С какого фреймворка стоит начать (Yii, zend, symfony)?

Question

[Сергей]

Решил вплотную подтянуть знания, решил начать учить фреймворки. Выбрал три наиболее популярных-востребованных среди php разработчиков. Так вот, с какого начать? Какой проще для начинающего, с какого проще перейти на другие два?

Answer 1

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

Для начинающего проще будет Yii. Он простой как пробка, но в то же время, при определенном опыте работы, на нем можно писать неплохие проекты.

Zend — тут ничего не могу сказать. Наверное только с него проще будет переходить на Symfony. В этом плане к слову Yii чуть проигрывает — с него слазить сложнее. я 2 месяца плевался когда на симфони переходил.

Symfony 2 наверное самый крутой PHP фреймворк из существующих сегодня, ну или самый перспективный. Я бы начал сразу с него, хотя будет тяжело, зато больше опыта.

Comments

[Kir ---]

Что крутого в фреймворке в котором паттерн использования DI используется не верно? Даже Файлер говорил, что подобная реализация DI самая плохая из всех возможных.
Мне кто-нибудь объяснит когда уже разработчики перестанут вестись на голый маркетинг?

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

Kir ---: кто такой Файлер?

Может кто-нибудь объяснить когда разработчики начнут думать своей головой? Ну да, у них DI реализован так как реализован, зато это позволяет компилить оный а не кешировать. Ну и дополнительные плюшки. + вам никто не мешает использовать любой другой поверх симфоневского, я вот PHP-DI юзаю.

Что до "маркетинга", лучше уже кривой DI чем Active Record всюду.

[Kir ---]

Сергей Протько: Фаулер* - опечатка
Какая связь между DI и ActiveRecord? Вы путаете, наверное Data Mapping и Dependency Injection.
Data Mapping к Symfony 2 имеет апосредственное отношение, т.к. Doctrine не часть Sf2

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

Kir ---: какая связь между DI и ActiveRecord? Я как пример приводил.

