Отличая Symfony 2 и Yii?

Question

[Kir ---]

Сейчас на распутье. Нужно начинать разрабатывать серьёзное 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 решен и выбор стоит лишь между этими двумя инструментами.

Comments

[Kir ---]

Сам публикую ответ на свой вопрос.

Answer 1

[Kir ---]

Symfony 2 не так плох как я о нём думал.
Просто везде не пишут как правильно его использовать.
Те кто говорят, что он сложный, но лучше, тоже не представляют как правильно «готовить» sf2 + doctrina.

Все Entity остаются лишь Entity без какой либо логики, только getters и setters.
Вся бизнес-логика оформляется в виде сервисов.
В контроллерах только проверка параметров и вызов соответствующего сервиса.

Все остальные претензии по поводу ошибок, событий и Forms к Sf2 остаются.
Но с подходом Data Mapping сложность написания и поддержки продукта действительно снижается.
Т.е. тут сыграл роль лишь Data Mapping.

В Symfony 2 есть большая проблема с тем что не правильно написан DI Container.
И поэтому весь код практически сводится к использованию глобальных переменных. Сравните:

$myService = $this->getContainer()->get('myService');
/* vs */
global $myService;

Преимущество у Sf2 тут исключительно в том, что при использовании сервисов мы знаем что там что-то лежит. Не факт что то что нужно, но что-то лежит. От чего легче не становится.

UPD
Какой фрэймворк выбрать Yii 2 или Symfony 2?

Comments

[marenkov]

>И поэтому весь код практически сводится к использованию глобальных переменных. Сравните:

$myService = $this->getContainer()->get('myService');
/* vs */
global $myService;

Это совершенно разные вещи.

global $myService - оздачает что где-то и в какой-то момент вы самостоятельно должны инициализировать $myService. Если сделать это слишком рано, то может оказаться, что вы зря его дергали. Ну и надо как-то определить какой класс для этого будет использоваться.

$myService = $this->getContainer()->get('myService') - сервис будет инициализирован фреймворком именно тогда, когда он вам понадобился. Если для его работы нужны другие сервисы, их инициализация также произойдет лишь при необходимости. Классы, которые будут использоваться в качестве сервисов берутся из конфигурации. Т.е. если вам не нравиться какой-либо сервис, пишите свой класс, вписываете его в конфигурацию и все - все используют его.

[Kir ---]

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

[marenkov]

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

Если серьезно, но проблемы глобальных переменных в возможности непреднамеренного изменения (совпадение имен) и той самой инициализации.

[Kir ---]

marenkov: и? Написали тоже самое что и я. Как вы оправдали этот подход к такому контейнеру?

[marenkov]

Kir ---: Отнюдь не то же самое, прочитайте внимательнее. Жду от вас ваше видение правильного контейнера. Как по мне, то единственная проблема, возможность преднамеренно заменить сервис. Но тут уж ничего не поделать, преднамеренно можно и back-door в код вставить.

[Kir ---]

marenkov: Когда ваш сервис А доступен всем подряд, то в блоке, который доступен лишь при выполнения условия ИКС, вы можете столкнутся с тем, что там находится сервис А в состоянии, которое противоречит условию ИКС.
И это одна из проблем.

Про создание сервисов, где инициализация не простая, а зависит от других сервисов - отдельная песня. Кто-угодно может подменить состояние для своих нужд и вы это никак не контролируете.

И вся проблема не в том, что кто-то со злым умыслом это сделал. А в том что он не видит область воздействия своих локальных действий. Что и есть самая большая проблема при использования глобальных переменных.

Я, действительно опечален тем, что огромное количество программистов, уже с затуманенными мозгами книгами по паттернам и "модным" фреймворкам, не понимают какие задачи решает ООП и с помощью каких инструментов.

[marenkov]

Kir ---: Мда, тяжелый случай. Советую Вам почитать что-нибудь толковое о контейнерах, сервисах и сервис-ориентированном программировании. Хотя нет, лучше о Haskell. Правда проблема с возможным изменением файлов и содержимого базы данных останется, но от этого уж никуда, ну разве ПЗУ программировать.

[Kir ---]

marenkov: ... аргументировано, на этом и закончим.

[abratko]

marenkov: не нужно мешать людям заблуждаться и наступать на грабли, тем более когда они хотят на на них наступить. Они поймут это только тогда, когда получат по лбу, а они по нему обязательно получат - это неизбежно, судя по комментариям от Kir ---.

