Изучение Symfony2/Laravel, сколько времени потребуется?

Question

[Koh Phi Phi]

В общем решил вернуться к веб-разработке. Всё что пробовал из фрэймворков это CodeIgniter около года назад. Хотелось бы начать изучать либо Symfony, либо Laravel.
Посоветуйте что выбрать (для работы), и сколько примерно времени займёт период от начала изучения до первого собеседования?

Answer 1

[Сергей Протько]

сколько примерно времени займёт период от начала изучения до первого собеседования

По персонажам которые приходят на собеседование могу сказать что некоторые и за год работы не знаю ничерта о том что и как они используют.

На symfony2 в среднем проекты поинтереснее, так что я рекомендовал бы именно его. В любом случае переход laravel <-> symfony не является проблемой, ибо различия принципиальные там только в ORM идущей из коробки. Архитектура же этих фреймворков в целом схожа, разница в нюансах. Например в laravel мидлвэры как отдельная сущность, а в symfony они реализуются через события ядра, но суть та же. Еще нюансы с доктриной, эта штука довольно сложная и ее очень легко использовать неправильно, особенно с mysql. Но после того как разберетесь с ней возвращаться на всякие там active record-ы совсем не захочется. По сути это единственная полноценная ORM в php мире.

Еще вне зависимости от выбора рекомендую ознакомиться с такими штуками как луковая/гексагональная архитектура, почитать чего по TDD и тестирование в целом. Кента Бэка например, Эрика Эванса.

Comments

[Сергей Протько]

OnYourLips: хз, доктрина использует plain old php objects что лично в моем случае серьезно так поднимает скорость разработки. А с 2.5 версии можно value objects хранить спокойно, что позволяет наконец уйти от анемичной модели и радоваться жизни, загоняться по DDD и не жерствовать читабельностью кода в угоду скорости разработки.

[Сергей Протько]

OnYourLips: в целом же соглашусь - в большинстве проектов доктрина может будет лишней, с другой стороны это тоже своего рода плюс, так как проектов на symfony+doctrine много, и они судя по этой логике должны быть интереснее.

[Сергей Протько]

OnYourLips:
1) я не пишу геттеры/сеттеры, вообще это тип антипаттерн (хотя до 2.5 в доктрине по другому было сложно), зато у сущностей все хорошо с принципом открытости/закрытости ну и не забываем что есть такая штука как инкапсуляция.
2) у меня нет сервисов отдельных, 90% логичи реализуется прямо в сущностях (оставшиеся 10% случаев выносятся в сервисы только потому что иначе сущности начинают знать что-то совсем не относящееся к ним ну и репозиторий еще, но там все выборки и все такое в любом случае и вообще все что связано с доктриной)
3) вы не учитываете что вам надо все же базу данных иметь, то есть нет конфигов это круто, но для того что бы это было реальностью вам надо сначала сделать схему базы данных. У меня же главное это бизнес объекты и их взаимодействие, а структура базы формируется автоматом по этим самым конфигам описывающим связи объектов. С AR же мы в любом случае сначала должны спроектировать базу данных.
4) я не валидирую модель (хотя это сомнительный довод, в Laravel тоже так можно) так как она не может войти в невалидное состояние
5) доктрина позволяет строить бизнес логику сразу, максимально быстро и максимально удобно. Если логика простая (CRUD обычный) то да, эти преимущества довольно сомнительны. Но бывают довольно сложные фичи и такой подход позволяет быстрее найти сценарии которые небыли покрыты на плэнингах/грумингах.
6) за счет identity map (я не уверен к слову, в eloquent есть оно?) я могу спокойно работать с бизнес объектами и не беспокоиться на счет дублирования
7) за счет unit of work я могу не париться из-за сохранения, мне не нужно дергать save методы или вручную коммитить транзакции, все ресолвится на уровне инфраструктуры и я просто работаю с бизнес объектами. Соблюдается принцип persistence ignorance.

То есть доктрина (при наличии опыта работы с оной) может увеличивать стоимость разработки только за счет того что в среднем разработчики использующие доктрину дороже. Время разработки будет примерно тем же, но качество решений может быть выше. Опять же все это имеет смысл только в случае если мы имеем дело с бизнес логикой сложнее блога, что-то типа каталога товаров скорее.

[Сергей Протько]

OnYourLips: 1) ну с 2.2 вообще был кошмар, даже если брать 2.4 версию то там уже все намного лучше, 2.5 вообще сказка. Последние года так полтора я особо проблем с доктриной не ловлю и не наблюдаю торчащего DBAL. Есть правда свои нюансы, скажем пользоваться доктриной на mysql боль и унижение. А вот с постгресом все просто работает.