Например по дефолту Symfony идет с не слишком удобным DiC, который, хоть и реально гибкий и крутой, заставляет разработчиков лениться при проектировании того же сервисного слоя (как правило им лень описывать на каждый чих новый севис и появляются убогие "Менеджеры". Зато опять же из коробки Symfony идет с доктриной, которая обеспечивает persistence ignorance за счет использования Unit-of-work.

Если брать какой-нибудь Laravel или Yii - там разработчики вдохновлялись RoR, и по итогу в комплекте поставки идет сносный IoC с автоконфигурированием. Но в то же время по дефолту там идет богомерзский ActiveRecord. В итоге можно и на нем сделать все хорошо, оборачивать все в транзакцию и работать через aggregate-root и использовать модели ORM как DTO, но это уже реально сложно и в 99% случаев будет считаться оверхэдом.

А теперь давайте прикинем, что влияет больше непосредственно на код проекта? Использование ActiveRecord вместо Doctrine, где все это добро можно вынести в отдельный слой и вообще не завязывать на нее код проекта, или же DiC, который влияет только на удобство использования. При том что для Symfony есть autowire-bundle-ы, которые реализуют автоконфигурирование, пусть и кривенько. Можно запариться и сделать что-то свое. А можно вообще не париться и поставить PHP-DI + Symfony2 bridge и жить себе припиваючи. В этом плане к слову Zend выигрывает, так как у него и IoC как надо и доктрину можно легко прикрутить.

Разработчики знаете ли, могут с Symfony выкидыать лишнее и оставлять то что им нужно. Есть проекты где от Symfony с течением времени осталось только HttpKernel и HttpFoundation. Раутинг сменен на FastRoute, формы и валидатор выкинуты (вся валидация идет через использование VO и внутри модели предметной области (в сервисах, в самих сущностях).

ну и опять же речь в вопросе шла о первом фреймворке, да и ответ этот я писал 2 года с лишнем назад. Тогда тот же Laravel был еще зеленым.

[Kir ---]

Например по дефолту Symfony идет с не слишком удобным DiC, который, хоть и реально гибкий и крутой, заставляет разработчиков лениться при проектировании того же сервисного слоя (как правило им лень описывать на каждый чих новый севис и появляются убогие "Менеджеры".

За подобное создание сервисов на каждый чих нужно руки отрывать. Это главная ошибка всех разработчиков, которые впервые встречают DiC. Связность нужно снижать лишь только там, где это необходимо. Таких мест достаточно мало. Если у вас вообще будет реализовано через контейнер, то вы логику программы вынесите в конфиг что в РАЗЫ усложняет разбор кода и поддержки развёртывания приложения.

Зато опять же из коробки Symfony идет с доктриной, которая обеспечивает persistence ignorance за счет использования Unit-of-work.

Unit-Of-Work идёт с Doctrine, а не с Sf2. Doctrine не часть Sf2.

Разработчики знаете ли, могут с Symfony выкидывать лишнее и оставлять то что им нужно.

Ну вот разве что это только можно поставить в плюс. Только слишком много нужно выкидывать. Да, как я и писал DiC реализован не правильно. Нельзя получать сервис по текстовой строчке. Это сводится к использованию глобальных переменных.

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

Kir ---:

справедливости ради, в PHP нет такой вещи как "взять по типу", только строки. Так что все ок.

За подобное создание сервисов на каждый чих нужно руки отрывать.

Аргументируйте (или как минимум расскажите как надо, мне всегда интересно узнать мнение других людей о построении сервисного слоя приложения, именно как части модели предметной области). За что именно нужно отрывать руки? За то что вместо тупых классов менеджеров (по одному на каждую сущность, нарушая при этом single responsibility) у нас имеются четкое разграничение сервисов по фичам и каким-то особенностям бизнес логики? За то что всю бизнес логику и весь сервисный слой приложения можно покрыть юнит тестами без боли?

Словом это все очень абстрактно. Ну и есть не нулевая вероятность что фразу "создать класс на каждый чих" вы восприняли уж сильно буквально.

Опять же, что до конфигов - конфиги нужны, и я уже третий раз повторяю, вас никто нивчем не ограничивает. Можно хоть свой компайл пасс сделать который будет все "правильно" делать (я правда считаю это извращением), можно поставить другой контейнер (причем есть готовые интеграции, не нужно городить горы бойлерплейтов). Хотя да, согласен что контейнер зависимостей у симфони - самая неудачная его часть.

Unit-Of-Work идёт с Doctrine, а не с Sf2. Doctrine не часть Sf2.

Ну Doctrine идет в symfony-standard-edition из коробки. Так что я считаю это частью фреймворка. Ибо если это не так, то Symfony можно воспринимать только как набор компонентов и не более, и тогда любые притензии к отдельным компонентам можно считать фарсом.

Повторюсь, мне сейчас нравится идея вообще обходиться без full-stack фреймворков и использовать набор компонентов. Но новичкам, а вопрос задавался в этом контексте, этого следует избегать и для начала разобраться в основной структуре приложения.

p.s. А что вы предлагаете использовать новичкам которые, как правило, даже ООП толком не знают?

[Kir ---]

Сергей Протько:

справедливости ради, в PHP нет такой вещи как "взять по типу", только строки. Так что все ок.

/**
 * @property $session DBSession
 */
class AppContainer {
   private $session;
   function getSession() {
      return $this->session;
   }
}
$session = $container->getSession()

Изи.

Аргументируйте

. Если у вас вообще будет реализовано через контейнер, то вы логику программы вынесите в конфиг что в РАЗЫ усложняет разбор кода и поддержки развёртывания приложения.

Ну Doctrine идет в symfony-standard-edition из коробки. Так что я считаю это частью фреймворка

Давайте не смешивать всё в одну кучу. Doctrine можно прикрутить почти к любому Фреймворку. Как и Symfony 2 использовать без неё.

. А что вы предлагаете использовать новичкам которые, как правило, даже ООП толком не знают?

Те кто знают ООП на самом деле очень мало. Следствие использование DiC как в Sf2 прямое нарушение solID.

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

Kir ---: мм... вам я так понимаю нравится Yii или laravel4.... или pimple.... Я правильно вас понимаю что вместо конфигов, с которыми хоть как-то можно жить, вы предлагаете одно из двух:
- писать тонны бойлерплейта на каждый класс, что как по мне хуже конфигов
- завязать все компоненты фреймворка на контейнер и нарушить принцип ивенсии зависимостей. Что в итоге произойдет где-нибудь в проекте ибо разработчики ленивые существа. ну или вообще убойную комбинацию из регистри и фабрик явных.

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

А как вам такой вариант:

class Foo {

     public function __construct(Session $session){}
}

и конфиг ко всему этому:

<?php

return [
    Session::class => MySessionManagerImpl::class
];

В итоге у нас одна строчка в конфиге, которая определяет что для такого-то интерфейса, на который завязазы все остальные компоненты, у нас такая-то реализация. И все. Больше ничего писать ненадо (если нет чего-то сложнее вроде передачи конфигов или параметров).

Следствие использование DiC как в Sf2 прямое нарушение solID.

Ммм... именно принцип сегрегации интерфейсов? Ну... в целом не думаю что sf/DiC подстегивает к этому разработчиков. Уж чаще можно встретить для начала нарушение принципа единой ответственности. По поводу того что народ чаще завязывается на конкретные имплементации и принебрегает силой интерфейсов - это беда не инструмента а головы. Опять же все это лего фиксится использованием другого контейнера и Symfony тут не причем.

Но опять же, это один из компонентов который легко заменить на другой.

По поводу инверсии зависимостей - как я уже писал выше - у sf с этим все ок, ничего не нарушается (я небыл уверен, выделили вы D или так просто опечаталось)

[Kir ---]

Сергей Протько:

мм... вам я так понимаю нравится Yii или laravel4.... или pimple....

Мне нравится Pyramid. Я не обнаружил пока что ничего что противоречило одному из принципу SOLID или ООП.

вместо конфигов, с которыми хоть как-то можно жить ...:
- писать тонны бойлерплейта
- завязать все компоненты фреймворка на контейнер и нарушить принцип ивенсии зависимостей

Конфиг, это чистой воды вынос логики создания из кода, в другое место. Теперь находясь в любом сервисе вам необходимо сверяться, что у вас там в конфиге. Что на прямую противоречит цели создания принципа ООП, т.е. снижения сложности понимания кода.
Завязывание всего на контейнер, это и есть что сейчас пропагандирует Sf2. Я предлагаю выносить в контейнер только лишь те компоненты, которые критичны для сторонних разработчиков (сторонние, это те кто завязаны на ваш продукт, но используют его как каркас или библиотеку) или подменяются по задумке администраторами при развороте (Например выбор больших самостоятельных функциональных модулей, с публичным интерфейсом с учётом принципа open/closed. Например выбор сервиса криптографии. Под Linux один, под Windows другой.)

А как вам такой вариант:

Строчку заменили на строчку. Норм, чё.

Ммм... именно принцип сегрегации интерфейсов

О чём я думал когда писал это я не помню, помню что очень гневно торопился. :) Так что эту часть можете забыть. Суть в том что контейнер не гарантирует вам вернуть то чего вы ожидаете, т.е. свою функцию как составляющая IoC он не выполняет.

, выделили вы D или так просто опечаталось)

Да, опечатка :)

