Комментарии 160
Ни в коем случае не ведитесь на «простоту» Yii! В качестве первого фреймворка ни в коем случае не рекомендую — плохому научитесь. Сделайте по простенькому проекту на Laravel / Symfony / ZF и выберите тот что понравится. Не нойте что сложно (не сложно!) — это окупится с лихвой в будущем.
Ваше заявление звучит примерно так: «Если вы хотите использовать простой инструмент, используйте вместо него сложный».
Вы советуете начинать изучение фреймворков с тех, что сложнее, и велика вероятность, что человек не осилит, и пойдет дальше говнокодить на коленке. Как по мне, то лучше сначала начать с простого, постепенно усложняя, чем сразу нырять в омут с головой.
Вы советуете начинать изучение фреймворков с тех, что сложнее, и велика вероятность, что человек не осилит, и пойдет дальше говнокодить на коленке. Как по мне, то лучше сначала начать с простого, постепенно усложняя, чем сразу нырять в омут с головой.
Я вкладывал немного другой смысл — «не гонитесь за ложной простотой». Луше вложить немного усилий в самообразование и получить хороший старт для дальнейшего роста.
И да, я более чем уверен что меня мало кто послушает. Проще «говнокодить на коленке» на Yii, чем задумываться над тем, почему же в шаблоне нельзя делать «SomeModel->listAll()» и многие другие славные вещи…
Yii не отвратителен, но изначально (в том числе в документации) он дает массу вредных советов и не запрещает разработчикам стрелять себе в ногу, там где им хочется.
И да, я более чем уверен что меня мало кто послушает. Проще «говнокодить на коленке» на Yii, чем задумываться над тем, почему же в шаблоне нельзя делать «SomeModel->listAll()» и многие другие славные вещи…
Yii не отвратителен, но изначально (в том числе в документации) он дает массу вредных советов и не запрещает разработчикам стрелять себе в ногу, там где им хочется.
Луше вложить немного усилий в самообразование и получить хороший старт для дальнейшего роста.
С этим я согласен, если бы я изначально по такому пути пошел, то сэкономил бы годы. Даже если бы я прочитал эту статью на заре становления своей карьеры, то вряд ли прислушался. Хочется же побыстрей, все и сразу.
Ха, про выстрел в ногу точняк. Это даже с виджетами для фронта можно соеденить. Соберешь фронт себе на бек и будешь сам его потом палкой ковырять, а когда проект разрастется и потребуется разделить обязанности, будут большие сложности, вот это и есть выстрел себе в ногу, поэтому я и назвал это и минусом и плюсом
Может я слишком категорично высказался, но в последнее время много проектов на Yii пришлось просмотреть — везде схожие ошибки. Наболело. И просматривая список вакансий постоянно вижу именно Yii. Да, просто, да быстро. Но чтобы тянуть на нем более-менее серьезный проект, на старте нужен серьезный опыт.
Тоже самое и в случае Laravel происходит. Слишком много он позволяет. А новички хотят скорее начать, не понимая к чему это приведёт в будущем.
Да вот те же самые фасады. Мало кто понимает, что их стоит использовать лишь в качестве хелперов, например в консольке или миграциях, а для бизнес-логики только DI. А потом открываешь какой-нибудь проект и видишь методы контроллеров по 500 строк каждый, которые при этом ещё и копипастятся. Хотя бы сервисный слой для этого? Какой сервисный слой? Не… не слышал =)
Кажется, что это «бич» любого решения с низким порогом входа, но склонен согласиться с тем, что в случае Yii — там на порядок сложнее вывести такой проект в адекватное состояние. Хотя тут я не слишком объективен.
Да вот те же самые фасады. Мало кто понимает, что их стоит использовать лишь в качестве хелперов, например в консольке или миграциях, а для бизнес-логики только DI. А потом открываешь какой-нибудь проект и видишь методы контроллеров по 500 строк каждый, которые при этом ещё и копипастятся. Хотя бы сервисный слой для этого? Какой сервисный слой? Не… не слышал =)
Кажется, что это «бич» любого решения с низким порогом входа, но склонен согласиться с тем, что в случае Yii — там на порядок сложнее вывести такой проект в адекватное состояние. Хотя тут я не слишком объективен.
Yii слишком много позволяет в плане архитектуры, поэтому на нём слишком часто встречается всякой негодности. Вот что мне в нём действительно нравится, так это их queryBuilder. Доктриновский после yii'шного кажется слишком убогим.
Я бы сказал наоборот, в плане архитектуры — не очень много позволяет. Если это про расположения файлов в проекте. Тут с Ларой они одинаковы. Симфони самый развязанный в плане архитектуры. А по поводу QueryBuilder'a скажу, что чистый доктриновский да, немного сложноватый, за счет непривычности описания в аннотациях, но в Ларе например он переорганизован и ничем не хуже Yii-шного, даже немного похож, поэтому их я даже не сравнивал
Симфони самый развязанный в плане архитектуры
Ну… Вот тут я бы поспорил. Слишком много ограничений у симфони. Простой пример: Зарегистрировать UserInterface из секьюрити в контейнере, чтобы потом он мог резолвиться через автовайринг или парам резолвинг. Можно сделать, но это оверинжинеринг и проще сделать фектори (или дёргать токен сторадж).
В этом плане у ларки непосредственно архитектурных ограничений ещё меньше и возможностей больше. У Symfony другое преимущество — он более развязный с зависимостями. Т.е. сами компоненты на порядок гибче, но их и так же на порядок меньше.
Зарегистрировать UserInterface из секьюрити в контейнере, чтобы потом он мог резолвиться через автовайринг или парам резолвинг. Можно сделать, но это оверинжинеринг
А в чем именно оверинженеринг? Простенькая фэктори + строчка в конфиге
Symfony\Component\Security\Core\User\UserInterface:
factory: ['@App\UserProvider', 'get']Если честно — у меня вообще вылетел из головы этот способ. Ваша правда.
Ладно, другой пример. Надо для роутов добавить метаинформацию произвольного формата, при этом она должна мерджиться при наследовании (т.е. инклудах). Ну вот простой пример:
Проблемы:
1) Можно указывать только строки или массивы (т.е. нельзя скинуть ссыль на сервис)
2) Внутри подключаемого ресурса эти параметры не мержатся.
Только не надо говорить, что это не Symfony-way и надо на эвенты всё вешать, а конфиги выносить в другое место. Ну вот взбрело такое в голову, присобачить миддлвари. Мы же об архитектурной гибкости говорим.
Ладно, другой пример. Надо для роутов добавить метаинформацию произвольного формата, при этом она должна мерджиться при наследовании (т.е. инклудах). Ну вот простой пример:
api.example:
resource: "@AppBundle/Resources/config/routing.yml"
prefix: /api
defaults:
_middleware:
- AppBundle\Middleware\QueryLogs
- AppBundle\Middleware\JsonResponsePrettifier
- AppBundle\Middleware\ExceptionsLogger
- AppBundle\Middleware\CrossOrigin
- AppBundle\Middleware\ThrowableToExceptionsTransformer
Проблемы:
1) Можно указывать только строки или массивы (т.е. нельзя скинуть ссыль на сервис)
2) Внутри подключаемого ресурса эти параметры не мержатся.
Только не надо говорить, что это не Symfony-way и надо на эвенты всё вешать, а конфиги выносить в другое место. Ну вот взбрело такое в голову, присобачить миддлвари. Мы же об архитектурной гибкости говорим.
Для кастомщины типа последней несложно написать свой загрузчик с кастомным типом, который будет моржевать нужные дефолты
чтобы не получить минус я должен был привести код загрузчика? конфиг остается тем же, только добавляется свой `type` туда, а дальше строго по докам
symfony.com/doc/current/routing/custom_route_loader.html
symfony.com/doc/current/routing/custom_route_loader.html
Так это вообще не Symfony way. Вы тут свои middleware делаете что ли? В Symfony так не делают т.к в этом по сути нет необходимости, есть Lifecycle symfony.com/doc/current/components/http_kernel.html
Для
AppBundle\Middleware\JsonResponsePrettifier -> JMSSerializerBundle
AppBundle\Middleware\ExceptionsLogger -> Смотря что вы тут хотите, если ошибки фреймворка то symfony.com/doc/current/logging.html, если свои то делаете EventListener на событие kernel.request например, там можно получить метаинформацию из роута (да, текстовую, но вообще возможности роутинга позволяют создать свой загрузчик роутов который позволяет более гибко описать роутинг)
AppBundle\Middleware\CrossOrigin -> NelmioCorsBundle
AppBundle\Middleware\ThrowableToExceptionsTransformer -> Да это и так есть в symfony, для создания обработчика Exception можно создать контроллер и указать его в конфигурации. (https://symfony.com/doc/current/controller/error_pages.html)
Для
AppBundle\Middleware\JsonResponsePrettifier -> JMSSerializerBundle
AppBundle\Middleware\ExceptionsLogger -> Смотря что вы тут хотите, если ошибки фреймворка то symfony.com/doc/current/logging.html, если свои то делаете EventListener на событие kernel.request например, там можно получить метаинформацию из роута (да, текстовую, но вообще возможности роутинга позволяют создать свой загрузчик роутов который позволяет более гибко описать роутинг)
AppBundle\Middleware\CrossOrigin -> NelmioCorsBundle
AppBundle\Middleware\ThrowableToExceptionsTransformer -> Да это и так есть в symfony, для создания обработчика Exception можно создать контроллер и указать его в конфигурации. (https://symfony.com/doc/current/controller/error_pages.html)
Lifecycle асинхронный и на него нельзя полагаться. Может возникнуть ситуация, когда на один kernel.request возникнет два события response и controller. Миддлвари в этом плане более надёжное, гибкое и универсальное средство не предполагающее подводных камней в виде какой-то логики, которая внедряется где-то посередине и всё ломает, меня последовательность и количество событий.
P.S. Имхо, работа поверх кернел эвентов — это фатальная проблема архитектуры фреймворка, т.к. они ограничивают и возможности симфони и отказаться (задепрекейтить) от них невозможно, т.к. сам симфони не умеет как ларка — взять и поменять кусок ядра в новом мажоре, посчитав старый подход тупиковым.
P.S. Имхо, работа поверх кернел эвентов — это фатальная проблема архитектуры фреймворка, т.к. они ограничивают и возможности симфони и отказаться (задепрекейтить) от них невозможно, т.к. сам симфони не умеет как ларка — взять и поменять кусок ядра в новом мажоре, посчитав старый подход тупиковым.
как бы расположение папок в проекте очень далеко от понятия архитектураю И что в Yii что в Ларе любые пути можно переопределить
Большой функционал работает через фасады и IDE-системы не видят методов и свойств в некоторых классах, показывая предупреждения
Все «фасады» лежат в конфигах, в файле app.php. Первым делом при старте нового проекта — берёте и удаляете вообще всё, что там лежит. И никаких фасадов.
«Фасад» в терминах Laravel — это статический прокси + локатор на сервис внутри DI. Подчёркиваю, внутри DI. Каждый сервис может инжектиться (в том числе через автовайринг) по интерфейсу, такие интерфейсы в рамках Laravel называются «контрактами», так же как бины (bean) в Spring.
Механизм очень похож на symfony, только вместо аннотаций, используется отдельный файл и фасадный класс Route, с набором статических методов.
В классе роутов нет ни одного статического метода. Например: github.com/illuminate/routing/blob/master/Router.php#L139
Нет документации на русском языке.
UPD: Не увидел ссылки в футере. Всё ок =)
Увы, не могу оценить часть про Yii2, т.к. в основном использую другие фреймворки (в частности Symfony), но судя по части про Laravel — его вы знаете крайне поверхностно, что делает эту статью довольно субъективной, без попыток реального сравнения возможностей.
С другой стороны — могу подтвердить, что в Yii2 действительно генераторы кода мощнее, но ничего не мешает в Laravel так же указать ссылки на шаблоны для генерации кода.
Спасибо за комментарий. Я не видел смысла вдаваться в дебри смысла работы фасадов, скорее это предупреждение, что придется с этим столкнуться, поскольку ни в Yii2 ни в Symfony этого нет. Но то, что вы описали в комментарии — очень хорошо. Спасибо за дополнение!
поскольку ни в Yii2 ни в Symfony этого нет.
Сам механизм, который делает всё тоже самое и содержит точно такие же проблемы есть и в Yii и в Symfony.
Сервис локация (фасады и проч)
Laravel:
Yii:
Symfony:
\DB::xxx();
Yii:
Yii::$app->db->xxx();
Symfony:
$container->get('doctrine')->xxx();
Это называется сервис-локацией и порождает скрытые зависимости. В случае Laravel — это заменяется на обычный DI, в Symfony — точно так же на DI, при этом сейчас (в последних версиях) обращение к контейнеру через get — вызывает ошибку доступа. Надо явно прописывать что этот сервис публичный.
DI (как делать по-нормальному)
Laravel:
Symfony:
Yii2:
А тут я фиг знает как, т.к. не шарю Yii. Покажете пример?)
public function __construct(Connection $conn)
{
$conn->xxx();
}
Symfony:
public function __construct(EntitManagerInterface $em)
{
$em->xxx()
}
Yii2:
А тут я фиг знает как, т.к. не шарю Yii. Покажете пример?)
Сложно сказать. Может я не знаю, но способ получить подключение к базе можно так же через сервис локацию
Но это как раз через фасады, которые в конфиге задаются. Либо расширением класса ActiveRecord, чем и являются модели. Тут просто не доктрина, поэтому сложно провести аналогию, принцип немного другой.
А в той же ларе или симфони, можно получить низкоуровневый объект PDO
Я не совсем об этом речь вел. Модели я чисто для примера взял. В Ларе например и в роутах используются методы Route::post(/***/), которые по факту не являются статичными. Я в общем о том, что такие явления есть
$connection=Yii::app()->db;
Но это как раз через фасады, которые в конфиге задаются. Либо расширением класса ActiveRecord, чем и являются модели. Тут просто не доктрина, поэтому сложно провести аналогию, принцип немного другой.
А в той же ларе или симфони, можно получить низкоуровневый объект PDO
Я не совсем об этом речь вел. Модели я чисто для примера взял. В Ларе например и в роутах используются методы Route::post(/***/), которые по факту не являются статичными. Я в общем о том, что такие явления есть
Как-то так:
Yii::$container->get('db');vs
public function __construct(\yii\db\Connection $db)Сложно сказать. Может я не знаю, но способ получить подключение к базе можно так же через сервис локацию
Вопрос как раз в другом. Как это делать не через эту самую сервис-локацию. Потому что, как я уже описал выше — это крайне плачевный подход для долгоживущих проектов.
Ну вот есть какой-то класс, например database query logger, зарегистрируем его в контейнер (можно же?) по имени "dbQueryLogger". Как сказать проекту, что получая Yii::app()->dbQueryLogger (или как-то так, поправьте если ошибаюсь) нужно создавать этот объект и прокидывать туда соединение с базой + PSR LoggerInterface.
UPD: О, VolCh ответил на вопрос. Спасибо. А в методы прокидывать так же можно?
Да, зря контроллер в Symfony сделали ContainerAware… )
По Yii 2 пример ровно такой же :) Инъекция через рефлексию в конструктор поддерживается.
Также хочу дополнить, что Yii2 на самом деле не очень-то привязан к Bootstrap 3. Можно не использовать пакет 'yiisoft/yii2-bootstrap', а вместо него подключить, например, 'digitv/yii2bootstrap4', — и имеем набор классов-виджетов Bootstrap 4
Безспорно. Можно и свои расширения с виджетами написать и тем же функционалом и юзать например bulma вместо бутстрапа. Но речь то о том, что у него встроенно из коробки, а не установлено из вне.
В данном случае — просто в приложении-шаблоне (https://github.com/yiisoft/yii2-app-basic) в файле composer.json указана зависимость 'yiisoft/yii2-bootstrap'. Если не разворачивать приложение из шаблона, а организовывать структуру проекта самому (ну, или же просто убрать эту зависимость), — пакет не будет доступен. Он не прибит гвоздями, насколько я знаю.
Да это понятно. Так в любом решении, можно любой пакет заменить на другой или собрать по частям. Речь о работе из коробки, без лишних заморочек и для типовых задач. Когда человек выбирает фреймворк, на котором он будет учиться писать, он не собирается делать Highload проекты и пересобирать фреймворк. До этого еще дойти надо!
В Yii2 есть yii\rest\ActiveController — который позволяет быстро настроить REST FULL API...
Вот как раз REST FULL API он и позволяет делать.
А вот RESTful все таки удобней разрабатывать используя функциональные возможности Laravel
В Symfony (3) из коробки 4, если не ошибаюсь, 4 способа задавать роуты, да и вообще конфиги: php, yaml, xml, annotation. И не понимаю, почему Symfony низкоуровневый фреймворк — уровень у него обычный для современных фреймворков. И не фреймворк laravel построен на базе фреймворка symfony, а фреймворки laravel и symfony построены на базе компонентов symfony, первый в меньшей степени, второй в большей.
С первой страницы официального сайта симфони. Означает, что используются не компоненты, а именно фремворк. А Вот Yii использует именно компоненты.
А низкоуровневый — это как аналогия языков программирования. Типа PHP, JAVA, PYTHON языки высокого уровня, а C, C++ или Асемблер низкоуровневые языки. Тут дело в доступности данных низкого уровня (дампы или ячейки памяти, отдельные биты в кластерах), а не в том, как роуты задаются
Symfony — это набор компонентов, который называется "фреймворком". Так же как, например, Illuminate — тоже "фреймворк".
Сборка приложения в симфони называется symfony flex или symfony standard. У Illuminate же называется Laravel. Что тоже называют фреймворками, хотя это только сборка.
https://github.com/symfony/framework-bundle — вот фреймворк симфони
https://github.com/laravel/framework — вот фреймворк ларавел
github.com/symfony/symfony — вот фреймворк симфони.
А github.com/symfony/framework-bundle — это FrameworkBundle использующийся в составе фремворка
Имхо автор не имеет реального опыта работы с симфони и краем глаза увидел что компоненты симфони используются в Laravel и т.д… Symfony фреймворк в том же смысле что и Laravel позволяющий реализовывать хотя бы тот же MVC паттерн
А github.com/symfony/framework-bundle — это FrameworkBundle использующийся в составе фремворка
Symfony более низкоуровневый фреймворк
Имхо автор не имеет реального опыта работы с симфони и краем глаза увидел что компоненты симфони используются в Laravel и т.д… Symfony фреймворк в том же смысле что и Laravel позволяющий реализовывать хотя бы тот же MVC паттерн
Так чем у симфони уровень ниже чем у ларавеля? какие, например, абстракции не предоставляет симфони?
Ай, ну как же не понять то. Низкоуровневый — не значит хуже или что то невозможно реализовать или чего-то не предоставляет. Низкоуровневый язык программирования означает, что ты можешь работать с данными не на уровне объектов и чисел и строк, а на уровне дампов памяти, битов, положения битов в кластере и тому подобные вещи. В аналогии с фреймворками я имел ввиду, что для Симфони ты будешь больше писать ручками, для осуществления каких-то типовых задач, которые в свою очередь в Ларе и Юии имеют готовые решения.
Хлебные крошки?
Так каких "каких-то"? У каких типовых задач по разработке на PHP нет готовых решение в symfony и есть в yii/laravel?
В Symfony есть абстракции над http и сессиями, роутинг, шаблонизация, кеширование, работа с формами, валидация, работа с ФС, контроль доступа, DI, i18n, l10n и переводы, конфигурация, сериализация, работа с процессами ОС, свой http-клиент и работа с DOM, бридж к ORM, бридж к свифтмейлеру, бридж к пхпюнит, бридж к монолог, бридж к твиг, средства отладки и профилирования. Что ещё нужно от фреймворка?
Генераторы не в счёт, они не являются частью фреймворка как каркаса приложения, они часть экосистемы вокруг каркаса.
Ну и замечание: многие вещи в плане разделения frontend/backend будут сделаны в Yii 2.1. Как минимум — отказ от привязки к jQuery. Разработчики прекрасно знают о подобной исторической проблеме архитектуры и пытаются ее постепенно решить по мере возможностей.
Но в плане разработки сайта на коленке с простой админкой — это очень сильная сторона Yii. По сути можно сделать на нем простой блог за 30 минут и это не преувеличение.
Но в плане разработки сайта на коленке с простой админкой — это очень сильная сторона Yii. По сути можно сделать на нем простой блог за 30 минут и это не преувеличение.
Интересно, с каких это пор в симфони стали отсутствовать инструменты для решения небольших типовых задач?
А если выбирать из 2х зол, я бы выбрал меньшую — Laravel.
Приведу пример. В Симфони есть генератор готовых интерфейсов? Встроенный удобный сборщик фронтенда как у Ларавел? Помельче: хелперы для работы с конфигами, или какими-то данными. А интерфейсы для данных — это вполне типовая задача.
В Симфони есть генератор готовых интерфейсов?
https://symfony.com/doc/current/bundles/SymfonyMakerBundle/index.html
Встроенный удобный сборщик фронтенда как у Ларавел?
Разговор про с коробки! Доставить можно все что угодно. И в Симфони правильно делают что не ставят в коробку. В последней версии вообще много чего выпилили с того, что было раньше, все можно поставить, но отдельно, и по мере надобности. Мне нравится такой подход. Но разговор шёл про «из коробки». Здесь не о чем спорить. Для многих типовых решений есть куча отдельных библиотек написанным самими SensioLab и сторонние решения.
Это совсем не то, что делает Yii. Этот генерирует только php файлы с классами, а у Yii это и модели и контроллеры сразу с данными и готовое сверстанное представление
symfony.com/doc/current/bundles/SymfonyMakerBundle/index.html
Это совсем не то, что делает Yii. Этот генерирует только php файлы с классами, а у Yii это и модели и контроллеры сразу с данными и готовое сверстанное представление
https://github.com/symfony/website-skeleton/blob/4.0/composer.json
"require": {
// ...
"symfony/webpack-encore-pack": "*",
// ...
},
"require-dev": {
// ...
"symfony/maker-bundle": "^1.0",
// ...
},Мейкер был. А вот вебпака вроде не было, до недавних пор. Может я ошибаюсь, но это все равно не то. Мейкер тут точно такой же как в Ларавел, точнее в Ларавел он заимствован из симфони скорее всего. А вебпак все равно надо настраивать, как с миксами легко не получится. Но это не в минус, это как раз больше к свободе действий.
Не поймите меня не правильно. Симфони я очень уважаю. Но для типовых проектов, которые мне приходилось делать быстрее сделать на Ларе или Юии. Симфони лучше подходит для планирования хорошей архитектуры и мощных нагруженных проектов. Для толстых проектов, совмещающих в себе кучу мелких, я бы бесспорно выбрал Симфони. А если писать что-то типа Алибабы, Ебэя или Что-то еще более крупное. Лучше вообще избегать фреймворков, поскольку тут очень важно продумать свою разумную архитектуру, чего не делает один человек. Не думаю что Гугл или Яндекс пишут на каких-то фреймворках, скорее разрабатывают свои. Но это лично мое мнение
Не поймите меня не правильно. Симфони я очень уважаю. Но для типовых проектов, которые мне приходилось делать быстрее сделать на Ларе или Юии. Симфони лучше подходит для планирования хорошей архитектуры и мощных нагруженных проектов. Для толстых проектов, совмещающих в себе кучу мелких, я бы бесспорно выбрал Симфони. А если писать что-то типа Алибабы, Ебэя или Что-то еще более крупное. Лучше вообще избегать фреймворков, поскольку тут очень важно продумать свою разумную архитектуру, чего не делает один человек. Не думаю что Гугл или Яндекс пишут на каких-то фреймворках, скорее разрабатывают свои. Но это лично мое мнение
Сейчас большинство проектов делается согласно принципу “Api first”. А в нагружённом проекте вообще всегда зоопарк технологий а не фреймворк.
Это совсем не то, что делает Yii.
Laravel тоже так не умеет, на сколько я помню, но его вы почему-то включили в обзор
Symfony начиная с версии 4 как раз следует парадигме «доставь все что тебе нужно». Чем-то напоминает Flask из мира python. На старте это готовый микрофреймворк, но собрать из него можно что угодно.
Было ли это хорошим решением — время покажет. Лично мне нравится, хоть и непривычно что Doctrine и Twig по умолчанию отсутствуют.
Было ли это хорошим решением — время покажет. Лично мне нравится, хоть и непривычно что Doctrine и Twig по умолчанию отсутствуют.
Что такое генератор интерфейса?
Для фронта — есть и любой вешний без проблем подключается. Что должны делать эти хелперы а главное зачем? Тот же вопрос про данные.
Помельче: хелперы для работы с конфигами, или какими-то данными.
Что вы под этим имеете в виду?
Где вы видели, что в проекте используется только то, что есть в самом фреймворке?
Нигде не видели)
Тогда к чему такая привязка к инструментам из коробки?
Потому что если сравнивать. То возможности самих фреймов. А если говорить о различных надстройках, то вообще можно придти к выводу что все имеют одинаковые возможности с разной реализацией просто.
Как раз все дело в реализации, как по мне.
Сравнивать можно и нужно не то, что из коробки (особенно если коробок много по факту, скажем различные edition типа web-edition, api-edition и т. п. или full-edition, standard-edition, micro-edition), а то, что предоставляет вендор прежде всего. Если в доках фреймворка X написано про фичу Y "перед использованием подключите Y с помощью composer req x/y", то это не повод исключать из сравнения.
Сразу предупрежу вопрос о том, почему не рассматриваем Symfony.Ерунда какая-то написана. Мы используем Symfony и в крупных и в мелких проектах и никаких костылей вроде собственных фреймворков не пишем.
Дело в том, что Symfony более низкоуровневый фреймворк, который чаще берут для основы в крупных проектах, например таких, как написание собственного фреймворка для разработки.
Вы вероятно имели в виду бандлы, а не сам фреймворк. Из отдельных бандлов/либ да, можно набросать свой собственный фреймворк (в этом собственно прелесть модульной архитектуры) если уж очень колется, но только зачем? :)
Его в принципе нельзя сравнивать с Laravel и Yii2, так как они используют его компоненты в своих реализациях.Ну вот вы сами ответили на свой вопрос.
В 2015г. я бы еще обратил внимание на Yii.
На данный момент, не вижу в нем хотя бы одного плюса.
Правда я фанат Symfony DDD/CQRS/Bus/EQ… Потому мое мнение совершенно бесполезно.
На тему крупных проектов, видимо автор застрял в 2015-2016гг. и не знает о существовании Symfony 4.
Соответственно, считать данный пост серьезным, совершенно нельзя.
На данный момент, не вижу в нем хотя бы одного плюса.
Правда я фанат Symfony DDD/CQRS/Bus/EQ… Потому мое мнение совершенно бесполезно.
На тему крупных проектов, видимо автор застрял в 2015-2016гг. и не знает о существовании Symfony 4.
Соответственно, считать данный пост серьезным, совершенно нельзя.
Я бы отмотал еще лет 7 ) Если и сравнивать Yii то с Symfony 1.x, ZF1.x (год 2007-2008й). Кстати у Symfony тогда был админ-генератор из коробки))
Да, был. Но я в то время на Zend писал и осваивал Yii, который был в тренде.
Но сейчас, выбор мой SF, но если смотреть на другие, то конечно laravel.
Причина проста — организация кода, архитектурный принцип и конечно ioc.
В добавок, удобно реализовать DDD. Хотя тоже надо будет поковыряться и написать обработчик для входящих данных, что бы использовать геттеры
Но сейчас, выбор мой SF, но если смотреть на другие, то конечно laravel.
Причина проста — организация кода, архитектурный принцип и конечно ioc.
В добавок, удобно реализовать DDD. Хотя тоже надо будет поковыряться и написать обработчик для входящих данных, что бы использовать геттеры
Я тогда выбрал Symfony (из-за схожести с RoR, который тогда тоже был в тренде, но не только — делал несколько небольших проектов то на одном, то на другом фреймворке, сравнивал грабли). И не пожалел, вторая версия, хоть поначалу и казалась сложной, повернула мозги в правильном направлении.
Проектов настолько больших, чтобы DDD принес реальную пользу (ЧСВ не в счет) немного, так что ниша Yii/Laravel довольно большая.
IoC есть и в Yii и в Laravel. В Yii в основном практикуется ServiceLocator. например вызов Yii::$app->get(); или Instance::ensure() в init() или конструкуторе хуже классического внедрения только в том плане, что нельзя будет класс оторвать от фреймворка, а это не так уж нужно если не пишешь библиотеку.
IoC есть и в Yii и в Laravel. В Yii в основном практикуется ServiceLocator. например вызов Yii::$app->get(); или Instance::ensure() в init() или конструкуторе хуже классического внедрения только в том плане, что нельзя будет класс оторвать от фреймворка, а это не так уж нужно если не пишешь библиотеку.
Проектов настолько больших, чтобы DDD принес реальную пользу (ЧСВ не в счет) немного
хуже классического внедрения только в том плане, что нельзя будет класс оторвать от фреймворка
То есть возможность роста проекта настолько, что DDD начнёт приносить пользу вы априори исключаете, гвоздями прибивая классы проекта к фреймворку, на котором сложно работать с DDD?
DDD — любой проект, где существует серьезная бизнес логика. Проекты, где важен бизнес а не ЧСВ разработчика.
Сначала реализуется бизнес-логика, которая не зависит от приложения, затем делается остальное.
Вот главная цель DDD.
Конечно, применять в мелких сайтах и петпроектах не имеет смысла.
Но я не говорю о таких проектах, их можно реализовать хоть на html и пару микросервисов. Я даже не считаю подобные проекты работой.
Т.е. вывод прост, вы не представляете что такое DDD и для чего.
Или просто не работали над серьезными бизнес-проектами с миллионными инвестициями.
Сначала реализуется бизнес-логика, которая не зависит от приложения, затем делается остальное.
Вот главная цель DDD.
Конечно, применять в мелких сайтах и петпроектах не имеет смысла.
Но я не говорю о таких проектах, их можно реализовать хоть на html и пару микросервисов. Я даже не считаю подобные проекты работой.
Т.е. вывод прост, вы не представляете что такое DDD и для чего.
Или просто не работали над серьезными бизнес-проектами с миллионными инвестициями.
Главная цель DDD это устранение сложностей с пониманием предметной области и создание реализации, максимально близкой к модели предметной области, чтобы ее удобно было понимать и поддерживать.
По вашему серьезные проекты невозможны без DDD?) Большинство проектов на Yii не сделаны по DDD, их вы тоже не считаете работой?) Жгите дальше.
По вашему серьезные проекты невозможны без DDD?) Большинство проектов на Yii не сделаны по DDD, их вы тоже не считаете работой?) Жгите дальше.
Нет, почему же.
Можно написать хоть обычными функциями на PHP4 (делал банковскую CRM в 2007г.).
Вы мне напомнили людей с развлекательных сайтов, которые читают первую строчку, затем среднюю и последнюю.
Вообще — я не говорил, что YII нельзя использовать и это полное дерьмо.
Я не писал, что невозможны серьезные проекты без DDD.
Вы как западные политики, придумываете то что вам удобно.
Почему для слепых котят, надо все пояснять и выделять жирным текстом?
Можно написать хоть обычными функциями на PHP4 (делал банковскую CRM в 2007г.).
Вы мне напомнили людей с развлекательных сайтов, которые читают первую строчку, затем среднюю и последнюю.
Вообще — я не говорил, что YII нельзя использовать и это полное дерьмо.
Я не писал, что невозможны серьезные проекты без DDD.
Вы как западные политики, придумываете то что вам удобно.
Почему для слепых котят, надо все пояснять и выделять жирным текстом?
Конечно, применять в мелких сайтах и петпроектах не имеет смысла.
Но я не говорю о таких проектах, их можно реализовать хоть на html и пару микросервисов. Я даже не считаю подобные проекты работой.
Вообще — я не говорил, что YII нельзя использовать и это полное дерьмо.
Я не писал, что невозможны серьезные проекты без DDD.
Вы как западные политики, придумываете то что вам удобно.
Почему для слепых котят, надо все пояснять и выделять жирным текстом?
Извините, я неправильно понял ваш комментарий.
Не вижу что кто-то писал, будто без ДДД невозможно реализовать крупное программное решение.
Доменый слой существует для реализации логики в отрыве от данных и приложения.
Вы пишите логику, основываясь на требованиях бизнеса. Домен, дает прекрасную возможность, подстраиваться под веяния бизнеса.
Доменый слой существует для реализации логики в отрыве от данных и приложения.
Вы пишите логику, основываясь на требованиях бизнеса. Домен, дает прекрасную возможность, подстраиваться под веяния бизнеса.
А без DDD вы логику на основе чего пишете?
Как обычно, бестпрактик.
Но это к сожалению не дает возможности, быстро перестроить логику, если что то кардинально изменится.
Соответственно это время и деньги бизнеса.
Если вас смутила фраза
То тут имелось ввиду, что в ДДД пишут, не именно вы =)
Пишу статью, образ речи сохраняется и в комментариях =)
Но это к сожалению не дает возможности, быстро перестроить логику, если что то кардинально изменится.
Соответственно это время и деньги бизнеса.
Если вас смутила фраза
Вы пишите логику, основываясь на требованиях бизнеса.
То тут имелось ввиду, что в ДДД пишут, не именно вы =)
Пишу статью, образ речи сохраняется и в комментариях =)
Я хотел сказать, что любые приложения всегда пишутся по требованиям бизнеса, DDD здесь не монополист. Да, по сравнению с обычными приложениями, в DDD код более абстрактный и иногда легче по нему понять сложную бизнес-схему. Но это актуально только для реально сложных проектов, там где логика простая, DDD привносит больше сложности, чем снимает. Основная цель DDD борьба со сложностью, но для этого нужно сначала убедиться в том, что эта сложность действительно есть и она будет доставлять проблемы.
Без DDD вы, грубо говоря, не выделяете бизнес-логику в отдельный слой, независимый ни от чего кроме бизнес-требований. Скажем, в типичном Yii/Laravel приложении бизнес-логика очень часто размазана между контроллерами (классами унаследованными от базового класса контроллера) и "моделями" (классами, унаследованными от базового класса ActiveRecord). И хорошо если бОльшая часть в "моделях", а не в контроллерах.
Выделение бизнес-логики в отдельный независимый слой в общем случае не только в случае DDD может применяться, но на практике если видишь такое выделение, то и другие технические паттерны DDD замечаешь почему-то.
Скажем, в типичном Yii/Laravel приложении бизнес-логика очень часто размазана между контроллерами (классами унаследованными от базового класса контроллера) и «моделями» (классами, унаследованными от базового класса ActiveRecord). И хорошо если бОльшая часть в «моделях», а не в контроллерах.
Ну в таком случае можно сказать, что в DDD-проекте она размазана между сущностями и сервисами, и хорошо, если большая часть в сущностях, а не сервисах, чтоб не получились анемичные сущности.
Существенное отличие между нашими фразами — в вашей нет слов "унаследованного от базового класса". В DDD бизнес-логика размазана по слою бизнес-логики и ни от чего не зависит. В типичном Yii/Laravel приложении бизнес-логика размазана между моделью, совмещающей по определению бизнес- и инфраструктурную логики, и контроллерами, реализующими по определению часть UI-логики. И, главное, и там, и там она зависит от классов, предоставляемых фреймворком. Захотите поменять фреймворк (ну или проапгрейдить на мажорную версию) — придётся разбираться где бизнес-логика, а где UI или инфраструктурная.
На актуальных версиях Yii/Laravel/Zend/Symfony можно писать как приложения в которых бизнес-логика отделена от всего остального, так и приложения в которых практически вся кастомная логика в контроллере, но почему-то на Zend и Symfony отделяют гораздо чаще, чем на Yii/Laravel. Как мне кажется, это не просто случайное стечение обстоятельств, а вполне сознательное поощрение того или иного стиля ведущими разработчиками того или иного фреймворка.
Я думаю, что это абсолютно нормально, когда для решения какой-то задачи берется популярный, поддерживаемый фреймворк и код зависит от него. В этом ничего плохого я не вижу и считаю это нормальным. Да, при смене мажорной версии придется приложить усилия, заменить какие-то вызовы, базовые классы, отрефакторить проект. C DDD эти усилия прикладываются наперед, но несколько в другом виде — абстракции. домена. Но и это спасет от рефакторинга лишь часть проекта. При замене фреймворка/мажорной версии все равно придется много переделывать. Инфраструктурный слой все равно придется переписать, а этот слой чаще получается даже намного толще доменного.
Я предпочитаю не закладывать наперед возможность смены фреймворка/мажорной версии, так как это порождает много абстракций, которые замедляют и усложняют разработку (надо больше думать для выделения хороших абстракций), чтобы потом облегчить гипотетическую смену фреймворка, которая может и не понадобиться вовсе. Некоторые проекты на Yii1 спокойно продолжают работать.
Фреймворконезависимость обходится дорого, она добавляет забот. Помимо реализации требований, приходится решать задачи по абстракции.
Да, иногда, она оказывается полезной, но я нахожу такие ситуации довольно редкими.
Я предпочитаю не закладывать наперед возможность смены фреймворка/мажорной версии, так как это порождает много абстракций, которые замедляют и усложняют разработку (надо больше думать для выделения хороших абстракций), чтобы потом облегчить гипотетическую смену фреймворка, которая может и не понадобиться вовсе. Некоторые проекты на Yii1 спокойно продолжают работать.
Фреймворконезависимость обходится дорого, она добавляет забот. Помимо реализации требований, приходится решать задачи по абстракции.
Да, иногда, она оказывается полезной, но я нахожу такие ситуации довольно редкими.
Правда я фанат Symfony DDD/CQRS/Bus/EQ…
Вот, сразу виден фанатизм. Он ослепляет.
Я пробовал применять DDD в проекте. Что получилось — то же самое что и было без DDD, только работы больше по абстракции домена. Кода стало реально больше. Оверхед был налицо, поэтому для себя я сделал вывод, что DDD нужно применять только тогда, когда есть проблемы коммуникации(!), домен реально сложный и нетиповой.
О недостатках DDD в википедии
Несколько лет назад, мы потратили 4 месяца, на проектирование архитектуры доменого слоя для SF без кода.
Доработали доктрину, реализовали сериалайзер и маппинг бандлы.
На данный момент, проект полностью оторван от приложения. Т.е. домен можно использовать в любом другом месте, подгрузив только нужные зависимости.
Слой приложения, полностью отдельный и не зависит от домена.
Вместе же, это реализует API для HL++ проекта.
Оверхеда какого либо нет. Правда это заслуга хорошо продуманной архитектуре и то о чем я писал выше.
Я вам открою секрет, на текущий момент, я больше фанат Golang и laravel. Но это только в отрыве от бизнеса.
Доработали доктрину, реализовали сериалайзер и маппинг бандлы.
На данный момент, проект полностью оторван от приложения. Т.е. домен можно использовать в любом другом месте, подгрузив только нужные зависимости.
Слой приложения, полностью отдельный и не зависит от домена.
Вместе же, это реализует API для HL++ проекта.
Оверхеда какого либо нет. Правда это заслуга хорошо продуманной архитектуре и то о чем я писал выше.
Я вам открою секрет, на текущий момент, я больше фанат Golang и laravel. Но это только в отрыве от бизнеса.
Несколько лет назад, мы потратили 4 месяца, на проектирование архитектуры доменого слоя для SF без кода.
4 месяца без кода, ну это большой риск. И что прототипов даже не писали?
На данный момент, проект полностью оторван от приложения. Т.е. домен можно использовать в любом другом месте, подгрузив только нужные зависимости.
Вот именно, что можно, но нужно ли? Вам это дало какой-то профит, если не секрет, какой? Повторно использовали домен в другом проекте? Так он же уникальный, разве нет? В чем именно получилась реальная выгода, если не секрет?
Нет. Блок схемы в основном. Продумывали алгоритмы.
У нас было время, т.к. проект уже работал (кстати на YIi частично), но он не отвечал двум основным требованиям. Это нагрузка (на 50 обращениях уже не вытягивал именно PHP, не БД. До нас делали по доке проект), вторая проблема, это изменения поведения внешних клиентов которым поставляются данные (booking.com, trivago и др. букинг товарищи).
Время дали год для команды. Надо было придумать и реализовать проект с возможностью быстрой перестройки под тот или иной проект. Особенно это стало хорошо заметно на фоне санкций и нового закона о данных.
Профит — я уже сказал по сути. Быстрая смена работы под определенные бизнес-решения. Домен используется и в др. проекта, как вы верно заметили. Домен не совсем уникальный, он имеет модели, репозитории, логику для определенных вещей букинг бизнеса, что в 90% случаев одинаково.
Для использования домена в другом проекте (условие только SF), надо подменить для своих нужд хендлеры, если это требуется и/или объекты ответа заменить.
Слой приложения пишется свой, у каждого свои потребности.
У нас было время, т.к. проект уже работал (кстати на YIi частично), но он не отвечал двум основным требованиям. Это нагрузка (на 50 обращениях уже не вытягивал именно PHP, не БД. До нас делали по доке проект), вторая проблема, это изменения поведения внешних клиентов которым поставляются данные (booking.com, trivago и др. букинг товарищи).
Время дали год для команды. Надо было придумать и реализовать проект с возможностью быстрой перестройки под тот или иной проект. Особенно это стало хорошо заметно на фоне санкций и нового закона о данных.
Профит — я уже сказал по сути. Быстрая смена работы под определенные бизнес-решения. Домен используется и в др. проекта, как вы верно заметили. Домен не совсем уникальный, он имеет модели, репозитории, логику для определенных вещей букинг бизнеса, что в 90% случаев одинаково.
Для использования домена в другом проекте (условие только SF), надо подменить для своих нужд хендлеры, если это требуется и/или объекты ответа заменить.
Слой приложения пишется свой, у каждого свои потребности.
В каком плане "то же самое"? Если работы по абстракции больше, то значит не то же самое, а абстракция сильнее, нет?
«То же самое» — имеется ввиду реальная работа, которую выполняет код. Да, абстракция стала сильнее, но внедрять новые функциональные возможности, как ни странно, стало сложнее. Приходится думать, как новое ляжет на существующие абстракции, а если не ложится, приходится их модифицировать вместе со всем соответсвующим инфраструктурным кодом. Да и просто больше файлов надо просмотреть и отредактировать.
Сначала меня DDD увлек, я думал, он мне поможет упростить работу, а на практике оказалось нет. Проект не настолько сложный и большой, команда 3 человека в одном офисе.
Сначала меня DDD увлек, я думал, он мне поможет упростить работу, а на практике оказалось нет. Проект не настолько сложный и большой, команда 3 человека в одном офисе.
Даа. Админ-генератор был сказка. Мы вот в sf4 юзаем EasyAdmin и плюёмся :(
Я так понимаю кроме жирной Сонаты и EasyAdmin больше вариантов нет?
Я так понимаю кроме жирной Сонаты и EasyAdmin больше вариантов нет?
Если и есть, то хуже по качеству.
Хотя я особо не искал.
SF в 99% используется для реализации API, остальное swagger + экспорт в postman.
Хотя я особо не искал.
SF в 99% используется для реализации API, остальное swagger + экспорт в postman.
Нормальных я не видел. EasyAdmin использую для чего-то совсем простого, в остальных случаях пишу свои решения. Sonata, при всем моем уважении к труду сообщества, слишком медленная и переусложненная. Я отказался от ее использования после долгих лет мучений… )
Работа через фасады, большинства обширных классов Laravel. Такое сложное предложение, я поясню! Дело в том, что во многих классах фреймворка используется динамическое создание свойств и методов, в зависимости от каких-то условий.
Проще привести пример. Мы объявляем класс модели работы с базой данных, которая является расширением стандартного класса Illuminate\Database\Eloquent\Model, в котором нет статических методов where, select и т.п., но на самом деле они есть и ими можно пользоваться. Вот такие чудеса. Дело в том, что такие методы образуются из так называемых фасадов, которые считывают обычные методы класса и превращают их в статические. А свойства получаются путем обращения к базе данных.
Автор вообще не видит разницы между фасадами и магическими методами? Статью очень трудно воспринимать, так как автор явно поверхностно знаком с обоими фреймворками.
Плюс Yii2 — в том что он очень лоялен к новичкам, можно генерацию из интерфейсов делать, без консоли, можно минимум js знать, тонны виджетов на каждый чих; и он же — большой минус так как тормозит развитие и изучение сопутствующего стека, оставляя зацикленными на jquery-bootstrap
И очень не хватает для Yii2 аналога laracast
Да, Yii/Laravel + VueJs на мой взгляд сейчас очень актуальный и востребованный стек.
Сам работаю с Yii, очень удобно.
Про механизмы доступа к данным что-то ничего не написали.
Сам работаю с Yii, очень удобно.
Про механизмы доступа к данным что-то ничего не написали.
С лета 2013-го до лета 2017-го моей основной задачей была поддержка и развитие проекта на symfony 1.4. Он был популярным и поддерживаемым на время старта проекта. И процентов на 90 уверен, что он работает до сих пор, хотя и ведутся работы по уходу с него. Что я могу сказать: была бы там логика отделена от фреймворка (считая doctrine1 частью symfony 1) — не было бы острой нужды в уходе с него. Минимум годовую зарплату я получил за борьбу с сильной связанностью бизнес-логики и фреймворка. Там и других косяков в архитектуре хватало, и сам я немало костылей написал под убеждением «ещё пара месяцев и так или иначе развитие остановится» буквально с первого дня работы, но основная проблема была именно в отсутствии изоляции от фреймворка и orm. По самым моим пессимистичным оценкам, пару человеко-месяцев выделенных летом 2013-года на изоляцию, окупились бы только за счёт моих задач к лету 2017-го многократно.
А можете описать пару проблем именно из-за связанности?
Навскидку, по памяти:
- повсеместное, буквально в каждом типе функциональных модулей, использование синглтона sfContext — имплементация Registry. Например, поступает задача в некоторых случаях модифицировать поведение реакции на http-запрос. Добавляешь get-параметр в урл, проверяешь егов контроллее, модифицируешь поведение, поведение непредсказуемое, копаешься, копаешься, а потом оказывается что это параметр используется уже где-то в модели через sfContext::getInstance()->getRequest()->get('hold')
- "магическая" передача динамических свойств класса контроллера в шаблоны
- активное использование методов типа save() в "безобидных" сеттерах или методах типа calcBalance() инстансов ActiveRecord, а то и в геттерах.
Да, ситуация у вас тяжелая была. Конечно, обращение к HTTP Request в модели это перебор. И я тоже против повсеместного обращения к реестру. Но вот в конструкторе, при инициализации объекта, на мой взгляд, допустимо обращаться к реестру за зависимостями. Если там будет обращение к недоступной зависимости, это быстро обнаружится, так же как и для классического конструктора. Также API класса для использования в клиентском коде становится попроще — не надо всюду все зависимости для создания экземпляров прокидывать.
Я раньше тоже был только за классическое внедрение через конструктор/методы, но сервис-локатор в конструкторах упрощает код и экономит время. К тому же зависимость можно прокинуть туда, куда ее через конструктор иногда не прокинешь (какая-нибудь библиотека требует, чтобы он был без параметров).
Безусловно, у классического внедрения свои плюсы — можно класс сделать независимым от локатора — максимально реюзабельным. Но это не всегда нужно.
А почему вызовы save() в методах-мутаторах (изменяющих состояние) AR считаете неправильным? И причем тут сильная связанность? Я как раз наоборот, ратую за это. Тем более в Yii, если ничего не поменялось, то к базе запросов не будет.
Я раньше тоже был только за классическое внедрение через конструктор/методы, но сервис-локатор в конструкторах упрощает код и экономит время. К тому же зависимость можно прокинуть туда, куда ее через конструктор иногда не прокинешь (какая-нибудь библиотека требует, чтобы он был без параметров).
Безусловно, у классического внедрения свои плюсы — можно класс сделать независимым от локатора — максимально реюзабельным. Но это не всегда нужно.
А почему вызовы save() в методах-мутаторах (изменяющих состояние) AR считаете неправильным? И причем тут сильная связанность? Я как раз наоборот, ратую за это. Тем более в Yii, если ничего не поменялось, то к базе запросов не будет.
В конструкторе, да, не так страшно, особенно если DI нет и внедрить его затруднительно, а вот когда в коде обычного метода где-то, вот понадобилось и дернули реестр, то выявить что где повлияет очень сложно.
Неявное сохранение с одной стороны, если метод не назван как-то типа calcBalanceAnsSave() — когда просто calcBalance или getBalance, то как-то ожидаешь, что максимум чтение с базы может быть, но никак не запись, причём может быть каскадная. Множественные сохранения с другой, когда мутаций несколько. Ну а главное, именно сильная связанность — бизнес-логика получается сильно связанной с ActiveRecord. Ладно бы просто в конце сеттера вызывался save, так где-то в середине, а если в конец перенести, то или не работает вообще, или сохраняет лишнее.
а еще в ларе ну очень токсичное русскоязычное коммьюнити. не один раз уже сталкивался
А в чем это выражается? Дают вредные советы?
Наоборот. Отправляют читать доку, отвечая на вопросы по основам.
Раз вы начали за RSalo отвечать.
И в чем же тогда заключается смысл фразы «токсичное русскоязычное коммьюнити»?
И в чем же тогда заключается смысл фразы «токсичное русскоязычное коммьюнити»?
С моей стороны это была лишь ирония, т.к. есть довольно много участников, и я не исключение, которые на вопросы, вида «Почему у меня ошибка: can not call method on null» — вместо ответа на вопрос отправляют в документацию и отвечают фразами «не стоит браться за фреймворк, пока не изучил язык». Я не преувеличиваю — это действительно так, например: toster.ru/q/502732 А люди после этого начинают обижаться. А как ответить, мол, «друг, просто переведи сообщение об ошибке и всё станет понятно» — непонятно, т.к. это уже не первый и даже не второй вопросы подобного рода от некоторых начинающих. Потом такие новички обижаются.
Буквально под новый год проводили следственный эксперимент на тему «токсичности»: Взяли случайный вопрос с тостера, на который был дан ответ, вида «иди читать документацию» и «не надо вставлять код картинками, для этого есть соответствующий тег», с возражением «не хочешь помочь — не отвечай». Дальнейшая волна комментариев состояла из приперательств, на тему «не надо задавать вопросы, которые есть в документации, на темы, которые элементарно гуглятся».
Далее этот вопрос из под фейкового аккаунта был перемещён на стековерфлоу. При этом, для чистоты эксперимента — он был задан вообще в англоязычном сегменте (существует мнение, что на отечественных IT формуах/ресурсах — люди более «токсичные», а на зарубежных всё ок). В результате сам вопрос набрал "-2" за 2 или 3 часа, но, к слову сказать, один ответ там всё же был дан.
Вся эта история и сам эксперимент были проведены на стриме, часть которого был посвящён теме «почему подрастающее поколение так любит видеоуроки и не хочет учиться» и лежит в записи на ютубе, ссылку на которое, я могу кинуть в личку.
Я достаточно подробно расписал ответ?
Буквально под новый год проводили следственный эксперимент на тему «токсичности»: Взяли случайный вопрос с тостера, на который был дан ответ, вида «иди читать документацию» и «не надо вставлять код картинками, для этого есть соответствующий тег», с возражением «не хочешь помочь — не отвечай». Дальнейшая волна комментариев состояла из приперательств, на тему «не надо задавать вопросы, которые есть в документации, на темы, которые элементарно гуглятся».
Далее этот вопрос из под фейкового аккаунта был перемещён на стековерфлоу. При этом, для чистоты эксперимента — он был задан вообще в англоязычном сегменте (существует мнение, что на отечественных IT формуах/ресурсах — люди более «токсичные», а на зарубежных всё ок). В результате сам вопрос набрал "-2" за 2 или 3 часа, но, к слову сказать, один ответ там всё же был дан.
Вся эта история и сам эксперимент были проведены на стриме, часть которого был посвящён теме «почему подрастающее поколение так любит видеоуроки и не хочет учиться» и лежит в записи на ютубе, ссылку на которое, я могу кинуть в личку.
Я достаточно подробно расписал ответ?
Я достаточно подробно расписал ответ?
Да. Спасибо.
А я вижу главный и неоспоримый плюс Yii именно в виджетах. Такой удобной кодогенерации (разметки) я не видел ни в одном фреймворке ни на одном языке. Честно скажу — я не пользовался ларавелем, но немного читал его доки — и у него насколько я понял нет ничего подобного. Взять к примеру хелперы из ASP.NET (я вообще больше сишарпер): они генерируют лишь один тег который и обозначен в названии, например Html.TextBox — inpu а Html.Label — label. В то время как ActiveForm->field() в yii генерирует сразу инпут, вместе с меткой, валидцией и блоком для вывода ошибок. Это офигительно удобно! И хотя хелперы можно создать свои генерирующие что угодно — куда удобнее когда уже все сделано за тебя! Не говоря уже о том что в Yii встречаются виджеты легко генерирующие такую сложную (для бэкэндера) разметку которую не сверстаешь вот так сходу. Например вот этот грид (хоть и не из коробки, но установить же не проблема) я использовал в одном проекте. Нужна была такая вот многофункциональная таблица и все решилось с помощью этого чудо-виджета!
Если Вам виджеты нравится, Вам надо VueJs попробовать вместе с его однофайловыми .vue компонентами. Хороших результатов и высокой реюзабельности можно добиться.
Хорошая очень штука Vuetify. Очень много компонентов, удобно делать полноценное веб-приложение. Есть проблемы со встроенной версткой правда, кастомизировать сложно, но если к дизайну приложения придирок особых нет, то быстро и удобно. На Ларе, кстати, собирается на раз два mix'ом
может я не совсем правильно пользовался вуе, но блин — у меня как не крутил получался инвалид какой-то, а не удобные компоненты. чтобы построить на вуе тот же грид, нужно в любом случае подгружать в дом сырые данные, а затем уже их формировать в грид. проще уже отрендерить на серверной части, чем мудрить еще и на клиентской части. если уже делать на вуе нормальные компоненты, то уже делать на полноценном ресте, иначе получится такой же инвалид как и у меня
Компоненты решают эту проблему. Некоторые компоненты работают так, что можно с сервера получить, например json, собрать в объект, и объект отдать компоненту, он сам отрендерид гриды. В том же Vuetify, о котором я говорил выше, есть data-tables — компонент, который это делает. А компоненты реально удобные, сравнимы с реактовскими
Идея конечно хорошая, но я к сожалению не фронтендщик ни разу. Много раз пытался изучать фронт, но дальше jquery не зашло. Просто JS не люблю. Весь этот зоопарк инструментов сборки, библиотек и фреймворков меня сбивает с толку. С бэкэндом проще — тут обычно существует один инструмент сборки/зависимостей и один основной фреймворк. Хотя в PHP конечно побольше, но все равно в основном это Yii, Laravel и Symphony — не так уж много. Про CMS я вообще не говорю — не мое. Там одно кнопкотыкание в админке и ужасная процедурщина в коде…
У вас все таки получилось поднять холивар. Злые симфонисты не дадут спокойно пройти мимо них)
)) На самом деле очень интересно профессиональное сравнение Laravel 5.6 и Symfony 3.4/4.0 на долгоиграющих активно развивающихся проектах со сложной бизнес-логикой, учитывая, скажем так, заметно пересекающиеся кодовые базы. Как-то на небольших проектах с Laravel, сделанных по туториалам и ларакастам не очень понятны его преимущества, почему его кто-то выбирает со всей его магией и глобальными состояниями. Может как и в туториалах Symfony демонстрируется как можно быстро решить конкретную задачу, не заботясь о том, как дальше решение поддерживать. Классический пример: использование Symfony Forms в тесной связке с Doctrine Entity — bad practice с точки зрения чистой архитектуры, формы и сущности ничего общего не имеют, даже если их поля мапятся друг на друга 1:1 по случайному стечению обстоятельств.
Marco Pivetta в одном из своих докладов озвучивал тезис о том, что формы, примененные не к ДТО нарушают валидность объекта
В частности вот слайды (возможно надо поскроллить анимацию)
ocramius.github.io/doctrine-best-practices/#/51
ocramius.github.io/doctrine-best-practices/#/56
С другой стороны Symfony Forms не оперируют чистыми полями сущности, она работает через публичные методы, а это значит, что имея корректную DDD сущность без сеттеров (а с бизнес-логичными методами) вы не сможете привести ее в невалидное состояние формой и проблема исчезает. Но там становится сильно сложней конфигурация самой формы в таком случае, надо навешивать на нее дата мапперы, события и прочие радости жизни
Вот пример, как работать с VO через формы
webmozart.io/blog/2015/09/09/value-objects-in-symfony-forms
В частности вот слайды (возможно надо поскроллить анимацию)
ocramius.github.io/doctrine-best-practices/#/51
ocramius.github.io/doctrine-best-practices/#/56
С другой стороны Symfony Forms не оперируют чистыми полями сущности, она работает через публичные методы, а это значит, что имея корректную DDD сущность без сеттеров (а с бизнес-логичными методами) вы не сможете привести ее в невалидное состояние формой и проблема исчезает. Но там становится сильно сложней конфигурация самой формы в таком случае, надо навешивать на нее дата мапперы, события и прочие радости жизни
Вот пример, как работать с VO через формы
webmozart.io/blog/2015/09/09/value-objects-in-symfony-forms
Так и я про это. А если открыть мануал симфони к формам, то там форма прямо к сущности с сеттерами биндится. Ну и по опыту многие так и делают в проектах.
Так это не проблема формы, это проблема моделей у которых есть сеттеры. Если у модели есть сеттеры — ей по определению (задумке, факту, хз) можно вертеть как угодно, что и используется в формах по умолчанию, т.к. это самый распространенный (к сожалению) кейс.
Если убрать у сущности сеттеры, то выглядеть уже будет корректно, в этом случае форма сама будет выступать как DTO + трансформер, который правильным образом переложит данные (вызвав нужные методы в нужном порядке) в модель
Если убрать у сущности сеттеры, то выглядеть уже будет корректно, в этом случае форма сама будет выступать как DTO + трансформер, который правильным образом переложит данные (вызвав нужные методы в нужном порядке) в модель
Это проблема мануала к форме :) Сделаешь модель нормальную, уйдешь в отпуск, придешь а там уже сеттеры. Спршиваешь«зачем?!», ответ «а так формы не работают, по мануалу Симфони сеттеры должны быть»
По статье чувствуется поверхостное знание и Yii2 и Laravel.
сам я начинал с Laravel но ушел на Yii2.
С уверенностью могу сказать, что наговнокодить можно в любом реймворке.
Прокомментирую эти плюсы ларавел
> Имеет встроенный сборщик скриптов и scss
в Yii тоже есть встроенный сборщик. Но по мне в ларе реально удобнее.
> Встроенный шаблонизатор Blade
Он конечно прост, и в какой-то степени ограничивает говнокод. Но PHP сам по себе шаблонизатор. Я лично против дополнительных надстроек.
> Очень гибкое формирование Роутов
За все время мне еще не разу не попадалась задача на yii где не хватало бы гибкости формирования роутов.
> Очень гибкие возможности для написания REST API
аналогично предыдущему пункту
> Быстро развивается
не быстро развивается а потостоянно изменяется. Каждая новая версия слабосовместима с предыдущей. Обновления вызывают опасения. Поэтому с ларавела и соскочил.
в Yii всё стабильно. Критичных обновлений за последние года полтора не было. Обратная совместимость почти всегда есть. Только вот сейчас готовится критичное обновление Yii2.1 и то делают всё, что бы переход был гладким. А то вместо работы над проектом получается постоянное латание дыр за обновлениями.
В общем я на yii из-за стабильности перешел. Но ларевел мне по красоте кода нравится :-)
сам я начинал с Laravel но ушел на Yii2.
С уверенностью могу сказать, что наговнокодить можно в любом реймворке.
Прокомментирую эти плюсы ларавел
> Имеет встроенный сборщик скриптов и scss
в Yii тоже есть встроенный сборщик. Но по мне в ларе реально удобнее.
> Встроенный шаблонизатор Blade
Он конечно прост, и в какой-то степени ограничивает говнокод. Но PHP сам по себе шаблонизатор. Я лично против дополнительных надстроек.
> Очень гибкое формирование Роутов
За все время мне еще не разу не попадалась задача на yii где не хватало бы гибкости формирования роутов.
> Очень гибкие возможности для написания REST API
аналогично предыдущему пункту
> Быстро развивается
не быстро развивается а потостоянно изменяется. Каждая новая версия слабосовместима с предыдущей. Обновления вызывают опасения. Поэтому с ларавела и соскочил.
в Yii всё стабильно. Критичных обновлений за последние года полтора не было. Обратная совместимость почти всегда есть. Только вот сейчас готовится критичное обновление Yii2.1 и то делают всё, что бы переход был гладким. А то вместо работы над проектом получается постоянное латание дыр за обновлениями.
В общем я на yii из-за стабильности перешел. Но ларевел мне по красоте кода нравится :-)
не быстро развивается а потостоянно изменяется. Каждая новая версия слабосовместима с предыдущей. Обновления вызывают опасения. Поэтому с ларавела и соскочил.
Это было только два раза за всю историю, переход с 3.х на 4.х и с 4.х на 5.х. Можно было догадаться, почему эти версии мажорные.
ни фига, в 5.6 настройку логгинга поменяли, удалили интерфейс, переимновали пару классов, изменили порядочек в индексах, что может давать проблемы с откатом миграций, В 5.5 попереимновывали и поменяли логику в методах реквеста… bc в ларке ломают гораздо чаще… и это может быть не так критично на свежем проекте в разработке, но не на рабочем монстре.
Да это же мелочи, причём описанные в доке (ну кроме миграций). Обновление с Symfony 3.0 до 3.4 больше времени требует, нежели ап с 5.1 до 5.5. Ну это на моей практике было так, на других проектах может быть иначе.
Что сознательно поломали с 3.0 по 3.4? Нет, были, конечно, ошибки, приводящие к поломкам BC, но это ошибки, которые фиксились. Всё наследство 3.0, 3.1, 3.2 или 3.3, от которого решили отказаться в 4.0, в 3.4 просто deprecated должно быть — это официальная подход к развитию. 3.4 от 4.0 отличается выпиливанием этого deprecated. Ап с 3.1 на 3.4 на довольно большом проекте безболезненно прошёл, после выпиливания deprecated в логах, на 4.0 тоже.
Встроенный сборщик основан на WebPack
Очень жирный минус. Всюду таскать этого тормозного монстра… ну нафиг.
Привет dastanaron_dev, а есть смысл переписывать сайт на laravel, если он на yii написан? Планируем к сайту добавить личный кабинет с возможностью оплаты, говорят yii сложнее масштабировать.
Привет elenk_r, я думаю, что я не в праве давать в данном случае какие-либо советы, по той причине, что я не знаю ни ваш действующий ресурс, ни доработок, которые требуются сделать. Yii2 можно мастабировать, но есть определенные нюансы связывающие руки в некотором смысле, но они есть и у других фреймов. Тут надо рассматривать позадачно и по трудозатратам. Если текущий проект не сложно переложить на Laravel и он решает другие проблемы, то смысл конечно есть. Если же планируется масштабирование еще в будущем, помимо ЛК и оплат, я бы посоветовал смотреть в сторону микросервисной архитектуры, где вообще каждый сервис может работать на своем фреймворке, но это тоже несет существенные минусы, зато хорошо подходит в качестве временных переходных решений, позволяет параллельно переписывать старые сервисы на новый движок. А если текущий проект не очень большой и нужно только добавить личный кабинет с небольшим количеством настроек и оплат, тут и Yii2 с легкостью справится с этой задачей. Если в ближайшем будущем не требуется серьезных расширений, я бы оставил старый движок, так как и команде с ним привычней работать и сделать будет быстрее чем переписывать с нуля. Однако нужно еще понимать, насколько «загажен» в коде ваш текущий проект. Если там он так сделан, что масштабирование настолько сложное, что почти невозможное, то пора писать новый проект, на чем то новом.
Ну и еще. Если планируется серьезное масштабное расширение с кучей фич и переход на микросервисную, я бы предложил смотреть в сторону минималистичных фреймворков, типа Silex (сейчас устарел) или Symfony 4, где все лишнее из коробочной сборки выпилино, даже doctrine. Все можно установить, но уже по раздельности. Для крупных растущих проектов самое оно, есть контроллеры и все, модели и остальную архитектуру организуй как хочешь!
Ну и еще. Если планируется серьезное масштабное расширение с кучей фич и переход на микросервисную, я бы предложил смотреть в сторону минималистичных фреймворков, типа Silex (сейчас устарел) или Symfony 4, где все лишнее из коробочной сборки выпилино, даже doctrine. Все можно установить, но уже по раздельности. Для крупных растущих проектов самое оно, есть контроллеры и все, модели и остальную архитектуру организуй как хочешь!
В целом, laravel и yii достаточно схожи идеологически, как по мне, и в общем случае переписывание смысла мало имеет. Хотя, конечно, могут быть ситуации, когда что-то конкретное в одном фреймворке сильно мешает проекту, а во втором фреймворке хотя бы мешать не будет.
Использую Yii2 advanced, bootstrap4, vue, по моему это лучшее что можно придумать. Особенно если жестко придерживаться начальной архитектуры.
На Yii3 переходить на планируете?
Пока вижу для себя риски, у нас небольшая фирма. Не хочется столкнуться с непредвиденными не пофикшенными багами фреймворка.
Я больше про архитектурные изменения. Если Yii2 для вас лучшее, что можно придумать, то Yii3 может оказаться разочарованием.
Нет, я говорю конкретно об advanced шаблоне. В чистом виде yii2 не зашел. К сожалению без четкого определения расположения контроллеров, моделей, шаблонов — получается такой же г*но код как и на чистом php, только сложнее. С этим шаблоном, вход нового программиста на работающий проект занимает пару часов. Поэтому если под капотом будет yii3 — существенно ничего не поменяется.
Важный момент — не менять при этом роуты. Стандартизация — наше все ))
Важный момент — не менять при этом роуты. Стандартизация — наше все ))
Вот зря вы так. На чистом PHP можно сделать хорошую архитектуру, без всяких фреймворков, просто время разработки будет существенно увеличено. Да, это не самая тривиальная задача, целая куча книг об архитектуре, и порой сложно выбрать или создать подходящую под конкретный проект, но тем не менее! На чистом можно делать красиво и без говнокода. Я в этом убедился поработав в Roistat
В итоге, скорее всего, получится свой фреймворк или что-то что легко в него превращается.
Да, так и получились большинство фреймоворков, возможно)))
Ну я например видел такой подход. Берут бибилиотеки готовые, например для маршрутизации и ORM для БД, и создают собственную архитектуру где это и как должно лежать. По сути да получается собственный фреймворк, при грамотной архитектуре лучше чем любой публичный, в том плане, что хорошо подходит под текущий проект, а минусы как правило в том, что не очень универсальный и документации мало)
Ну я например видел такой подход. Берут бибилиотеки готовые, например для маршрутизации и ORM для БД, и создают собственную архитектуру где это и как должно лежать. По сути да получается собственный фреймворк, при грамотной архитектуре лучше чем любой публичный, в том плане, что хорошо подходит под текущий проект, а минусы как правило в том, что не очень универсальный и документации мало)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Выбираем Yii2 или laravel