Вроде же тут же вроде явная статическая зависимость от User:
protected function send(User $user)
Да, вы правы, это зависимость. Код сам по себе вообще не может существовать в вакууме. Он всегда от чего-то и в какой-то мере зависит. В статье, возможно, не достаточно ясно представлено назначение DTO объектов, под словом «клей». Более детально — то это наши объекты, которые выражают предметную область нашего проекта. Они формируют термины, в которых части проекта общаются между собой. И да, для того, чтобы части проекта могли друг с другом взаимодействовать им нужно общаться на одном и том же языке.
Можно эту зависимость ослабить, используя интерфейсы в описании вместо объектов, но особого практического смысла в этом не вижу.
Очень спорное утверждение, особенно на вашем искусственном простом примере. Вместо простого линейного когда имеем сложную цепочку событий в разных модулях.
Для того, чтобы не ломать голову что за чем идет и по какому событию и ввели карту событий в конфиге, чтобы было видно наглядно
Ее можно хранить хоть в глобальном конфиге для всех модулей, хоть для каждого модуля отдельно (тогда в файле кеша конфигов она полностью построится и там ее можно будет найти). На самом деле, из опыта, цепочки получаются не такие уж и монструозные. Обычно один ивент — это один, два обработчика, как-то привыкаешь по ним дебаггером ползать — и какого-то дискомфорта не ощущаешь.
Не понятно чем это поможет.
Иногда сильно помогает, когда поддерживаешь систему, в которой не все уголки исследованы, а те что исследованы — не все умещаются в памяти. Ставится задача бизнесом в терминах бизнеса: отправить письмо человеку, который был на групповом занятии, после окончания этого занятия. И вместо того, чтобы долго и нудно рыться по коду где там то занятие, как и кем закрывается. Смотришь на карту ивентов, которая является набором событий в системе языком бизнеса, находишь, кем-то заботливо оставленный ивент завершения группового занятия и цепляешь туда следующим обработчиком свой новый обработчик, особо не вникая в дебри уже написанного кода.
Как было замечено в статье — у нас уже сложилась большая кодовая база и никто переписывать ее не будет. И статья адресована тем, у кого похожая ситуация, когда проект пишется и развивается с Zend 2.0.0.
Ну а так, совет с Zend-Expressive дельный. Сами его используем в сопутствующих проектах (частях системы), которые начинали разрабатывать в течении последнего года.
После Zend 2 и Symfony 2 пришлось на новой работе работать с Laravel 5. Проект довольно большой по объему кода. Сначала думал, что проект плохо написан, после прочтения кучи статей — понял, что код проекта похож по стилю на код, который в любом примере по ларавелю можно найти (статические вызовы везде по коду, компоновка запроса к БД прямо из контроллера, да и где угодно по коду).
Думал как улучшить код — ввести расслоение кода, прокидывать все зависимости через конструктор или сеттеры, а не вызывать статические методы фасадов, выкинуть Eloquent и подключить Doctrine 2, выкинуть блейд, разделить код на модули, чтобы по паре сотен файлов не лежало в директории с контроллерами и столько же с моделями. Но тогда не понятно что остается от фреймворка — получается такая себе Symfony 2.
В итоге для себя решил, что все-таки Laravel не подходит для проектов с большим объемом кода, раз из него, в таком проекте, сильно хочется сделать другой фреймворк, значит тот другой — гораздо лучше подходит для организации кода в большом проекте.
Да, вы правы, это зависимость. Код сам по себе вообще не может существовать в вакууме. Он всегда от чего-то и в какой-то мере зависит. В статье, возможно, не достаточно ясно представлено назначение DTO объектов, под словом «клей». Более детально — то это наши объекты, которые выражают предметную область нашего проекта. Они формируют термины, в которых части проекта общаются между собой. И да, для того, чтобы части проекта могли друг с другом взаимодействовать им нужно общаться на одном и том же языке.
Можно эту зависимость ослабить, используя интерфейсы в описании вместо объектов, но особого практического смысла в этом не вижу.
Для того, чтобы не ломать голову что за чем идет и по какому событию и ввели карту событий в конфиге, чтобы было видно наглядно
Ее можно хранить хоть в глобальном конфиге для всех модулей, хоть для каждого модуля отдельно (тогда в файле кеша конфигов она полностью построится и там ее можно будет найти). На самом деле, из опыта, цепочки получаются не такие уж и монструозные. Обычно один ивент — это один, два обработчика, как-то привыкаешь по ним дебаггером ползать — и какого-то дискомфорта не ощущаешь.
Иногда сильно помогает, когда поддерживаешь систему, в которой не все уголки исследованы, а те что исследованы — не все умещаются в памяти. Ставится задача бизнесом в терминах бизнеса: отправить письмо человеку, который был на групповом занятии, после окончания этого занятия. И вместо того, чтобы долго и нудно рыться по коду где там то занятие, как и кем закрывается. Смотришь на карту ивентов, которая является набором событий в системе языком бизнеса, находишь, кем-то заботливо оставленный ивент завершения группового занятия и цепляешь туда следующим обработчиком свой новый обработчик, особо не вникая в дебри уже написанного кода.
Ну а так, совет с Zend-Expressive дельный. Сами его используем в сопутствующих проектах (частях системы), которые начинали разрабатывать в течении последнего года.
Думал как улучшить код — ввести расслоение кода, прокидывать все зависимости через конструктор или сеттеры, а не вызывать статические методы фасадов, выкинуть Eloquent и подключить Doctrine 2, выкинуть блейд, разделить код на модули, чтобы по паре сотен файлов не лежало в директории с контроллерами и столько же с моделями. Но тогда не понятно что остается от фреймворка — получается такая себе Symfony 2.
В итоге для себя решил, что все-таки Laravel не подходит для проектов с большим объемом кода, раз из него, в таком проекте, сильно хочется сделать другой фреймворк, значит тот другой — гораздо лучше подходит для организации кода в большом проекте.