Answer 2

[kirchevsky]

Yii, но любой ответ в таком топик будет очень субъективным…

Answer 3

[ckald]

CodeIgniter. Мне кажется, он очень удачно направляет начинающего разработчика. И, при этом, отлично справляется с огромными или высоконагруженными проектами.

Comments

[Roman Revin]

lvl 1 — CodeIgniter
lvl 2 — Yii
lvl 3 — Symfony

[ckald]

Как грубо :) Боюсь, есть смысл укоротить ваш список до lvl 1 — CodeIgniter, а дальше пусть сами выбирают. Насколько я понимаю, ни у кого нет критериев для ранжирования фреймворков. А вот начинать действительно просто с игнайтера в виду большого комьюнити, отличной документации и общей прозрачности (конечно, на беду гибкости).

Answer 4

[AntonioK]

Спорно, но Kohana 3.

Comments

[Meliborn]

Подписываюсь под коханой за простоту.

[LayneBuchyn]

Простите, но бесперспективно.

[StrangeAttractor]

Прекраснейшая, логичнейшая вещь!

[ckald]

Да, все комментарии ко двору: у Коханы все хорошо и дистрофическое комьюнити. История: пропало несколько отличных модулей (например, Jelly ORM и все на ней завязанные), когда у jonathan-geiger не осталось времени их поддерживать.

