Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 58
ух, писать на джаве, используя PHP — это круто.
Такая ситуация складывается ровно потому, что на это есть спрос. Бизнес с удовольствием заказывает большие и сложные вещи на PHP потому, что PHP разработчиков много и они стоят относительно недорого. А мир PHP уже подстраивается под бизнес.
И да, я тоже считаю странным использовать такую махину, как Symfony 2 для простых «бложиков».
И да, я тоже считаю странным использовать такую махину, как Symfony 2 для простых «бложиков».
Мы довольно сложные штуки строим на Yii без тонн аннотаций и контейнеров. Ну ведь реально проще чуть порефакторить код когда надо, а не усложнять до такого состояния, что новому человеку в команде проще повеситься сразу.
Может быть. Сам я с Yii не сталкивался, сейчас работаю как раз с Symfony 2 и мы тоже с тоннами аннотаций не заморачиваемся и пишем проще :)
Нужно понимать что ситации бывают разные:
Если вы пишете для конечного заказчика, тогда я с вами согласен
Если же для комьюнити или библиотечный код то ситуация противоположная
Если вы пишете для конечного заказчика, тогда я с вами согласен
Если же для комьюнити или библиотечный код то ситуация противоположная
Ситуация не меняется. Нужно использовать паттерны под задачу, нужно решать с их помощью задачу, а не всовывать их везде куда только можно
Сложно не согласиться с утрирждением, что нужно быть умным, а не глупым
Есть ОЧЕНЬ мало ситуаций когда нужен именно DI\IoC. В большинстве случаев достаточно SM
Вот это дествительно спорно
Если предположить что DI\IoC используеться в основном для улучшения тестирования кода и уменьшения связаности/зависимостей на состояние, то станет понятно где они не нужны — в
Может это Ваш случай, для меня верно обратное
стало называть синглтон антипаттерном, и создавать сотни абстрактных классов что бы избавиться от пары глобальных.
Вы наверно путаете: разбиение на класы (не в коем случаи абстрактные — это тоже антипатерн) нужен исходя из принципа минимизации ответсвености, а избаление от синглетонов продиктовано необходимость во-первых явго указывать зависимости, и во-вторых уменьшением зависимостей, что очень сложно без первого
еще раз повтою, что в проекте где все изначально спланировано == «небольших», часто такой подход еконимически приемлем
В Yii 2 не планируется Di?
Это упоминается в заключении. Сайт-блог рассматривается в качестве примера только потому, что он понятен большинству веб-разработчков. Для подобных сайтов в PHP есть множество других простых фреймворков и CMS'ок.
Дело в том, что и для проектов побольше и даже для самых крупных отлично живётся без неумеренного использования DIC.
Как Вы думаете, зачем тогда его вообще придумали, раз без него так отлично живется?) И почему его так активно используют в своей архитектуре symfony, yii, zend и другие большие проекты? Лично мне кажется, при разработке действительно сложных проектов, имеющих огромное количество связанных классов, лучше использовать проверенные архитектурные решения.
Самое интересное, Doctrine не позволит вам использовать NoSQL, а при переходе на Propel, придется многое переделывать.
Doctrine ведь MongoDB поддерживает. Я, правда, не пробовал эту поддержку, может она и плохо работает, но она заявлена.
А что конкретно вы подразумеваете под Doctrine? ORM, ODM, DBAL?
MongoDB: github.com/doctrine/mongodb-odm
CouchDB: github.com/doctrine/couchdb-odm
OrientDB: github.com/doctrine/orientdb-odm
PHPCR: github.com/doctrine/phpcr-odm
Из лично проверенных: поддержка MongoDB стабильна, есть проекты в продакшне.
CouchDB: github.com/doctrine/couchdb-odm
OrientDB: github.com/doctrine/orientdb-odm
PHPCR: github.com/doctrine/phpcr-odm
Из лично проверенных: поддержка MongoDB стабильна, есть проекты в продакшне.
Самое интересное что Расмус видит развитие PHP совершенно в другой области.
Просветите же!
Спасибо, как раз вовремя.
Как вы отслеживаете целостность ссылок?
$blog->addPost($post);
$post->setBlog($blog2);
жесть
и все ради того что, когда-то, что-то, возможно нам понадобится… паттерны в топку DI наше все
чем строить всю эту чушь из тон абстракций типа MyFactoryOfYourFactoriesOfVendorFactoriesForPhpGetRequest легче окружение настроить для PHP
это даже не Java, в ней есть хотя бы поддержка аннотаций, а здесь черт знает что… чего нет в языке сделаем в виде строк и распарсим
и все ради того что, когда-то, что-то, возможно нам понадобится… паттерны в топку DI наше все
чем строить всю эту чушь из тон абстракций типа MyFactoryOfYourFactoriesOfVendorFactoriesForPhpGetRequest легче окружение настроить для PHP
это даже не Java, в ней есть хотя бы поддержка аннотаций, а здесь черт знает что… чего нет в языке сделаем в виде строк и распарсим
как по мне — перегиб.
контроллер как сервис, шаблонизатор как сервис, орм как сервис, каждая сущность как сервис, хэлпер вьюхи как сервис для вьюхи, сам бложек как сервис для самого себя. отчасти оно оправдано и удобно, но во многих мануалах получается эадкий сервис ради сервиса — почти ООП ради ООП. эта изолированность зачастую вносит ненужные усложнения в понимание. схема работы получается простой, да. но чтоб понять всю ее простоту надо осмыслить больше, чем чтоб понять что-то на 10-15% более сложное.
и эти аннотации. нет, это безумно круто, что часть логики формирования ответа перенести в аннотацию, но у меня возникает следующий вопрос: имеем сложное приложение, где всё сделано фэншуйненько-аннотационно. роуты, кеширование, переменные в шаблон и т.д. даже AOP заюзаем для красоты. как мне при всём этой буйстве найти какой контроллер отвечает за урл /example/test? поиском строки по проекту?
контроллер как сервис, шаблонизатор как сервис, орм как сервис, каждая сущность как сервис, хэлпер вьюхи как сервис для вьюхи, сам бложек как сервис для самого себя. отчасти оно оправдано и удобно, но во многих мануалах получается эадкий сервис ради сервиса — почти ООП ради ООП. эта изолированность зачастую вносит ненужные усложнения в понимание. схема работы получается простой, да. но чтоб понять всю ее простоту надо осмыслить больше, чем чтоб понять что-то на 10-15% более сложное.
и эти аннотации. нет, это безумно круто, что часть логики формирования ответа перенести в аннотацию, но у меня возникает следующий вопрос: имеем сложное приложение, где всё сделано фэншуйненько-аннотационно. роуты, кеширование, переменные в шаблон и т.д. даже AOP заюзаем для красоты. как мне при всём этой буйстве найти какой контроллер отвечает за урл /example/test? поиском строки по проекту?
В симфони 2 в режиме разработки внизу экрана есть панель где это написано, а при переходе в профайлер информации вообще море.
Либо с командной строки можно использовать команду
Либо с командной строки можно использовать команду
app/console router:debug <название маршрута>
Почему минусуют? Когда проект маленький можно все и в одном файле держать. В симфони это есть кстати, причем можно хранить все роуты в yml, xml или php формате на выбор.
Но когда проект большой удобней хранить роуты в каждом бандле отдельно или в аннотациях. Найти потом роут, как уже написали, легко через router:debug. И кстати поиск строки или регулярки по проекту (или поиск файлов/классов) при поддержке чужого кода по-моему самое популярное действие.
Для примера в статье симфони конечно использовать мало смысла, но на то он и пример, чтобы на понятных задачах показывать функционал. И все это кстати не обязательно знать совсем чтобы написать серьезный проект, у симфони очень хорошая документация. А в дебри всегда можно зайти xdebug-ом.
Но когда проект большой удобней хранить роуты в каждом бандле отдельно или в аннотациях. Найти потом роут, как уже написали, легко через router:debug. И кстати поиск строки или регулярки по проекту (или поиск файлов/классов) при поддержке чужого кода по-моему самое популярное действие.
Для примера в статье симфони конечно использовать мало смысла, но на то он и пример, чтобы на понятных задачах показывать функционал. И все это кстати не обязательно знать совсем чтобы написать серьезный проект, у симфони очень хорошая документация. А в дебри всегда можно зайти xdebug-ом.
1. Во-первых заключение надо было поставить в начало, так как судя по комментариям, большинство прочитало статью по-диагонали и у них сработал спинномозговой рефлекс про жаву, ооп головного мозга итд.
2. Пример неудачен, с количеством сервисов дикий перегиб.
Если бы мне при выборе фреймворка попалась на глаза эта статья, я бы ни за что не перешел на symfony2. К счастью я просто поставил Yii, сделал пару проектов, затем поставил symfony2 и сделал другой проект, желания на Yii возвращаться не было.
Уверяю что в обычном процессе разработки на симфони, нет необходимости в большей части того что написано в статье.
2. Пример неудачен, с количеством сервисов дикий перегиб.
Если бы мне при выборе фреймворка попалась на глаза эта статья, я бы ни за что не перешел на symfony2. К счастью я просто поставил Yii, сделал пару проектов, затем поставил symfony2 и сделал другой проект, желания на Yii возвращаться не было.
Уверяю что в обычном процессе разработки на симфони, нет необходимости в большей части того что написано в статье.
| Уверяю что в обычном процессе разработки на симфони, нет необходимости в большей части того что написано в статье.
Тогда в чем смысл использовать Sf2 вместо Yii?
Тогда в чем смысл использовать Sf2 вместо Yii?
| Тогда в чем смысл использовать Sf2 вместо Yii?
В чём смысл использовать %framework1% вместо %framework2%?
В чём смысл использовать %framework1% вместо %framework2%?
Мы используем %framework1% потому что у него есть такие приемущества:
— А
— Б
— В
— Г
но, мы ими не пользуемся…
— А
— Б
— В
— Г
но, мы ими не пользуемся…
Я это к тому, что очень часто сталкиваешься с ситуацией, когда приходится поддерживать говнокод проект, написанный задолго до тебя, на старте которого %framework2% был наилучшим решением. Переписать всё это на %framework1% было бы лучшим решением, но выделит ли бизнес на это over 9000 человеко-часов? Вряд ли.
То-то и оно.
То-то и оно.
Смотрите. Я писал проекты и на Yii и на Sf2. Приемущество второго, очень сомнительна, я серьёзно.
Задач, которые бы сложнее решались или не решались бы на Yii я не встречал.
Вот поэтому закрадывается вопрос, зачем люди выбирают Sf2, если не используют его сильные стороны, при существующих в нём из-за инх(сильных сторон) недостатков?
Задач, которые бы сложнее решались или не решались бы на Yii я не встречал.
Вот поэтому закрадывается вопрос, зачем люди выбирают Sf2, если не используют его сильные стороны, при существующих в нём из-за инх(сильных сторон) недостатков?
То есть в остальном это одинаковые фреймворки? На такие попытки набросить на вентилятор даже реагировать лень… ладно, благо делать нечего и в интернете как всегда кто то не прав :)
— А: Doctrine идет почти-что изкаропки, хорошо интегрирован. Также я сторонник DataMapper.
— Б: Легче покрывать тестами
— В: Продвинутый DI (но без фанатичного использования как в этой статье)
— Г: Прекрасная библиотека для форм, мощная, продуманная, и отлично интегрированная с ORM.
— Д: Symfony2 идет в ногу с прогрессом, composer, поддержка и использование фич из последних версий PHP5.
— Е: Модульность и низкая связанность.
— Ж: Фантастические возможности в плане конфигурируемости и переопределения функционала.
— З: Поддержка в IDE
— И: Аннотации
— Й: Twig
Думаю хватит, но могу дойти и до конца алфавита.
Здесь преимущества которые я нашел в Symfony2 но не нашел в Yii. Если вы не согласны с тем что это преимущество и хотите меня убедить что яблоко вкуснее груши — не тратьте время, я не собираюсь превращать эту ветку в habrahabr.ru/qa/16766/#answer_82655 habrahabr.ru/qa/23597/#answer_96664, я в курсе вашей священной войны ;)
Естественно есть и недостатки, assetic не исправляет путь к изображениям в css до сих пор, в документации был нерабочий пример динамических форм (сейчас исправлен), до сих пор непонятно куда класть 3-rd party js библиотеки — единого мнения нет, ну и много других минусов по мелочи, но работе это не мешает, да и покажите мне фреймворк без недостатков.
— А: Doctrine идет почти-что изкаропки, хорошо интегрирован. Также я сторонник DataMapper.
— Б: Легче покрывать тестами
— В: Продвинутый DI (но без фанатичного использования как в этой статье)
— Г: Прекрасная библиотека для форм, мощная, продуманная, и отлично интегрированная с ORM.
— Д: Symfony2 идет в ногу с прогрессом, composer, поддержка и использование фич из последних версий PHP5.
— Е: Модульность и низкая связанность.
— Ж: Фантастические возможности в плане конфигурируемости и переопределения функционала.
— З: Поддержка в IDE
— И: Аннотации
— Й: Twig
Думаю хватит, но могу дойти и до конца алфавита.
Здесь преимущества которые я нашел в Symfony2 но не нашел в Yii. Если вы не согласны с тем что это преимущество и хотите меня убедить что яблоко вкуснее груши — не тратьте время, я не собираюсь превращать эту ветку в habrahabr.ru/qa/16766/#answer_82655 habrahabr.ru/qa/23597/#answer_96664, я в курсе вашей священной войны ;)
Естественно есть и недостатки, assetic не исправляет путь к изображениям в css до сих пор, в документации был нерабочий пример динамических форм (сейчас исправлен), до сих пор непонятно куда класть 3-rd party js библиотеки — единого мнения нет, ну и много других минусов по мелочи, но работе это не мешает, да и покажите мне фреймворк без недостатков.
А в чем смысл использования Yii перед Sf2?
Меньше заморочек, понятней новичкам, быстрее из коробки. Как результат, дешевле обходится на нём делать проект.
Хотелось бы больше конкретики от одного из создателей Yii. Все эти 'понятней, меньше заморочек' это все очень субъективные и не сильно поддающиеся формализации признаки. Насчет 'дешевле' это вообще несколько наивно. Во-первых я сомневаюсь что хороший разработчик на Yii дешевле хорошего разработчика на symfony. Во-вторых для больших проектов основное время разработчика занимает продумывание архитектуры, написание кода слабо зависящего от фреймворка, написание тестов. Возможно ниша Yii в небольших проектах? Но тут сразу налетит много конкурирующих фреймворков, а symfony разработчик может взять silex c привычными ему компонентами и быстренько настрогать небольшой сайт. Вообщем извините, но не убедительно.
А какая тут вообще может быть формализация? Количество использованных паттернов? Покрытие тестами? Скорость работы «hello world»?
Большие проекты, как показала практика, отлично делаются без DIC и непонятно зачем нужного во многих случаях decoupling (те же моки отлично решают проблему с тестами). Просто рефакторить надо постоянно, а не заранее наворачивать сверх меры. Кстати, само определение «большие» очень расплывчато. В некоторых проектах из тех, в которых доводилось поучаствовать внутри всё просто как пробка, но проекты определённо большие: более 3-х миллионов пользователей и дофига данных. Ну и кода много, конечно, но он весь ну очень простой.
Про «дешевле» это исключительно опыт (я собирал и частично обучал команду компании CleverTech) и здравый смысл. Стоимость складывается из гонорара и времени на обучение. Дешевле выявить обучаемого начинающего и дообучить, чем брать опытных дорогих разработчиков, которые на одном проекте в количестве больше двух не могут частенько ужиться. Да и рутину надо кому-то делать. Опытному разработчику от рутины быстро станет скучно.
Ниша Yii в проектах, где не нужны сложности уровня Symfony 2. Основные конкуренты Yii были как раз Zend 1 и symfony 1. Но первые версии уже угасают, а вторые ушли в решения аля «Enterprise», слизанные из J2EE. Нам это направление не особо интересно. Плюс, конечно, Kohana, CI и Cake, но у них есть ощутимые недостатки. Так что Symfony 2 и Zend сделали нам хороший такой подарок в прошлом году.
Большие проекты, как показала практика, отлично делаются без DIC и непонятно зачем нужного во многих случаях decoupling (те же моки отлично решают проблему с тестами). Просто рефакторить надо постоянно, а не заранее наворачивать сверх меры. Кстати, само определение «большие» очень расплывчато. В некоторых проектах из тех, в которых доводилось поучаствовать внутри всё просто как пробка, но проекты определённо большие: более 3-х миллионов пользователей и дофига данных. Ну и кода много, конечно, но он весь ну очень простой.
Про «дешевле» это исключительно опыт (я собирал и частично обучал команду компании CleverTech) и здравый смысл. Стоимость складывается из гонорара и времени на обучение. Дешевле выявить обучаемого начинающего и дообучить, чем брать опытных дорогих разработчиков, которые на одном проекте в количестве больше двух не могут частенько ужиться. Да и рутину надо кому-то делать. Опытному разработчику от рутины быстро станет скучно.
Ниша Yii в проектах, где не нужны сложности уровня Symfony 2. Основные конкуренты Yii были как раз Zend 1 и symfony 1. Но первые версии уже угасают, а вторые ушли в решения аля «Enterprise», слизанные из J2EE. Нам это направление не особо интересно. Плюс, конечно, Kohana, CI и Cake, но у них есть ощутимые недостатки. Так что Symfony 2 и Zend сделали нам хороший такой подарок в прошлом году.
А чем ZF 2 и Symfony 2 сложней и навороченей, если убрать DIC?
Ну, например, в них делается большой акцент на используемые паттерны, названия которых частенько встречаются в классах. Пока что не знакомый на должном уровне новичок от таких названий офигеет и вместо того, чтобы просто начать пользоваться полезет читать Фаулера, Гамму и ко., а сходу они не очень хорошо даются.
Также некоторые компоненты (как минимум security) в Symfony 2 даже довольно опытных разработчиков заставляют разбираться в них неделями.
Ну и, наконец, в чём смысл выбирать фреймворк и не пользоваться его фичами?
Также некоторые компоненты (как минимум security) в Symfony 2 даже довольно опытных разработчиков заставляют разбираться в них неделями.
Ну и, наконец, в чём смысл выбирать фреймворк и не пользоваться его фичами?
SamDark, простота и функциональность(в вашем понимании) из коробки это замечательно. Но есть еще и третий фактор без которого использование фреймворка теряет всякий смысл в больших проектах, счас это называется fig-standards. Сколько я не пытался понять логику Yii(а пробовал раза 4 точно), мне не хватало терпения видя что-то вроде этого pastebin.com/PLZvXPQC где не то что элементарные пробелы, кавычки, скобки не расставлены, так еще переменные именуются в стиле $a, $b_, $_x, $__z.
И тут как раз decoupling помогает — возьму ка я пару компонентов с Symfony, пару с Zend, пару с вообще отдельных репозитариев, подключу UniversalClassLoader(или напишу за полчаса класс на основе Proxy паттерна) и все работает явно(!), понятно что где лежит и как инициализируется.
Вот это называется простота и функциональность, где есть стандарт общий(!)
А Yii это солянка и простота его мнимая, т.е. ты либо знаешь полностью фреймворк, либо в комманде придеться туго.
И тут как раз decoupling помогает — возьму ка я пару компонентов с Symfony, пару с Zend, пару с вообще отдельных репозитариев, подключу UniversalClassLoader(или напишу за полчаса класс на основе Proxy паттерна) и все работает явно(!), понятно что где лежит и как инициализируется.
Вот это называется простота и функциональность, где есть стандарт общий(!)
А Yii это солянка и простота его мнимая, т.е. ты либо знаешь полностью фреймворк, либо в комманде придеться туго.
Стандарт кодирования в Yii 1.1 да, не очень. В Yii 2 будет лучше, хоть и не PSR-2, который ну совсем субъективен и некоторые моменты просто подточены под Symfony 2, также как и последующие PSR.
Взять компоненты из Symfony, Zend и чего угодно можно и в Yii 1.1. Знать фреймворк конечно надо. А солянка, как по мне, начнётся если каждый начнёт тянуть в проект библиотеки, которые он знает. Так недолго до использования пары-тройки библиотек для работы с SQL в одном проекте.
Я всё это уже наблюдал когда работал с J2EE.
Взять компоненты из Symfony, Zend и чего угодно можно и в Yii 1.1. Знать фреймворк конечно надо. А солянка, как по мне, начнётся если каждый начнёт тянуть в проект библиотеки, которые он знает. Так недолго до использования пары-тройки библиотек для работы с SQL в одном проекте.
Я всё это уже наблюдал когда работал с J2EE.
Это хорошо что вы осознаете что стиль кода Yii это проблема (большая! и не только субъективно для меня). Но причем тут Symfony2 (вообще то я им в целом не пользуюсь и идеологии не поддерживаю habrahabr.ru/post/165237/#comment_5695853 )? www.php-fig.org/ здесь есть список какие люди с каких проектов участвуют в разработке.
>> А солянка, как по мне, начнётся если каждый начнёт тянуть в проект библиотеки, которые он знает //
Вы когда начинаете работать над проектом командой, вы же договариваетесь что будете использовать какой то фреймворк. Так в чем проблема договорится о библиотеках? (J2EE != PHP libs, далеко не равно)
>> А солянка, как по мне, начнётся если каждый начнёт тянуть в проект библиотеки, которые он знает //
Вы когда начинаете работать над проектом командой, вы же договариваетесь что будете использовать какой то фреймворк. Так в чем проблема договорится о библиотеках? (J2EE != PHP libs, далеко не равно)
Не понял, вы считаете что это плохо когда человек пробегается по основам ООП, прежде чем тратить чужие деньги браться писать проекты?
Если бы только по основам…
А что вы там такого сложного нашли?
Ну, у меня, например, в голове не сразу сложилось однозначное мнение про каждый из паттернов и понимание, когда что применять. Прочтение Гаммы, конечно, помогло, но переваривал я информацию довольно долго и мозг срывало в процессе неслабо. Данное занятие, насколько помню, хорошенько понизило мою производительность в то время. Если бы это был дедлайн, я бы наверняка его завалил и хорошенько получил бы по шапке от старших.
Спасибо автору. Все четко и понято. Отличный пост.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Руководство по использованию Dependency Injection в Symfony2