Отличая Symfony 2 и Yii

Сейчас на распутье. Нужно начинать разрабатывать серьёзное RIA с длительным циклом жизни. А поэтому стоит серьезный выбор между 2 frameworl'ами.
На данный момент по документациям нашел следующие отличая(возможно и ошибаюсь).

ORM.
В Yii есть Scope, в Symfony 2 вместо них Filter's и Repositories, но они не такие удобные, как Scope и нужно плодить сущности.

Кешироваие.
У обоих есть куширование на уровне запросов, моделей и страниц. В Yii так же есть кеширование на уровне фрагментов страниц и данных.

Доступ.
Подход к доступу в Symfony 2 основан на ACL, в Yii на RBAC (т.е. тут Yii предпочтительнее)

Легкость в освоении.
Мне показалось, что Yii освоить гораздо проще чем Symfony 2. При этом возможности у фреймворков почти одинаковые. Да и с документацией на русском языке у Yii получше.

Все описанное выше — это мои личные впечатления после прочтения документаций и создания приложений чуть более сложных чем «Hello world».
Обращаюсь к мастерам, где я ошибаюсь и что упустил из виду(отличая)?

p.s.
Вопрос с PHP решен и выбор стоит лишь между этими двумя инструментами.
23 февраля в 00:35
8

отсортировано по дате по оценке
ответы (2)

+5
ExxY #
Если вам по-быстрому набросать бложек — выбирайте Yii. Он простой.
Если вы собираетесь делать серьёзное приложение, если вы знаете зачем нужен Dependency Injection, если вам необходимо покрывать большинство кода тестами, если вам нужно супер-крутая модульная архитектура, работа с миграциями и фикстурами — только Symfony 2.
Чем не работается с миграциями в том же Yii? В чём проблема с тестами? kotomyava, 23 февраля в 00:56
На сколько я знаю, код покрыть тестами можно и в Yii.
Миграции там тоже.
Гнаться за модульной архитектурой, упуская цель разработки, тоже не имеет смысла.

Мне бы конкретные вещи.

За «Dependency Injection» спасибо, посмотрю. Только ли к Symfony 2 оно подключается.
SowingSadness, 23 февраля в 00:58
Нет, не только, библиотек для пхп с таким функционалом хватает. taliban, 23 февраля в 02:01
Похоже, что Yii Вы не видели вообще. Смешно читать, что на нем можно писать только «бложек». Ну-ну… DEViANCE, 23 февраля в 12:16
Миграции — автоматическая генерация.
Тесты — куча статических методов и очень большая связанность. Попробуйте напишите тест для модели которая через Yii:app() работает с сессией и еще запросы в БД делает.

P.S. в нашей компании с десятков проектов на Yii
ExxY, 25 февраля в 13:47
Дорогие фанаты Yii, советую вам рассказать какому-либо вашему знакомому энтерпрайз архитектору на Java/C++/Python/Ruby что в вашем супер-крутом фреймворке все зависимости загружаются через один статический метод, доступный из любой точки приложения (Yii::app) и посмотреть на круглые глаза. ExxY, 25 февраля в 13:51
@ExxY И в чем проблема написать тест для класса с сессией и который работает с BD?

>что в вашем супер-крутом фреймворке все зависимости загружаются через один статический метод
Пожалуйста, не надо холиварных выподов. Если вы так считаете, аргументируйте, чем плоха статичесткая точка входа в web-приложении?
Т.к. таскать все что угодно, через черный ящик — «container» гораздо менее прозрачно.

Мне известны, по крайне мере 2 способа работы в контроллере с Запросом и с Авторизацией:
— заставить понимать знать о запросе
— предоставлять статический доступ к запросу

В Symfony 2 используется не явно 1 способ, через DI.
И вот тут появляется главный вопрос: «Нужно ли везде где можно использовать DI?»
Например, в данном случае, мне кажется что это зло, т.к.
public function generateUrl($route, $parameters = array(), $absolute = false)
{
return $this->container->get('router')->generate($route, $parameters, $absolute);
}

public function forward($controller, array $path = array(), array $query = array())
{
return $this->container->get('http_kernel')->forward($controller, $path, $query);
}
//container instanceof ContainerInterface === true

