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

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

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

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

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

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

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

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

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

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

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

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

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

Вы эту статью сами-то читали?
Он описывает типичные ошибки новичков (а ля использование 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.

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

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

Спасибо за отзыв.
Т.е. я так понимаю основной плюс 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. И это без изменения кода моделей и контроллеров.

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

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

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

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

Любителям 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

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

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

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

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

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

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 Вы уверены, что верно понимаете RBAC?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кстати, не знаю как делается паттерн 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.

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

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

habrahabr.ru/qa/16766/#answer_97322

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

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

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

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

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

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