Комментарии 46
1. Service oriented architecture
2. Module management system
3. Event driven programing
По моему Zend и Symfony на одном уровне.
Явные преимущества Zend-а:
Это не преимущества. Это просто названия. Поясните как именно zend лучше подходит для SOA (и что вы понимаете под этим, так, на всякий случай, ибо кто только что не имеет ввиду под этим термином), в чем отличие в плане модульности? И как лучше помогает мутить эвеншуал консистенси.
я не вижу преимуществ скажем перед symfony в этом плане. Там тоже все базируется на модульности и low coupling. Особенно если мы будем смотреть на symfony flex.
Я работал только с Symfony 2, поэтому, что сейчас там происходит мне сложно сказать. Какая-то информация и впечатления от использования у меня, конечно, сохранились. Я не впечатлился. Возможно, я не так его приготовил, зато, я считаю, что прекрасно приготовил Zend Framework. Мне намного комфортней работать с ним. Это выбор вкуса, а о вкусах не спорят. Особенно, если конечный результат от этого не зависит.
Это выбор вкуса, а о вкусах не спорят.
когда мы начинаем обсуждать субъективные штуки, вроде впечатлений о подключении модулей и т.д. мы уже выходим из категории объективных преимуществ того или иного решения.
Более того, вы не ответили на вопрос — как именно то что вы описали (что по большому счету субъективно) дает преимущества в виде: SOA, управление зависимостями, event driven?
Как по мне — никаких преимуществ, только вопросы вкуса. Их я поднимать не хочу ибо это в целом не имеет смысла. И я так же не хочу поднимать вопрос "кто лучше", меня конкретно интересовала ваша точка зрения по вышеозвученному вопросу (в частности — я все еще хочу узнать в контексте SOA в чем преимущества, ведь по идее вообще разницы нет).
По SOA Вы задавали вопрос не мне.
> в частности — я все еще хочу узнать в контексте SOA в чем преимущества, ведь по идее вообще разницы нет
Разница только в удобстве реализации для конкретной команды.
Объективное преимущество вытекающее из нашего диалога: ZF не нужен Flex.
ZF нужен component installer. Если вы ответите что он не нужен — то symfony тоже не нужен flex.
В моей заготовке тоже нет flex (пока-что во всяком случае). По поводу установки в 2 этапа (я так понимаю речь идет о дефолтных настройках модуля).
возьмем к примеру DoctrineORMModule и DoctrineORMBundle. Опустим момент с установкой самих пакетов так как они идентичны. В случае с zend мы регистрируем модуль в module.config.php, в случае с symfony мы регистрируем бандл в kernel.
Далее, в силу того что у нас нет роутинга, дальнейшее различия возникают лишь при конфигурировании модулей. В случае с Zend, мы добавляем конфигурацию на уровне наших модулей, в случае с Symfony мы полагаемся на конфигурацию приложения.
То есть, роль модуля Application в symfony играет Kernel. В связи с этим я вообще не вижу разницы во флоу установки модулей.
Так же как у вас может быть более одного модуля, выполняющего роль сервиса в контексте SOA например, вы можете иметь несколько кернелов (и это более чем нормальная практика). Дальше symfony вообще никак не регламентирует модульность проекта, полная свобода действий. Бандлы обычно для реюзабельных частей используются, а не для структурирования приложения.
Все эти объяснения мне дают понять лишь одно (если доверится Вам, т.к. сам я еще не проверил), то Symfony в этой же области, что и Zend Framework.
В Symfony есть моменты, которые мне не нравится, поэтому, я и другие люди со схожими взглядами выбрали Zend Framework. Это дело предпочтения, подхода и ощущений.
я указал, что он завязан на Symfony
так же как component installer завязан на zend. На связанность приложения это никак не сказывается.
Это дело предпочтения, подхода и ощущений.
Я полностью согласен, более того, я считаю что здоровая конкуренция никому не помешает. Но меня больше интересуют преимущества о которых говорит alo-blo.
однако возможно он имел ввиду преимущества перед laravel/yii и тогда в целом все логично.
Особенно если мы будем смотреть на symfony flex.
И какие плюсы он дает? Вы сейчас говорите как раз о завязках на фреймворке. В ZF есть Component Installer, хоть там и надо было всего добавить модуль в список (массив). В ZF не нужно было никогда (с версии 2.0):
- Регистрировать бандл (модуль) в app/AppKernel.php;
- Регистрировать маршруты, которые предоставляет бандл (модуль);
- Регистрировать настройки для бандла (модуля) в app/config/config.yml.
В ZF просто добавляется название модуля в config/module.config.php, например, ZfcTwig. На этом установка заканчивается. Естественно, нужно, чтобы этот модуль у вас был. Но это работа Composer и одна единственная команда.
И удаление также в 2 этапа: убираем из config/module.config.php. Удаляем через Composer.
Вы сейчас говорите как раз о завязках на фреймворке.
это плагин для composer который автоматизирует озвученную вами рутину. Вы можете работать как с ним, так и без него. Никакой завязки.
Он поможет как-то проекту написанному на Yii/Laravel/Zend?
Он поможет как-то проекту написанному на Yii/Laravel/Zend?
нет, но он невилирует описанные вами преимущества (в частности это по сути является тем же, что и zend component installer).
Вся привязка к симфони там сейчас только в рецептах, которые по понятным причинам есть только для симфони и околосимфонёвых проектов.
Но, насколько я знаю, можно писать и подключать свои рецепты
Надо отметить, что «написанному» проекту флекс никак не поможет. Даже написанному на симфони. Он помогает быстро стартовать новые проекты
По-моему он уже на пол пути к смерти. Symfony, особенно 3-4 версии значительно прибавил в развитии. Нету "реальных" причин выбирать Zend, когда есть Symfony.
Есть ли что то похожее на Zend Expressive? Не так давно искал — не нашел ничего…
Чем тогда решают схожие задачи, подпиской на kernel.request?
пс. сорри если не в тему
Чистая статистика вакансий в три раза больше на symfony, на zend в основном поддержка zf1-2 веб-приложений. Да и личное впечатление не очень.
Я начал писать на Zend как раз из-за
Разработчики языка PHP, создавшие Зенд
и был расстроен излишней сложностью и неочевидностью процесса разработки
Лично мне кажется, что Laravel это и есть php мир, каким он должен быть. Быстрое создание прототипов и запуск. Конкурент Rails. Но никак ни Spring как в случае Zend и Symfony, а с выходом Spring Boot вообще смысл в Symfony теряется, и сейчас фреймворк идет по принципу упрощения, и если вы посмотрите Symfony 4, минимализм в чистом виде.
А на счет "на пути к смерти", вот опрос хабра, где на вопрос
"На каком фреймворке вы бы начали следующий проект?" Zend получил 1.8%, и это по вашему не смерть?
И не удержусь от замечания — «опрос Хабра» это не заседание Госдепа США. Это ничего не значит. Судьбу Zend Framework решает не «Хабр» и его опросы.
Это все что мне есть сказать тебе на данный час )
ты изучил отчасти благодаря мне
Чувак, не обольщайся, я читал официальную доку, и даже не знал о существовании переводов.
Судьбу Zend Framework решает не «Хабр» и его опросы.
Как раз они и решают — люди. И чем меньше людей интересуются той или иной технологией тем скорее она умирает. Рейтинг stackoverflow, github или reddit еще более разгромен.
и был расстроен излишней сложностью и неочевидностью процесса разработки
Здесь более высокий уровень вхождения и преследования SOLID принципов, а не KISS, и не Worse is better. Разные подходы.
Laravel это и есть php мир, каким он должен быть. Быстрое создание прототипов и запуск
Когда устанете от "херак-херак и в продакшн" — welcome. =)
а с выходом Spring Boot вообще смысл в Symfony теряется
Spring — это, Java. Symfony — это, PHP. На Java час разработки стоит дороже, чем аналогичный на PHP. Это разные ниши. Для разных проектов и клиентов.
Zend получил 1.8%, и это по вашему не смерть?
Все-таки, он получил хоть что-то. А это уже не смерть. Он не получил 0.
Разработчики языка PHP, создавшие Зенд, об этом знают вообще
это разные штуки с разными авторами. zend framework имеет слабое отношение к zend engine.
Угу, с точки зрения скорости...magento сильно быстрый?
если сделать мегенту на чем угодно он будет медленным.
Там затык не в этом. В 2012 (работал только в этом году с ней) были причины из-за:
- вездесущий EAV
- деревья XML-конфигов, которые никто не кешит
- рекурсии в view
- с кешированием были проблемы
Все, что вспомнил. Наследование здесь не при чем.
во первых подобного в ZF нет.
Да и наследование не налагает никаких накладных расходов на рантайм. Накладных расходов на вызов метода в этом случае будет такой же как просто вызов метода объекта (это ж не prototype-based наследование).
Vagrant работает только на unix-подобных системах
Работает всё.
В Zend самому нужно решать эту проблему. Каждый решает её один раз и таскает из проекта в проект.
Конкретно решение на скриншоте можно посмотреть в репозитории в модуле User. Там Zend Paginator, Bupy7 Form, Doctrine, Twig.
для 19 звезд на проекте это бессмысленно.
Сделайте docker контейнер, сведите всю установку к
docker-compose up
и количество звезд увеличится.
Обзор заготовки web-приложения на Zend Framework 3