такой подход лишает бизнес-логику возможность использовать интерфейсы.
Что в свою очередь приводит к более дорогой поддержке проекта. Да и вообще, какой в к черту ООП, если у нас черный ящик который передаем от класса к классу «заумной аббревиатурой» DI?
SowingSadness, 25 февраля в 22:15
К слову, о «статический доступ к запросу», я имею в виду вот такой подход: sebastian-bergmann.de/archives/882-Testing-Code-That-Uses-Singletons.html SowingSadness, 26 февраля в 16:48
Почему реализованное как есть в Symfony 2 DI плохо:
miller.limethinking.co.uk/2011/05/19/when-dependency-injection-goes-wrong/
о чем я выше уже писал
SowingSadness, 26 февраля в 17:53
+3
VolCh #
С Yii плотно не работал, потому просто мнение:

ORM в Symfony (Doctrine2), имхо, мощнее чем в Yii по определенению. DataMapper+UoW vs ActiveRecord. Плюс хранлище на основе SQL СУБД без особых проблем может быть заменено на что-то другое, MongoDB, например, также из коробки почти. Но, вероятно, DM несколько тормознутее AR за счёт широкого использования отражений. Решается путем создания кастомных репозиториев, где хоть напрямую SQL вызывайте, не пользуясь DBAL.

Доступ в sf2 может быть основан на чём угодно, главное реализовать isGranted(). На основе ролей — из коробки.

Вообще модульность и низкая связанность сильная сторона sf2 (не в последнюю очередь из-за DI где нужно и где не нужно :) ). Другие full-stack PHP фреймворки, что поверхностно изучал, этим похвастаться не могут. В sf2 жёсткие связи используются мало, почти всё конфигурируется: не нужны предлагаемые абстракции роутера — напишите свой класс хоть на switch case, хоть на C, главное нужный интерфейс реализуйте и строчку в конфиге поправьте (а можно и не править, но, имхо, не стоит).
Кстати, на мой взгляд Symfony 2 самый продвинутый фреймворк из всех популярных на популярных динамических языках. Но во многих приложениях такая продвинутость может быть излишня, как излишня, по моему мнению, Java для личного блога. Вот как раз к Enterprise Java идеологии и близок Sf2, наверное. Для стартапов в сфере b2c с циклом близким к Agile методикам всё же Yii порекомендую (по отзывам :) ). Для b2b, для автоматизации хорошо известных бизнес-процессов альтернативы Sf2 имхо нет, если оставаться в области популярных динамических языков. VolCh, 23 февраля в 05:00
Спасибо за отзыв.
Т.е. я так понимаю основной плюс sf2 это DI.

>для b2b, для автоматизации хорошо известных бизнес-процессов альтернативы Sf2 имхо нет
Как же тогда быть с доступам к ресурсам. Для Enterprise же, как раз нужно использовать RBAC, а не ACL.

По поводу DataMapper, подскажите, было ли в вашей практике использование DM кроме как в роле ActiveRecord? А то, за большую гибкость мы платим черезмерно раздутым и, как следствие, более сложным в поддержке кодом.
SowingSadness, 23 февраля в 15:53
Можно и так сказать, хотя не совсем точно будет. Низкая связанность компонентов вернее будет, а уж реализуется она через DI.

Ещё раз. Простая реализация RBAC идёт из коробки. Если вам не нужна динамическая конфигурация ролей (создавать роли в админке грубо говоря), то просто задаёте их список в конфиге. Там же в конфиге можете ограничить список урлов для каждой роли. А можно в контроллерах зашить более сложную логику. Список ролей стандартными способами в базе хранить можно. Сложнее если нужно роли создавать в рантайме, но тоже решаемо. Собственно вся авторизация реализуется одним методом isGranted(). А противопоставлять ACL и RBAC я бы вообще не стал. Субъектами RBAC могут являться и роли.

Было, проводил денормализацию БД в целях оптимизации без изменения кода моделей. Собственно основное назначение DataMapper — отделить объекты модели от таблиц БД, чтобы их изменения друг на друга не влияли. Да и раздутым в использовании я бы DM не назвал, особенно при сложной логике, когда в ходе выполнения запроса создаются/изменяются/удаляются несколько несвязанных реляционными отношениями объектов модели — вызываем только раз метод «save» (flush). Собственно даже для «бложиков» мне теперь нравится использовать DM. Например, позволяет комменты к посту хранить в виде json/php-serialize поля в таблице постов, а не использовать 1-to-many и JOIN. И это без изменения кода моделей и контроллеров.
VolCh, 23 февраля в 19:53
С примером использования DM — большое спасибо.

Но вот с RBAC в Sf2 я не соглашусь, там чистое ACL(вы и пример ACL привели, а не RBAC) и оно не подходит для реализации динамических ролей, как вы сами и отметили. Хотя это уже оффтоп.
SowingSadness, 23 февраля в 20:42

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