Answer 2

[ExxY]

Если вам по-быстрому набросать бложек — выбирайте Yii. Он простой.
Если вы собираетесь делать серьёзное приложение, если вы знаете зачем нужен Dependency Injection, если вам необходимо покрывать большинство кода тестами, если вам нужно супер-крутая модульная архитектура, работа с миграциями и фикстурами — только Symfony 2.

Comments

[Борис Сёмов]

Чем не работается с миграциями в том же Yii? В чём проблема с тестами?

[Kir ---]

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

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

За «Dependency Injection» спасибо, посмотрю. Только ли к Symfony 2 оно подключается.

[Анатолий]

Нет, не только, библиотек для пхп с таким функционалом хватает.

[DEViANCE]

Похоже, что Yii Вы не видели вообще. Смешно читать, что на нем можно писать только «бложек». Ну-ну…

[ExxY]

Миграции — автоматическая генерация.
Тесты — куча статических методов и очень большая связанность. Попробуйте напишите тест для модели которая через Yii:app() работает с сессией и еще запросы в БД делает.

P.S. в нашей компании с десятков проектов на Yii

[ExxY]

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

[Kir ---]

@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?

[Kir ---]

К слову, о «статический доступ к запросу», я имею в виду вот такой подход: sebastian-bergmann.de/archives/882-Testing-Code-That-Uses-Singletons.html

[Kir ---]

Почему реализованное как есть в Symfony 2 DI плохо:
miller.limethinking.co.uk/2011/05/19/when-dependency-injection-goes-wrong/
о чем я выше уже писал

[Inori]

Вы эту статью сами-то читали?
Он описывает типичные ошибки новичков (а ля использование DIC как Service Locator) и как от них избавиться. Хоть бы его же вывод потрудились почитать:

Dependency Injection is a must if you want to create easily testable, loosely coupled code. However it is important to ensure that you avoid the above if you actual want to get these benefits.

[Kir ---]

Боже ш мой.
Ищите по статье: «Poor Type Hinting»

Answer 3

[dutchakdev]

Что бы я не делал, куда бы я не шел, я выбираю — Yii. Больше менять не чего не хочу. Причин на это столько, что это целая отдельная статья, которая миллион раз переписана другими людьми, полюбившими это чудо!

Answer 4

[Владимир Чернышев]

С 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, главное нужный интерфейс реализуйте и строчку в конфиге поправьте (а можно и не править, но, имхо, не стоит).

Comments

[Владимир Чернышев]

Кстати, на мой взгляд Symfony 2 самый продвинутый фреймворк из всех популярных на популярных динамических языках. Но во многих приложениях такая продвинутость может быть излишня, как излишня, по моему мнению, Java для личного блога. Вот как раз к Enterprise Java идеологии и близок Sf2, наверное. Для стартапов в сфере b2c с циклом близким к Agile методикам всё же Yii порекомендую (по отзывам :) ). Для b2b, для автоматизации хорошо известных бизнес-процессов альтернативы Sf2 имхо нет, если оставаться в области популярных динамических языков.

[Kir ---]

Спасибо за отзыв.
Т.е. я так понимаю основной плюс sf2 это DI.

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

По поводу DataMapper, подскажите, было ли в вашей практике использование DM кроме как в роле ActiveRecord? А то, за большую гибкость мы платим черезмерно раздутым и, как следствие, более сложным в поддержке кодом.

[Владимир Чернышев]

Можно и так сказать, хотя не совсем точно будет. Низкая связанность компонентов вернее будет, а уж реализуется она через DI.

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

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

[Kir ---]

С примером использования DM — большое спасибо.

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

[cystbear]

С чего вы взяли, что в sf2 систем ACL?

[Kir ---]

symfony.com/doc/current/book/security.html
symfony.com/doc/current/cookbook/security/acl.html

[Kir ---]

Любителям Doctrina (ORM по умолчанию в поставке с sf2):
github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php#L364
github.com/doctrine/doctrine2/pull/126
github.com/doctrine/data-fixtures/commit/374d037b2320af296bf5bfe85c7820714ed06718#commitcomment-1565880

[Elkan]

Меня особо никогда не удовлетворяла реализация RBAC в Yii, всегда приходилось писать свой менеджер авторизации и т п, который работал с БД, так что смутное преимущество. Symfony красивый да, но чтобы сделать что-то красивое на нем, нужно убить кучу времени со всеми DI и прочим, так-что всегда выбирается из время/скорость разбработки и все. Но Symfony отличный :)