2) немного не понял, причем тут бандлы и ar? Я к слову никогда не понимал идеи разделять приложение на бандлы и в последнее время вообще отказался от оных (в рамках приложения, сторонние использую). Я не работал с eloquent, только пробовал, и не могу ничего сказать. Но если брать как пример Yii2 - там модели использовать как бизнес сущности, не как анемичную модель невозможно и просто опасно, могут быть тонны побочных эффектов. Хотя все можно делать, я видел как чуваки пытаются практиковать DDD с eloquent, но мне показалось это менее удобным чем с доктриной.

Доктрина за последние три года хорошо так подросла. Там есть еще свои проблемы, но с момента перехода на postgresql я вообще перестал испытывать проблемы с ней.

Answer 2

[Александр N++]

Берите laravel5, базового туторила хватает с лихвой, если конечно опыт есть в php5.4+ (и то дело 1-2 статей про PS4 namespace)

Я руководствуюсь этим
Чем проще, тем лучше.

Плюсов не вижу использовать симфони2, разве только, если штат знает/использует симфони и нечего другого не хочет. (мурашки)

PS вообще пишу на Yii2.
1 Все есть из коробки
2 главное простой

Comments

[Сергей Протько]

А вы пробовали симфони? Или точнее пробовали ли вы доктрину? (воспринимайте как соц опрос, думаю статейку написать и интересует мнение тех кому она не нравится). Вообще не представляю как писать поддерживаемый код с active record.

[Александр N++]

Сергей Протько зачем мне побывать такую боль на голову как доктрину.
Тогда мой принцип "чем проще, тем лучше" будет разрушен, по моему мнению.

Если в про AR который в Yii1 то да такой AR невозможно нормально поддерживать, а вот AR в Yii2 очень вменяемый.
Я бы с удовольствием глянул, примеры, того-что, нельзя сделать AR(Yii2) но можно сделать в доктрине.

[Сергей Протько]

Александр N++: в Yii2 запилили identity map-ы? Я с 2012-ого просто не слежу за событиями.

Например

$user = new User('Sergey');
$foo->user = $user;
$bar->user = $user;
// где-то сильно позже
$foo = Foo::find(1); // я не помню точно API yii2
$bar = Foo::find(2); // так что извините если что

assert($foo->user === $bar->user);

что тут будет?

[Александр]

Я долгое время работал с yii. И немного с yii2. Теперь только с symfony2. Количество готовых модулей больше. На счёт доктрины не знаю. По мне удобнеее чем AR . Работа с формами намного лучше, особенно с вложеными

[Александр N++]

Сергей Протько:
ошибка будет, а должно что то получится?

[Сергей Протько]

Александр: работаю с симфони более трех лет, количество готовых решений конечно впечатляет, но качетсвенных кот наплакал. Я обычно сильно расстраиваюсь когда вижу очередной бандл. Да что далеко ходить - нормального бандла для аплоада файлов нету, приходится использовать всякие vich uploader. В остальном да.

Александр N++: ну а не должно быть, доктрина это гарантирует. Если у foo и bar связь с одним и тем же пользователем, то и объекты это должны быть одни и те же. То есть значение foo->user и bar->user будут ссылаться на один и тот же инстанс юзера. Это то что должна гарантировать нормальная ORM.

Answer 3

[Mikhail Osher]

Оба хороши. На мой взгляд, у Symfony2 чуток выше порог вхождения.
Лично я руководствуюсь таким методом:
- нужен хардовый энтерпрайз = симфони
- иначе = ларавэл

Comments

[Сергей Протько]

Мое личное мнение - если уж Laravel то только с doctrine2. В целом же если разобраться разницы почти и нет.

[Сергей Протько]

OnYourLips: да ладно вам, с Doctrine скорость разработки не настолько сильно падает. Я бы даже не сказал что она падает.

[Сергей Протько]

OnYourLips:

https://gist.github.com/fesor/db2dd19e71a40ed2297b

пример дико упрощен, и не забываем что в моем случае мне не надо писать миграции или делать схему базы руками. Я просто запущу doctrine:migration:diff и doctrinte:migration:migrate.

[Сергей Протько]

OnYourLips: и да, я могу совершенно спокойно покрывать бизнес логику в сущностях юнит тестами, с active record же насколько я понимаю это невозможно, только интеграционные.