Pascal/Object Pascal гораздо более продуманный язык, чем питон, и, кроме того, приучает к статической типизации и необходимости компилировать. Я бы сказал, начиная с паскаля, больше шансов получить в итоге программиста, а не веб-макаку.
Без всяких проблем реализовывал поддержку json и xml запросов в Symfony с помощью листенера события kernel.request. Получится несколько более многословно, но ничуть не хуже по сути.
Ну здесь как раз можно вспомнить про принцип единственной ответственности. Если в конструкторе слишком много аргументов — то явно что-то не так, и, может быть, стоит разделить серивис на несколько?
Вы можете привести пример, где без этого действительно нельзя было бы обойтись и не хватило бы, скажем, инъекции в конструктор?
И я, кстати, не утверждал, что в Symfony DI лучше, чем в Laravel. Речь вообще шла не о возможностях фреймворков, а о практиках, принятых в том или ином сообществе.
Нет, он будет вызываться в реализации репозитория в слое инфраструктуры. Делать это в контроллере (да и вообще делать в контроллере что либо) — крайне плохая практика.
Если инстанс ActiveRecord используется не только в инфраструктурном слое, а и в доменном, то нет.
А если он используется только в инфраструктурном, то это уже не ActiveRecord, а Row Gateway. А если использовать его таким образом, то зачем тем более нужен Eloquent, можно обойтись и Doctrine\DBAL или Zend\Db.
Не «невозможность» (благодаря неплохому DI-контейнеру эта возможность еще как есть), а неприятие этой практики в ларавел-сообществе.
1. Нет, не столько из-за «магии», сколько из-за сильной связанности. Если мы, например, инъектируем сервис по интерфейсу, то можем легко подменить реализацию, вообще ничего не меняя в зависящих от него классах и прочем. Причем интерфейс может находиться именно в нужном слое, ничего не знающем о реализации. Таким образом достигается слабая связанность.
2. Hexagonal, DDD, CQRS/Event-sourcing и тому подобные архитектурные паттерны. Он дает возможность писать большие, поддерживаемые, слабосвязанные проекты, с бизнес-логикой сложнее, чем круды. Писать на ларавеле в этом стиле можно, но мало кто так делает — ведь это же так здорово — дергать фасады где хочешь.
Соглашусь. Причем следующим этапом будет отказ от framework-standard-edition и сборка своего решения из компонентов Symfony/Zend, чтобы не привязываться к системе бандлов.
Symfony Microkernel и грядущий Symfony 4 — шаги в очень правильном направлении.
Про DDD и гексогоналку. Мне казалось, что суть этих технологий как раз в отсутствии привязки к стораджам и всяким eloquent или doctrine. Мне кажется вторая даже вреднее, так как люди тешат себя иллюзией о правильной архитектуре, а по сути вместо спагетти кода пишут лазанью.
Безусловно Вы правы, но Doctrine (если использовать ее правильно) — это единственная ORM на PHP, которая позволяет приблизиться к принципу persistence ignorance. В конечном счете, для доменного слоя репозиторий — это только интерфейс, и его может в инфраструктурном слое имплементировать класс, наследующий в то же время EntityRepository. В случае же с другими ORM придется вручную «пересыпать» данные внутри репозитория в доменную сущность.
Но есть laracast демонстрирующий хорошие практики.
Помню, долго смеялся, когда автор ларакаст запилил курс с примерами по DDD в ларавеле. Команды у него в себе носили модели, а репозиторий возвращал экземпляр Eloquent'а. Называется — «слышал звон, да не знаю, где он».
То что вы не видите разнцицу между статистическими вызовами и фасадами, это не говорит, о том, что это ничего не меняет.
Ну так просветите, что это меняет для меня, как пользователя фреймворка? Фасады, пожалуй, даже хуже — работают на «магии» (помню, сильно удивился, когда в первый раз перешел к определению «фасадного» метода) и даже для автокомплита в IDE требуют костылей.
Когда мне начинают рассказывать, что на Laravel говнокодят, что Eloquent нарушает принцип единой ответственности и показывают тру «enterprise-like практики»
Вы, видно, не писали более-менее больших проектов с сотней хитрожопо взаимосвязанных сущностей. Да даже без этого — «чистая» модель как сущность бизнес-логики гораздо удобнее, чем ActiveRecord с магическими свойствами. Не говоря уж о том, что, даже безотносительно SRP, как правило таблица БД не полностью идентична сущности бизнес-процесса (за исключением самых простых случаев).
Я прекрасно понимаю, как можно использовать фреймворк в ынтырпрайз-стиле. Я говорю о том, что ни документация, ни сообщество, ни стартовая структура директорий, к этому совершенно не поощряют.
Придет новичок-вчерашний сайтошлеп, который не слышал про SOLID, GRASP, сервисы, интерфейсы и прочие умные слова (а мы почти все такими были когда-то), и увидит ваши статические вызовы чего угодно откуда угодно, и подумает, что так и надо делать. Да, быдлокод на чем угодно можно писать, но ларавел к этому просто подталкивает.
Весь интернет, не считая монстров типа google, — пачка примитивных крудов.
Я говорю о всяких там SaaS, ERP-системах и прочем. Там бывает, что бизнес-логика не укладывается в модель крудов, изредка даже головой приходится подумать. Нравится нам это или нет, но PHP уже давно на полном серьезе пришел в enterprise-разработку.
Дайте угадаю, Вы — евангелист Ларавела и вам за это платят?
Вы рекомендуете читать документацию, и следовать практикам, принятым в ларавел-сообществе, а я уже упомнянул, что документация и сообщество как раз таки поощряют писать говнокод, не рассказывая о том, что возможен другой путь (enterprise-like практики).
Хотя, конечно, для типового веб-приложения (== пачки примитивных крудов) этого более чем достаточно, и скорость разработки куда важнее. А до поддержки и наращивания функционала, скорее всего, даже и не дойдет — редкий мегасовременный хипстерский стартап живет больше года.
Вроде и хорош Laravel на первый взгляд, но, по факту, для более-менее серьезного использования он годится только после доработки стандартного сетапа и нарушения всего, что говорит документация и предлагают авторы.
В ларавеле можно использовать инъекцию зависимостей по интерфейсу, заменить ущербный Eloquent на Doctrine (или вообще обойтись без готовой ORM), можно запилить структуру проекта согласно принципам «гексагональной архитектуры» или DDD, да и вообще много чего можно сделать.
Но, по факту, официальная документация и туториалы предлагает вместо этого использовать статические фасады для доступа к чему угодно (начиная с 5 версии — так и вообще просто глобальные функции типа app(), dispatch() и т.д. Забавно, что сам Тейлор аргументирует тем, что, мол, «под капотом» фасадов и функций на самом-то деле DI-контейнер инстанцирует объекты, как будто это что-то меняет)
Макаки, разумеется, в восторге — можно говнокодить безо всяких ограничений не включая мозг. Напрямую обратиться к БД в темплейте? Легко! Вызвать какой-либо сервис прямо из модели? Запросто! И именно поэтому ларавел так популярен! На западе уже, фактически, это «новый вордпресс». Да, казалось бы, дело в макаках, а не в ларавеле, но почему тогда документация учит «плохим» практикам, даже толком не упоминая о «хороших»?
А про «экосистему» и говорить не хочется — с каких пор привязка к вендорским инструментам стала благом?
То есть, все-таки нужно создавать «цветовую карту» исходного изображения, и нейросеть рисует уже основываясь на ней? Это т.н. «процедурное текстурирование», и существует уже достаточно давно. Есть несколько инструментов для художников по текстурам (самый популярный — Quixel Suite), в которых используется этот метод. То есть, натурально, рисуете на развертке цветовую карту, и он по этим цветам заполняет текстурами из библиотеки материалов (металл, кожа и т.д.). Так что ничего нового.
Вы можете привести пример, где без этого действительно нельзя было бы обойтись и не хватило бы, скажем, инъекции в конструктор?
И я, кстати, не утверждал, что в Symfony DI лучше, чем в Laravel. Речь вообще шла не о возможностях фреймворков, а о практиках, принятых в том или ином сообществе.
Неправда. А с версии 3.3 DI стал еще удобнее.
А если он используется только в инфраструктурном, то это уже не ActiveRecord, а Row Gateway. А если использовать его таким образом, то зачем тем более нужен Eloquent, можно обойтись и Doctrine\DBAL или Zend\Db.
1. Нет, не столько из-за «магии», сколько из-за сильной связанности. Если мы, например, инъектируем сервис по интерфейсу, то можем легко подменить реализацию, вообще ничего не меняя в зависящих от него классах и прочем. Причем интерфейс может находиться именно в нужном слое, ничего не знающем о реализации. Таким образом достигается слабая связанность.
2. Hexagonal, DDD, CQRS/Event-sourcing и тому подобные архитектурные паттерны. Он дает возможность писать большие, поддерживаемые, слабосвязанные проекты, с бизнес-логикой сложнее, чем круды. Писать на ларавеле в этом стиле можно, но мало кто так делает — ведь это же так здорово — дергать фасады где хочешь.
Symfony Microkernel и грядущий Symfony 4 — шаги в очень правильном направлении.
Безусловно Вы правы, но Doctrine (если использовать ее правильно) — это единственная ORM на PHP, которая позволяет приблизиться к принципу persistence ignorance. В конечном счете, для доменного слоя репозиторий — это только интерфейс, и его может в инфраструктурном слое имплементировать класс, наследующий в то же время EntityRepository. В случае же с другими ORM придется вручную «пересыпать» данные внутри репозитория в доменную сущность.
Помню, долго смеялся, когда автор ларакаст запилил курс с примерами по DDD в ларавеле. Команды у него в себе носили модели, а репозиторий возвращал экземпляр Eloquent'а. Называется — «слышал звон, да не знаю, где он».
Ну так просветите, что это меняет для меня, как пользователя фреймворка? Фасады, пожалуй, даже хуже — работают на «магии» (помню, сильно удивился, когда в первый раз перешел к определению «фасадного» метода) и даже для автокомплита в IDE требуют костылей.
Вы, видно, не писали более-менее больших проектов с сотней хитрожопо взаимосвязанных сущностей. Да даже без этого — «чистая» модель как сущность бизнес-логики гораздо удобнее, чем ActiveRecord с магическими свойствами. Не говоря уж о том, что, даже безотносительно SRP, как правило таблица БД не полностью идентична сущности бизнес-процесса (за исключением самых простых случаев).
Придет новичок-вчерашний сайтошлеп, который не слышал про SOLID, GRASP, сервисы, интерфейсы и прочие умные слова (а мы почти все такими были когда-то), и увидит ваши статические вызовы чего угодно откуда угодно, и подумает, что так и надо делать. Да, быдлокод на чем угодно можно писать, но ларавел к этому просто подталкивает.
Я говорю о всяких там SaaS, ERP-системах и прочем. Там бывает, что бизнес-логика не укладывается в модель крудов, изредка даже головой приходится подумать. Нравится нам это или нет, но PHP уже давно на полном серьезе пришел в enterprise-разработку.
Вы рекомендуете читать документацию, и следовать практикам, принятым в ларавел-сообществе, а я уже упомнянул, что документация и сообщество как раз таки поощряют писать говнокод, не рассказывая о том, что возможен другой путь (enterprise-like практики).
Хотя, конечно, для типового веб-приложения (== пачки примитивных крудов) этого более чем достаточно, и скорость разработки куда важнее. А до поддержки и наращивания функционала, скорее всего, даже и не дойдет — редкий мегасовременный хипстерский стартап живет больше года.
В ларавеле можно использовать инъекцию зависимостей по интерфейсу, заменить ущербный Eloquent на Doctrine (или вообще обойтись без готовой ORM), можно запилить структуру проекта согласно принципам «гексагональной архитектуры» или DDD, да и вообще много чего можно сделать.
Но, по факту, официальная документация и туториалы предлагает вместо этого использовать статические фасады для доступа к чему угодно (начиная с 5 версии — так и вообще просто глобальные функции типа app(), dispatch() и т.д. Забавно, что сам Тейлор аргументирует тем, что, мол, «под капотом» фасадов и функций на самом-то деле DI-контейнер инстанцирует объекты, как будто это что-то меняет)
Макаки, разумеется, в восторге — можно говнокодить безо всяких ограничений не включая мозг. Напрямую обратиться к БД в темплейте? Легко! Вызвать какой-либо сервис прямо из модели? Запросто! И именно поэтому ларавел так популярен! На западе уже, фактически, это «новый вордпресс». Да, казалось бы, дело в макаках, а не в ларавеле, но почему тогда документация учит «плохим» практикам, даже толком не упоминая о «хороших»?
А про «экосистему» и говорить не хочется — с каких пор привязка к вендорским инструментам стала благом?