[Kir ---]

Elkan извините не соглашусь.
Что в sf2 красивого? Как говорил Калашников — «красиво то, что просто». В sf2 ничего простого я не вижу. Попытка сделать все академически правильно, что привело к усложнению.

[Elkan]

Нет, там все сделано «академически правильно», но вот чтобы самому с 0 разобраться в нем и сделать так-же, надо гораздо больше времени чем для Yii, если выбирать просто сделать проект, то да Yii, а если поломать голову, приобрести опыта чуть больше в построениии кривых сверхсложный мозгодробящей архитектуры, то да sf2 :D Просто тут холивар разводить не хочется, там он выше уже кипит, но я считаю что sf2 сложнее yii на порядок, вот когда будет yii2, тогда поговорим об обратном)

[Kir ---]

Elkan Там все сделано не всё «академически правильно».
например в паттарне IoC Injection Container допущена критическая ошибка. Там не указан Type Hinting, что в свою очередь сводит на нет все прелести IoC и превращает работу на подобие работы с глобальными переменными.

[Kir ---]

Это я говорю про Symfony\Component\DependencyInjection\Container

[cystbear]

SowingSadness

symfony.com/doc/current/book/security.html
symfony.com/doc/current/cookbook/security/acl.html

Возможность использовать ACL есть, но «искаропки» идет система ролей
symfony.com/doc/current/book/security.html#roles

я не холиварю, просто пытаюсь понять.
Вот даже нагуглил бандл по-быстрому github.com/opensky/LdapBundle

[cystbear]

И иерархия ролей есть.

[Kir ---]

cystbear Вы уверены, что верно понимаете RBAC?

RBAC отличается от списков контроля доступа (англ. access control lists, ACL), используемых в традиционных избирательных системах управления доступом, тем, что может давать привилегии на сложные операции с составными данными, а не только на атомарные операции с низкоуровневыми объектами данных. Например, список контроля доступа может предоставить или лишить права записи в такой-то системный файл, но он не может ограничить то, каким образом этот файл может быть изменен. Система, основанная на RBAC, позволяет создать такую операцию как открытие «кредита» в финансовом приложении или заполнение записи «тест на уровень сахара в крови» в медицинском приложении. Присвоение привилегии на выполнение такой-либо операции многозначно, так как операции являются дробящимися в пределах приложения.

[Kir ---]

На самом деле, в sf2 очень тяжело создать RBAC, т.к. там вся идеология построена на том, что бы бизнес-логику писать в контроллерах(это один из самых больших провалов sf2)
А в связи с этим фактом вытекает следующее, что:
— все операции производятся в Action
— Action контролируются с помощью ACL
— Action очень жестко завязан на Request
— Одна и та же операция может быть реализована во многих Action.
— операция может быть раздроблена между несколькими Action.
— невозможно с помощью механизмов sf2 контролировать операцию, лишь Action.

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

Но мы можем пойти и отдать письмо прям на почту. Или же довести его сами.
Так вот RBAC проверяет всю операцию целиком. Каким бы способами мы не пытались это сделать.
Даже если мы ещё какой то способ выдумаем позже, RBAC будет это контролировать.

[cystbear]

Интересный пример.

Не могу ничего сказать против, но есть пара уточняющих моментов:

sf2 это HTTP Request-Response фреймворк, а ещё MVCS (аля Grails) по идеологии бизнес-логика должна быть в сервисах, а контроллеры/экшены должны её вызывать. Так и тестировать легче возможно.

Когда-то даже себе сделал такое
Controllers Pray

Take request
~~~~~~~~~
Create form
Bind form
~~~~~~~~~
Call one service method
Send response

сеция ~~~ необязательная

Action очень жестко завязан на Request

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

Окей, а что есть тогда симфонийские роли?

PS
прошу помнить — я не холиварю.

[Kir ---]

Часть бизнес-логики несомненно лежит на сервисах.
А часть логики, может лежать даже на банальном extension для twig. Например, переключение видов представления информации. RBAC может обеспечить получение extension'ом прав для отображения видов, которые он может предложить пользователю.

ACL везде прикручивать — повесишься.

Answer 5

[wartur]

Автору топика за поднятый вопрос благодарность. Сам пишу на Yii уже около полу года. Всем советую. Легко, просто, практично, все есть, куча сторонних модулей (в моем проекте их более 3-х, сэкономлено минимум 2-3 недели работы)

