Соблюдение — да. Но как вы сами и сказали Декоратор дает дополнительное поведение.
Если кратко то вот:
Adapter предоставляет к своему объекту другой интерфейс.
Proxy предоставляет тот же интерфейс, управляя обращениями к вложенному объекту.
Decorator предоставляет расширенный интерфейс.
Вы тоже всё напутали. Именно Proxy дает доступ к внутреннему объекту с сохранением интерфейса но с например выполнением внутри дополнительной логики. А Decorator дает дополнительный функционал, т.е. имеет свой интерфейс.
т. е.
предполагает обёртывание объекта с сохранением интерфейса и предпологает обёртывание существующих методов
Потому что Так как Модели в Ларе это AR то они и так часто перегружены логикой. И порой хочется чуток их разгрузить. И тут кто во что горазд) Сериализация всё же мне нравится больше через уже упомянутый fractal. А вот презенторы приятно использовать как часть view layer.
Надеюсь что автор просто забыл пометить пост как перевод) На всякий случай я напомню, что оригинал тут http://davidhemphill.com/blog/2016/09/06/presenters-in-laravel/
По пункту отправки писем. Очень удобно использовать mailtrap.io.
По окружению: уже или «по взрослому» работать и повторять прод в виртуалке или забить на redis, apache, nginx.
ставим в .env CACHE_DRIVER=file
SESSION_DRIVER=file
QUEUE_DRIVER=sync
и работаем через встроенный сервер. В итоге нужны только php+node+git. Можно и базу sqlite использовать.
Вы показываете просто свою некомпетентность. Причем тут те мнимые (потому как я не вижу у себя таковых и доказательств в виде таймлайнов загрузки и т.п. я не вижу) тормоза описанных вами сайтов и препроцессинг css?
раньше же как-то писали без всяких сас? писали
чего сейчас не могут?
Ну это вообще даже не знаю как на такое отвечать) Представляете, могут, но не хотят, потому что лучше стало. И на производительность конечного результата (при условии отсутствия ошибок, которые так то и с простым css навернуть можно) наличие препроцессора не влияет. А вот на скорость разработки и удобство поддержки очень даже влияет.
Не понял, какие трудности? прописываете зависимость в package.json и всё. Но ставить то конечно надо будет `npm i`. Вы же вендорный php код тоже не храните в репе и делаете `composer inst`.
Не должен artisan собирать ни стили, ни скрипты, ни картинки пережимать и т. д. Он для backend. Работа с frontend это нода уже давно и прочно. Вот руби в этом стеке лишний конечно.
Это не преимущества («превосходство в сравнении с кем-чем-н. другим») Yii, так как это есть во всех современных php фреймворках. И Некоторые превосходят (объективно или субъективно) Yii по части изложенных пунктов.
Как то слишком просто для статьи на хабре…
Да еще и расширение сервиса валидации не самое качественное. Хотя такой пример и дан в документации. Но сервисы лучше расширять отложено через $this->app->extend… ибо не на каждый запрос нужна валидация. А в случае расширения через фасад, сервис который за ним, будет порожден, даже если он не нужен.
Если кратко то вот:
Adapter предоставляет к своему объекту другой интерфейс.
Proxy предоставляет тот же интерфейс, управляя обращениями к вложенному объекту.
Decorator предоставляет расширенный интерфейс.
т. е.
Вот это как раз Прокси
Не совсем верно. Это не тип драйвера это имя подключения по умолчанию из конфига database.connections.
По окружению: уже или «по взрослому» работать и повторять прод в виртуалке или забить на redis, apache, nginx.
ставим в .env
CACHE_DRIVER=file
SESSION_DRIVER=file
QUEUE_DRIVER=sync
и работаем через встроенный сервер. В итоге нужны только php+node+git. Можно и базу sqlite использовать.
Ну это вообще даже не знаю как на такое отвечать) Представляете, могут, но не хотят, потому что лучше стало. И на производительность конечного результата (при условии отсутствия ошибок, которые так то и с простым css навернуть можно) наличие препроцессора не влияет. А вот на скорость разработки и удобство поддержки очень даже влияет.
Это не преимущества («превосходство в сравнении с кем-чем-н. другим») Yii, так как это есть во всех современных php фреймворках. И Некоторые превосходят (объективно или субъективно) Yii по части изложенных пунктов.
Да еще и расширение сервиса валидации не самое качественное. Хотя такой пример и дан в документации. Но сервисы лучше расширять отложено через $this->app->extend… ибо не на каждый запрос нужна валидация. А в случае расширения через фасад, сервис который за ним, будет порожден, даже если он не нужен.