С кой PHP Framework сте работили?

С кой PHP Framework сте работили?


  • Общо гласове
    16
Като стана дума за Slim, исках да те питам нещо. :) По натам. Добър ли е този фреймуърк и за какво най-често го избират девелопърите на PHP? Някакви тежки и затворени системи?
Слима е за апита, не става за друго по принцип.
Доста куца стара версия на ларавел ми се вижда
 
Слима е за апита, не става за друго по принцип.
Доста куца стара версия на ларавел ми се вижда
Да, знаех си, че е някаква за вътрешна употреба, която може лесно да комуникира с друга. ;) Мерси много за разяснението. :)
 
1.2..3.. много сложно стана :)
Аз github го ползвам малко, може би за това не съм запознат толкова с точките, които изреди. fork/mork :D
Но в моите неща, които аз ползвам, vendor-a си го държа винаги с мен и ъпдейтвам, ако се наложи. (но текущия, а не отначало)
Така съм свикнал. Има си проекти, които не се ъпдейтват. Засичал съм обяви, не е само laravel 3, дадох го като прост пример.
И да, помня bundles, бях правил някакъв календар с google api за записване на часове, нещо просто беше.. Едвам разбрах как да подкарам тогава миграции от конзолата :D (нещо такова ми се върти в главата)
Строго те съветвам да приемеш съветите на @Fakeheal присърце. Само в твоя полза е. Не го казвам да се заяждам, но ако си в екипа ми и чуя, че променяш код във vendor папката или че се опитваш да я местиш, то това ще ни е работата заедно.

Нещата може да звучат по-сложни, но като схванеш идеята ще разбереш колко грешно си правил нещата до сега. Като цяло в днешно време библиотеки се пишат качествено и имат добър API. Когато искаш да разшириш нещо винаги можеш да създадеш собствени wrappers, да имплементираш интерфейс по свой начин и т.н.

Колкото до рамки - ползвал съм Ларавел, Лумен и сега Симфони или по-скоро определени компоненти създадени от екипа на Симфони. Но това е защото системата, която поддържам го изисква/налага. В интерес на истината за в бъдеще, ако създавам проект с рамка ще е Симфони. Естествено, ако има такъв път ще се стремя да не ползвам PHP, a ASP.NET.
 
PHP фреймуърците предоставят множество предимства, които подобряват пайлплайна за разработката ни. Тези подобрения обхващат всичко - от сигурността до производителността на аппа, а и от там на целия работен процес, за който се създава в крайна сметка. Всеки фреймуърк има различни фокуси - някои могат да се фокусират върху работния процес за разработка, а други могат да се фокусират върху скалирането на проекта. Както спомена вече и @uphero , Слим влиза май при API-тата и добрата симбиоза на фреймуърка с тях.

Според мен, ако имаш избора дали да ползваш или да минеш на Pure PHP, май бих дал гласа си за фреймуърка. И като ме подсекат с някакви въпроси от рода на АМА ЗАЩО?

Първото, което ми идва на ума е, че слага ограничения при програмиране или казано по друг начин вкарва ни в някаква рамка, което не ни позволява мазане и импровизации, на които следващия след нас няма да е много щастлив. :)

Отделно това пък от своя страна увеличава сложността на програмирането, което изисква много повече ръчно програмиране, за да постигнем някакви цели, които вече са постигнати с някоя библиотека. Единственото лошо, което съм намирал и още намирам е, че за всеки фреймуък е нужно да се отдели време и усилия, за да се навлезе, почти като да учиш нов програмен език.
 
Никога не се редактира кода във вендор папката директно. Ако пакета, който използваш има нужда от промяна имаш няколко варианта:

