Это я понимаю и видел много примеров уровня «hello word». Интересно бы было посмотреть тесты из реального приложения, желательно большого и со сложной бизнес логикой. Буду рад, если сможете показать куски кода из каких-нибудь ваших проектов или дадите ссылку на статью, где это приводится.
А не могли бы привести пример в виде кода? Меня даже больше интересует не сам DI — с ним более менее ясно, а тесты. Что именно тестируется и как. Давно ищу какую-нибудь толковую статью по тестированию ZF2. Интересуют тесты не самого ZF2, а бизнес логики, конечно.
>>>А теперь, если возьмем средний рейт разработчика 20 долларов в час и посчитаем
>>>сколько стоит «В зенде вы точно так же можете написать свой тип маршрута».
Посчитали? Что получилось? 2.5$? Круто, осталось учесть, что врядли кто-то действительно потратит на него своё время — он просто никому не нужен, кроме фанатов РоР. Но фанаты и так уже пишут на рельсах.
>>>Вам не кажется что, это такой древний русский подход,
>>>предусматривающий фазу тщательной обработки напильником?
Не кажется. Зенд даёт инструменты, а не готовые решения.
А вообще если так рассуждать — то почему вы пишете на РоР, а не на каком-нибудь друпале или ворпрессе? Там же ещё меньше делать надо.
>>>Мнение основано на личных стереотипах.
Мнение основано на личном опыте, опыте коллег а так же по листу рассылки ZF — там тоже никто никогда, на моей памяти, не предлагал включить копию какого-то маршрута из РоР. Видимо он всё таки никому не нужен.
>>>Ну если так, посмотрите ещё на симфоневский роутинг. Он тоже лучше.
Смотрел. Чем лучше? Почему вы постоянно делаете голословные утверждения?
Ок, без проблем. Я понимаю позицию рельс разработчиков но мне совершенно не нравиться подход применямый в рельсах и уже тем более не нравиться, когда пытаются упрекнуть зенд в том, что он не рельсы.
Я смотрю на зенд приложения каждый день. Не первом зенде многие приложения вообще обходятся одним маршрутом по умолчанию.
Вопрос логики в построении маршрутов — это вопрос программиста, который проектирует приложение, но никак не фреймворка.
Вы не поняли, на что надо потратить 3.
Их надо потратить не на то, чтобы написать 7 маршрутов для одного ресурса, а на то, чтобы написать один класс наслединк Zend\Mvc\Router\Http\Segment, назвать его «Resource» и потом пользоваться им так же, как вы пользуетесь в РоР: 'albums' => ['type' => 'resource']
Всё. Этот код включает в себя 7 маршрутов и вложенные маршруты при надобности. И его можно использовать для маршрутизации по любым ресурсам.
Ещё раз — это частное решение почему-то очень полюбившееся разработчиком на рельсах. Вообще не понимаю, почему оно столько раз упоминается в этой теме.
Хорошее это или плохое — это дело вкуса, но никак не объективных плюсов или минусов подхода. Мне, например, такой подход в принципе не нравится, так что то, что его нет в стандартной поставке — плюс. А те, кому он нужен, потратят 3 минуты своего времи и сами его реализуют.
Рельсы — набор хорошо скомпонованных и подогнаных друг к другу спорных решений. Если в целом ты не против этих решений (взять тот же ActiveRecord, например) — то рельсы дают много плюшек и сильно сокращают время разработки. Но если ты против какого-то из них — усилия на изменение будут гораздо выше, чем в том же зенде.
В общем рельсы решают частный случай какой-то проблемы, зенд — решает общий случай, а частности оставляет за программистом.
Это не ключевая штука, это частный случай маршрутизации. Он, видимо, очень удобен для фанатов РоР, но от этого он не перестаёт быть маленьким частным случаем. К тому же на зенде он воспроизовдиться за несколько минут.
Почему вы его называется «ключевым»?
Зенд не даёт готовых красивых маршрутов. Зенд даёт иструменты для построения любой (абсолютно любой) маршрутизации, не отдавая при этом предпочтения какому-то конкретному способу.
>>>ресурс = view + list + edit + update + new + create + delete с параметрами для них по умолчанию
Почему все рубисты в этом посте жалуются на то, что роутер зенда — это не роутер РоР? Да, он действительно другой, но почему это считается за минус?
И да, не обязательно описывать каждый суброут по отдельности, достаточно написать один раз и пользоваться для любого ресурса — habrahabr.ru/post/150984/#comment_5120061
Но этот маршрут нужен только любителям РоР, так что его нет в дефолтной поставке.
Огромное количество вложений в массивах конфигах — сейчас есть только в роутере и только если у вас древовидная структура.
Новая архитектура форм — слегка непривычна в начале, но удобней чем старая. Преимущества раскрываются на больших формах и на большом количестве маленьких форм с пересекающимеся полями (можно написать один филдсет а потом просто включать нужные поля).
Гибкость ZF2 не только сохранил, но и улучшил — благодаря событиям и сервис менеждеру менять можно вообще что угодно (раньше MVC часть, например, расширялась не очень удобно)
В общем если вам нравиться ZF1 — почти наверняка понравитсья и ZF2.
DI в ZF2 практически не используется (вообще не встречал в коде начиная с beta3, кажется). Если вы не смотрели фрейморк со времен первых бет — советую посмотреть, там много чего изменилось в лучшую сторону.
Ну и по поводу этого:
>>>Если это не преимущество, а круто писать многомерные массивы с кучей конфиг-значений,
>>>то скорее всего вам платят за кол-во строчек кода.
Не стоит переходить на личности — я сейчас тоже могу предположить что вы просто не осилили роутер зенда и вам проще, когда дают готовый набор правил, как в РоРе и не надо думать своей головой. Но после этого диалог, скорее всего, кончится и начнётся срач.
Так что давайте не будем переходить на личности и попытаемся просто разобрать плюсы и минусы разных подходов, ок?
Это не преимущество, это всего лишь форма записи маршрута. Возможнао она удобна для вас (возможно даже для многих рубистов), но объективно она не лучше и не хуже зендовской.
В зенде вы точно так же можете написать свой тип маршрута (скорее всего просто расширив уже имеющийся segment), определить для него свой тип записи и набор правил и потом пользоваться так же:
Просто это частный случай решения проблемы и за пределами рельсов, видимо, мало кому нужный (например для меня это довольно не удобный способ).
А вообще, мне кажется, вы не поняли идеологию зенда. Зенд не предоствляет готовых решений чтобы сделать блог за 15 минут. Зенд предоствляет хорошо спроектированные и легко расширяемые решения типовых задач.
При этом не пытается решить проблемы специфичные для какого-то конкретного проекта или удовлетворить вкус конкретного программиста, вместо этого он даёт инструменты для легкого изменения любой части фреймворка под свой вкус.
>>>сколько стоит «В зенде вы точно так же можете написать свой тип маршрута».
Посчитали? Что получилось? 2.5$? Круто, осталось учесть, что врядли кто-то действительно потратит на него своё время — он просто никому не нужен, кроме фанатов РоР. Но фанаты и так уже пишут на рельсах.
>>>Вам не кажется что, это такой древний русский подход,
>>>предусматривающий фазу тщательной обработки напильником?
Не кажется. Зенд даёт инструменты, а не готовые решения.
А вообще если так рассуждать — то почему вы пишете на РоР, а не на каком-нибудь друпале или ворпрессе? Там же ещё меньше делать надо.
>>>Мнение основано на личных стереотипах.
Мнение основано на личном опыте, опыте коллег а так же по листу рассылки ZF — там тоже никто никогда, на моей памяти, не предлагал включить копию какого-то маршрута из РоР. Видимо он всё таки никому не нужен.
>>>Ну если так, посмотрите ещё на симфоневский роутинг. Он тоже лучше.
Смотрел. Чем лучше? Почему вы постоянно делаете голословные утверждения?
Вопрос логики в построении маршрутов — это вопрос программиста, который проектирует приложение, но никак не фреймворка.
Вы не поняли, на что надо потратить 3.
Их надо потратить не на то, чтобы написать 7 маршрутов для одного ресурса, а на то, чтобы написать один класс наслединк Zend\Mvc\Router\Http\Segment, назвать его «Resource» и потом пользоваться им так же, как вы пользуетесь в РоР:
'albums' => ['type' => 'resource']Всё. Этот код включает в себя 7 маршрутов и вложенные маршруты при надобности. И его можно использовать для маршрутизации по любым ресурсам.
Ещё раз — это частное решение почему-то очень полюбившееся разработчиком на рельсах. Вообще не понимаю, почему оно столько раз упоминается в этой теме.
Рельсы — набор хорошо скомпонованных и подогнаных друг к другу спорных решений. Если в целом ты не против этих решений (взять тот же ActiveRecord, например) — то рельсы дают много плюшек и сильно сокращают время разработки. Но если ты против какого-то из них — усилия на изменение будут гораздо выше, чем в том же зенде.
В общем рельсы решают частный случай какой-то проблемы, зенд — решает общий случай, а частности оставляет за программистом.
Не могли бы здесь привести пример кода сложного маршрута и рассказать о его преимуществах?
Почему вы его называется «ключевым»?
Зенд не даёт готовых красивых маршрутов. Зенд даёт иструменты для построения любой (абсолютно любой) маршрутизации, не отдавая при этом предпочтения какому-то конкретному способу.
Пост прочитаю, спасибо.
Почему все рубисты в этом посте жалуются на то, что роутер зенда — это не роутер РоР? Да, он действительно другой, но почему это считается за минус?
И да, не обязательно описывать каждый суброут по отдельности, достаточно написать один раз и пользоваться для любого ресурса — habrahabr.ru/post/150984/#comment_5120061
Но этот маршрут нужен только любителям РоР, так что его нет в дефолтной поставке.
Новая архитектура форм — слегка непривычна в начале, но удобней чем старая. Преимущества раскрываются на больших формах и на большом количестве маленьких форм с пересекающимеся полями (можно написать один филдсет а потом просто включать нужные поля).
Гибкость ZF2 не только сохранил, но и улучшил — благодаря событиям и сервис менеждеру менять можно вообще что угодно (раньше MVC часть, например, расширялась не очень удобно)
В общем если вам нравиться ZF1 — почти наверняка понравитсья и ZF2.
>>>Если это не преимущество, а круто писать многомерные массивы с кучей конфиг-значений,
>>>то скорее всего вам платят за кол-во строчек кода.
Не стоит переходить на личности — я сейчас тоже могу предположить что вы просто не осилили роутер зенда и вам проще, когда дают готовый набор правил, как в РоРе и не надо думать своей головой. Но после этого диалог, скорее всего, кончится и начнётся срач.
Так что давайте не будем переходить на личности и попытаемся просто разобрать плюсы и минусы разных подходов, ок?
Но зачем? Это частное решение написание которого занимает 3 минуты рабочего времени. Зачем его пихать в основную поставку фреймворка?
В зенде вы точно так же можете написать свой тип маршрута (скорее всего просто расширив уже имеющийся segment), определить для него свой тип записи и набор правил и потом пользоваться так же:
'albums' => ['type' => 'resource']или'items' => ['type' => 'resource']Просто это частный случай решения проблемы и за пределами рельсов, видимо, мало кому нужный (например для меня это довольно не удобный способ).
А вообще, мне кажется, вы не поняли идеологию зенда. Зенд не предоствляет готовых решений чтобы сделать блог за 15 минут. Зенд предоствляет хорошо спроектированные и легко расширяемые решения типовых задач.
При этом не пытается решить проблемы специфичные для какого-то конкретного проекта или удовлетворить вкус конкретного программиста, вместо этого он даёт инструменты для легкого изменения любой части фреймворка под свой вкус.
Приведите пример того, что вы писали в любом последнем проекте — сразу будут видны и плюсы вашего подхода и его минусы.