[AntonioK]

Так вроде в ветке 3.2 нативный ORM безусловно превосходит Jelly по функциональности?

Исторически так сложилось, что до сих пор я работал только с веткой 3.0.

[ckald]

Знаете, именно благодаря этому топику-вопросу, меня вчера потянуло посмотреть, как там дела у Коханы. И, да, документация ORM меня не разочаровала. Единственно, я пока не понял, как модуль bmidget'a для формогенерации Formo за него цепляется — ведь в моделях ORM явно не декларируются поля.

Этот вопрос требует исследований, но, в целом, всем спасибо за комментарии, вы сподвигли меня еще раз попробовать плотно засесть за Коханой и, возможно, попробовать нижеупомянутый Lavarel (явно по Кохане деланный) и вышерасхваленную Симфони.

[NeX]

jelly под 3.2 хорошо живет и развивается github.com/creatoro/jelly. Гораздо мощнее нативной orm, формо достаточно просто к нему прикручивается (придется модифицировать драйвер от нативной орм)

[ckald]

Последние коммиты в ветках — 8-12 месяцев назад. Неужели прямо-таки stable? Помнится, я год назад как раз пытался воскресить один проект на 3.2 — огреб множество проблем. Некоторые модули приходилось по косточкам перебирать. Тот же bmidget открестился от меня, когда я обратился за помощью с этим самым драйвером.

ORM хоть поддерживается :)

[NeX]

3.2 вышел примерно год назад, поэтому новых коммитов и не было. В продакшене используется, проблем пока не замечено. Код в нем легкий и понятный, хорошо расширяется. Драйвер, когда искал, находил только для «старых» версий jelly 2.3. Писал свой

[ckald]

NeX, как насчет выложить его где-нибудь на каком-нибудь гитхабе?) В ORM объявилось отсутствие полей «не-в-бд». В jelly, помнится, мы с ними славно дружили.

Answer 5

[neuromotor]

Не ограничивайтесь одним фреймворком. Попробуйте все три. Например реализуйте небольшой тестовый проектик на всех трех. Далее для себя решите что более о душе.

В любом случае это будет время потраченное с пользой!

Answer 6

[LayneBuchyn]

Начать проще с Yii.
Но, по моим наблюдениям, опытные Yii-разработчики, попробовав Symfony2, переходят на него, в том числе и я.

Answer 7

[Renat Ibragimov]

Так как CodeIgniter очень в подвешенном состоянии, то я бы рекомендовал Laravel — laravel.com/ это свежий, очень структурированный, понятный и с хорошей документацией фрэймворк, лучшее пока что я видел.

Comments

[Роман Кутенко]

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

[ckald]

Выглядит, как поделка на основе Коханы.

Не нашел в документации: он умеет запускать контроллеры во view хоть в каком-нибудь виде?

[Renat Ibragimov]

Ну на сколько я знаю Kohana, то Laravel на него не похож, скорее они похожи на одного предка — CodeIgniter, так сказать оба вдохновлялись им.

По поводу «запускать контроллеры во view» немного не понятно, что имелось в виду, если некое наличие HMVC то вызывать controllers из view ужасно плохая практика, но можно через IoC контейнер. Если же имелось в виду рендеринг кусочка другого views то это разумеется есть.

[Роман Кутенко]

В laravel мне понравился Blade, интересно с шаблонами работать. Но пока не знаю на сколько это будет нагружать сайты. Ну а в целом очень приятно писать на нем.

[ckald]

Ммм, Blade шибко похож на pure php. Вот mustache, например, подальше от логики во view ушел.