1) търсиш в документацията как пакета може да се разширява от твоя код, ако няма то:
2) правиш форк на проекта, модифицираш нужните файлове и после:
2.1) предлагаш промените да се внедрят в основната бибилиотека
2.2) инсталираш си твоя форк, ако не ти приемат промените (примерно защото са много специфични за твоето при

Много добре казано. Получаваш палец 👍🤗😁
Може би за това е хубаво туриста да има по "съвременни" уроци, които да покажат следващото ниво на хората и така да прогресират. Така освен комуникацията с потребителите ще има и съдържание, което да помага.

Забележка: въпреки, че едва ли някои би се заел с подобни уроци. По-лесния вариант ще бъде: ползвай Гугъл, udemy or... other smart advice.

Едит: Освен @Fakeheal > @Revelation е един от потребители също, които дават добри насоки и съвети.
 
Много добре казано. Получаваш палец 👍🤗😁
Може би за това е хубаво туриста да има по "съвременни" уроци, които да покажат следващото ниво на хората и така да прогресират. Така освен комуникацията с потребителите ще има и съдържание, което да помага.

Забележка: въпреки, че едва ли някои би се заел с подобни уроци. По-лесния вариант ще бъде: ползвай Гугъл, udemy or... other smart advice.

Едит: Освен @Fakeheal > @Revelation е един от потребители също, които дават добри насоки и съвети.
Според мен причината такива уроци да не се правят, е защото:
  1. Колкото по-старши си толкова повече те мързи.
  2. Потребителите на туриста исторически се знае, че не обичат да възприемат нови практики, по-добри решения и т.н., понеже излиза от комфортната им зона и нещата стават по-сложни (или в много случаи така си мислят). Съответно на никой не му се занимава да губи време за неща, на които няма да се обърне внимание.
Но като цяло не е това темата за такива мнения. Може да се създаде една тема в Дъра-бъра, ако някой иска да продължи по тази тема.
 
Според мен причината такива уроци да не се правят, е защото:
  1. Колкото по-старши си толкова повече те мързи.
  2. Потребителите на туриста исторически се знае, че не обичат да възприемат нови практики, по-добри решения и т.н., понеже излиза от комфортната им зона и нещата стават по-сложни (или в много случаи така си мислят). Съответно на никой не му се занимава да губи време за неща, на които няма да се обърне внимание.
Но като цяло не е това темата за такива мнения. Може да се създаде една тема в Дъра-бъра, ако някой иска да продължи по тази тема.
По скоро вече има уроци за всичко, това вече няма как да се получи тук.
Преди 10 години е било друго положението,
 
Symfony, Zend и Laravel. Когато съм имал избор - Symfony. Иначе с Zend също се работи приятно. Най ми беше тежко да работя с Laravel... няма такава идиотия, не знам по каква причина някой би го избрал.
 
Symfony, Zend и Laravel. Когато съм имал избор - Symfony. Иначе с Zend също се работи приятно. Най ми беше тежко да работя с Laravel... няма такава идиотия, не знам по каква причина някой би го избрал.
Може би многото библиотеки, лъскавите нещица, които могат да се правят и добрата му съвместимост с много фронт-ендски фреймуърци. Но това са ми само началните впечатления, по-голям фен съм на Zend. :) Drupal-ът селед 7цата е с Symfony, доколкото знам. Явно има защо. :)
 
Drupal ползват компоненти на Symfony, Laravel също, има и много други.
Иначе какво има за съвместяване с front-end-а, изкарваш един API и да си го ползват front-end-ърите. Кеф ти Angular, кеф ти React.
Не знам кой им се кефи, ама тея фасади, които можеш да хвърляш навсякъде, създават нов слой на зависимост... предпочитам да ползвам dependency injection. ORM-а и той има някаква специфична code smell.
Може фреймуърка да е супер и просто да не съм уцелил правилните проекти, ама впечатленията ми за Laravel са ужасни.
 
Drupal ползват компоненти на Symfony, Laravel също, има и много други.
Иначе какво има за съвместяване с front-end-а, изкарваш един API и да си го ползват front-end-ърите. Кеф ти Angular, кеф ти React.
Не знам кой им се кефи, ама тея фасади, които можеш да хвърляш навсякъде, създават нов слой на зависимост... предпочитам да ползвам dependency injection. ORM-а и той има някаква специфична code smell.
Може фреймуърка да е супер и просто да не съм уцелил правилните проекти, ама впечатленията ми за Laravel са ужасни.
За какъв горе долу проект е бил избран? При мен zend-а беше, както писах, за система, която генерира справки на база събрано и налято съдържание. Голяма база, малка файлова част и няколко външени услуги, внедрени в системата със скриптове. Супер беше, което за фронта не мога да го кажа, там реално си беше супер кофти изпълнение, ама се ползваше не много добре jQuery, bootstrap.
 