На данный топик наткнулся, что бы узнать не созрел ли я для более «мощных» академических фреймворков вроде SF2 или ZF2 и судя по отзывам понял кое-что для себя.

Так же скажу, что ZF2 мне не нравится из-за тяжести (как минимум минимум в 2 раза медленнее запускается ядро), и «многословность» (уж очень много писанины надо генерировать в коде)

Comments

[tamtakoe]

Скачал вчера три этих фреймворка и просто посмотрел поверхностно. У Зенда самый многословный код. У Симфони такая структура папок, что не понятно, как такое могло кому-то прийти в голову в здравом уме. Юи пока самый понятный

[Kir ---]

Советую дальше работать с Yii и радоваться жизни :)
В ZF2 и Sf2 не более «мощные», они более мудреные, при этом без пользы делу.

[wartur]

Кстати, не знаю как делается паттерн service layer в Sf2, но в Yii я это сделал такую структуру в моделях, схожую с тем как это делается в ZF2.

/model
/model/activeRecords
/model/activeRecords/domain1/*.php
/model/activeRecords/.../*.php
/model/activeRecords/domainN/*.php
/model/serviceLayer/
/model/serviceLayer/*.php
/model/forms/*.php

Проект уже работает с 2-мя интерфейсами (веб и мобильники) и 3-мя базами данных и не скажу, что акдемичности Yii не хватает, и код чем-то засран. Покрытие тестами делается запросто, не знаю о чем там все говорят и почему из-за app::yii это проблема. Да не рекомендуется App::yii юзать внутри моделей, желательно выносить любое взаимодействие с сессией на интерфейсы service layer.

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

[des1roer]

по поводу тяжеловесности. hello wolrd без ничего на sf2 кушает 8.8 мб, а стартовая страница yii2 в 2 раза меньше

Answer 6

[des1roer]

yii первоначально мне не очень понравился своей документацией. msdn по сравнению с ним боги. но вклиниваясь в тему нравиться он мне стал все больше и больше (другие правда не юзал)

Answer 7

[tamtakoe]

Inori, как понимаю, вы поддерживаете и даже продвигаете simfony среди разработчиков. Почему бы вам не разобраться в причинах недопонимания SowingSadness и не написать на основе этого несколько разъяснительных статей? Так же то, что все вокруг твердят о высоком пороге вхождения, должно быть хорошим звоночком, который намекает, что в т. ч. и вы недостаточно потрудились, чтобы его снизить. Порог ведь определяется только на половину архитектурой, а на другую — работой комьюнити и наличию адекватного материала: примерами, решением популярных проблем, открытыми проектами. Порой, один человек может так разжевать и популяризовать технологию, что ей все начинают пользоваться, несмотря на какие-то недостатки. Надеюсь, что в simfony таким человеком станете вы и мы будем вам благодарны!

Comments

[Inori]

habrahabr.ru/qa/16766/#answer_97322

[wartur]

Автору топика за поднятый вопрос благодарность. Сам пишу на Yii уже около полу года. Всем советую. Легко, просто, практично, все есть, куча сторонних модулей (в моем проекте их более 3-х, сэкономлено минимум 2-3 недели работы)

На данный топик наткнулся, что бы узнать не созрел ли я для более «мощных» академических фреймворков вроде SF2 или ZF2 и судя по отзывам понял кое-что для себя.

Так же скажу, что ZF2 мне не нравится из-за тяжести (как минимум минимум в 2 раза медленнее запускается ядро), и «многословность» (уж очень много писанины надо генерировать в коде)

[wartur]

ошибко, да ШтоШ такое, постоянно промахиваюсь!!!

[Kir ---]

Inori Снимаются вопросы по тому, как предполагается использвоание Symfony в проектах.
Все претензии к плохой архитектуре, остаются.

Answer 8

[cystbear]

Так вот RBAC проверяет всю операцию целиком. Каким бы способами мы не пытались это сделать.

то есть получается для RBAC нам нужно определить/сделать/описать высокоуровневые/абстрактные задачи. Например отправка письма, так?

Comments

[Kir ---]

Скажем так: «И это тоже можно сделать с RBAC.»
Т.е. RBAC охватывает более широкий круг задач, нежели чем ACL.

Answer 9

[Василий Норман]

Реализацию проверки прав доступа в Symfony2 удобно делать используя Voter'ы. По моему даже удобнее и гибче, чем RBAC. symfony.com/doc/current/security/voters.html