По поводу «запускать контроллеры во view»: под этой ужасно плохой практикой я понимаю pull-mvc www.guyrutenberg.com/2008/04/26/pull-vs-push-mvc-architecture/ и на интеллектуальном уровне такая архитектура мне кажется более удачной для информационного сайта с абыкакой структурой. Зачастую даже layout'ы всякие, какие используют с Kohana и Laravel, пасуют.

И я хочу проверить свой умозрительный вывод на практике. Codeigniter явно захлебнется, а вот Кохана потянет. Интересно и Laravel посмотреть.

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

Laravel очередной посредственный фреймворк. Идея неплохая, но реализация не дотягивает до использования в работе. Много таких фреймворков. В них смысл есть только для простеньких прототипов. На продакшен я бы побоялся проект писать на таком фреймворке, вдруг разработчик забьет или еще чего.

[Renat Ibragimov]

А в чем посредственность-то? Очень хорошо всё сделано, от грамотных нэймспэйсов, приятного роутинга (который мне микс из Sinatra напоминает), хорошие идеи по бандлам, автозагрузке и шаблонизатору. Всё это просто и приятно работает без багов.

А смысл бояться, что разработчик забъёт?
Это же open source найдёте багу, поправите сами. Использую в одном проекте, на продакшене, полёт в общем-то нормальный, каких-то явных граблей не встречал даже, что встречал, это читать документацию.

Answer 8

[nuclear]

Symfony. А вообще таких топиков тьма.

Answer 9

[Вячеслав Плиско]

Учиться лучше по Zend Framework, он прям писан чтобы показать возможности ООП в php и весь этакий академичный.
А вот для работы лучше начинать с Yii, он удобнее на первых порах.
Symfony, наверное, тяжёл для начала.
Лично мне нравится nette, но он не так хорошо документирован и часть материала вовсе на чешском.

Answer 10

[suver]

Из перечисленных я бы рекомендовал начать сразу с ZF. Он гораздо сложнее, но полезного опыта получишь больше. Если хочется сразу начать писать и не мучатся с настройками проекта, переопределения классов и прочим то лучше с Yii. За Symfony ничего не могу сказать, с ним дело имел вскользь. Мне не понравился. Я больше к ZF тянусь. Он сложнее, но он гораздо гибче и универсальнее. А если к нему еще Doctrine подключить вообще песня. Ну а вообще скоро обещают выход ZF2 вот его я очень жду.

Comments

[cystbear]

ZF первый, а Вы иммено о нем и говорили, это игргушка по сравнению с Symfony2.

Answer 11

[PlatinumArcade]

Я когда разбирался с фреймворками, начал со статьи типа «пишем MVC-фреймворк своими руками». Когда поэтапно строишь свой фреймворк, тогда приходит понимание о MVC-модели вообще. После этого понимания уже в любой MVC-фреймворк не страшно нырнуть, то уже дело вкуса.

Сам остановился на Yii, хорош!

Answer 12

[antoo]

Все эти 3 фреймворка очень мощные и далеко не самые простые, я бы не стал рекомендовать их для начинающих. Для начала лучше понять модели MVC, брать не очень тяжелые фреймворки типа FatFree, чтобы был хоть какой-то опыт, а потом уже пробовать тяжелые Zendы и Symfony.

Comments

[Антон Дмитриев]

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

Answer 13

[sowich]

Однозначно не стоит брать ZF во внимание если до этого не имели дело с фреймворками вообще, имхо конечно.

Для начала я бы посоветовал Kohana3.x Довольно простой фреймворк как по архитектуре, так и по понимаю кода. Если опыт в программировании достойный, то сможете очень быстро разобраться.

Yii на мой взгляд это следующий шаг, фреймворк очень мощный и гибкий. Но на первых парах тоже впринципе подойдет.

Ничего не могу сказать про Symfony2, к сожалению, пока не удалось познакомиться на практике.

ZF это как говорится «на посошок», когда имеется свободная ориентация в самом php(ООП) и владение шаблонами проектирования(хотя это необходимо в любом фреймворке).

Answer 14

[brezee]

Можно посмотреть в сторону CakePHP. Хорошая документация, комьюнити.

Comments

[ckald]

Ухты, он ожил?

Answer 15

[aram118]

выбирай zend framework 2.