Drupal ползват компоненти на Symfony, Laravel също, има и много други.
Иначе какво има за съвместяване с front-end-а, изкарваш един API и да си го ползват front-end-ърите. Кеф ти Angular, кеф ти React.
Не знам кой им се кефи, ама тея фасади, които можеш да хвърляш навсякъде, създават нов слой на зависимост... предпочитам да ползвам dependency injection. ORM-а и той има някаква специфична code smell.
Може фреймуърка да е супер и просто да не съм уцелил правилните проекти, ама впечатленията ми за Laravel са ужасни.
На 100% подкрепям мнението ти. Ларавел малко трудно ти дава нужната свобода, която ти трябва при по-големи проекти.
 
За какъв горе долу проект е бил избран?
Беше изградена erp система върху Laravel. Имаше около 350 фасади, щото явно екипа е бил скаран с DI, Eloquent не се справяше с половината от задачите, но те решили, като част от приложението да го надграждат... вместо да вземат Doctrine и да си решат всички проблеми, без един бит да напишат.
Има няколко концепции в Laravel, които много ми допадат, но като цяло, не бих го избрал за нещо сериозно.
Аз пиша предимно на Java, за това Zend и Symfony са ми най-близки. Laravel за мен предразполага да нарушиш всички добри практики в ООП.
 
ERP системата? Леле, тежка задача. Винаги съм си мислил, че PHP не е езика за такъв тип проект, но си е мое лично мнение. :)

И дори този фреймуърк, който са подбрали, не мисля, че е най-добър за случая.
 
ERP системата? Леле, тежка задача. Винаги съм си мислил, че PHP не е езика за такъв тип проект, но си е мое лично мнение. :)

И дори този фреймуърк, който са подбрали, не мисля, че е най-добър за случая.
Нали знаеш как са нещата. Наемат някой, дават му задача и той казва "ще я направим на PHP че е най-лесно и само него знам". Тормозя се дори в момента на работа като се опитват да оправят всяко едно решение с един тип база данни и един език. Никога не се взима предвид дали няма по-добро решение. От гледна точка на ресурси и познания в екипа го разбирам, но не ми харесва.
 
Нали знаеш как са нещата. Наемат някой, дават му задача и той казва "ще я направим на PHP че е най-лесно и само него знам". Тормозя се дори в момента на работа като се опитват да оправят всяко едно решение с един тип база данни и един език. Никога не се взима предвид дали няма по-добро решение. От гледна точка на ресурси и познания в екипа го разбирам, но не ми харесва.
Да не говорим, че вече сшима доста решения, кои Клауд базирани, които са десктоп, с централизирана локална или отдалечена база данни. Това с избора зависи изцяло от проджект мениджмънта, ако въобще има такъв.
 
ERP системата? Леле, тежка задача. Винаги съм си мислил, че PHP не е езика за такъв тип проект, но си е мое лично мнение. :)

И дори този фреймуърк, който са подбрали, не мисля, че е най-добър за случая.
Нали знаеш, почва се с нещо малко и докато се усетиш, че не си избрал най-удачното решение, код бейса е нараснал толкова, че няма как да се мигрира.
PHP си е ок като език, въпросът е, че трябва много добре да го познаваш, за да не се застреляш в крака.
 
З знаеш, почва се с нещо малко и докато се усетиш, че не си избрал най-удачното решение, код бейса е нараснал толкова, че няма как да се мигрира.нам
PHP си е ок като език, въпросът е, че трябва много добре да го познаваш, за да не се застреляш в крака.
Знам, знам, така почнаха фейса. :) Късно беше, когато станаха големи. ;)
 
Едно време 2015-2016 година работих на ето тая гняс:


Страшна мъка…

От тогава само angular + spring. Друго не хващам.
 

Back
Горе