Здравствуйте, zelenprog, Вы писали:


Z>Здравствуйте!

Z>Прочитал вот эту статью:
Z>"Охота на мифический MVC. Построение пользовательского интерфейса"
Z>https://habr.com/ru/articles/322700/

Z>В ней говорится, что обращение из пользовательского интерфейса к бизнес-логике надо обязательно выполнять через Фасад.
Z>Вот картинка:

Z>Image: Охота на мифический MVC. Универсальная схема MVC _ статья.png

Z>В связи с этим два вопроса:

Z>1) Получается, что этот Фасад должен знать как обработать все запросы, поступающие от клиента.
Z>Значит, это по сути God-object. Верно?
Z>Но это же анти-паттерн! Разве так правильно делать?

Z>2) А нужен ли этот Фасад для веб-приложений?
Z>Ведь в веб-приложениях клиент и сервер "общаются" через веб. На стороне сервера есть единая "точка", которая принимает все запросы.
Z>Можно ли эту "точку" считать Фасадом?


Все очень сильно зависит.
Задача фасада в данном случае изолировать доменные сущности от UI.
Может получить так: имеем доменную сущность, она прорастает во все представления или модели представления. Потом разрабы доменной модели говорят, мы сейчас сущность распилим и данные будут приходить вообще по другому.
и вот такое изменение может затронуть очень больше количество кода, а еще могут не дай бог сериализовать эту модель в настройки и придется писать миграции и таскать ее везде.
По этому в развесистом приложении вешают фасад/адаптер, который интерфейс доменной модели преобразует в интерфейс модели представления и добавляет развязку сущностей и позволяет с меньшим количеством изменений менять либо доменную модель либо модель представления.
Вообще картинки странно нарисованы, в слоено компонентной архитектуре связи "знает" обычно идут сверху вниз.
Главное во всех MVC MVP MVVM соблюдать модульность и сегрегированные интерфейсы. Вырожденно писать под паттерны нафиг не надо.

Здравствуйте, zelenprog, Вы писали:


Z>Здравствуйте!

Z>Прочитал вот эту статью:
Z>"Охота на мифический MVC. Построение пользовательского интерфейса"
Z>https://habr.com/ru/articles/322700/

Z>В ней говорится, что обращение из пользовательского интерфейса к бизнес-логике надо обязательно выполнять через Фасад.
Z>Вот картинка:

Z>Image: Охота на мифический MVC. Универсальная схема MVC _ статья.png

Z>В связи с этим два вопроса:

Z>1) Получается, что этот Фасад должен знать как обработать все запросы, поступающие от клиента.
Z>Значит, это по сути God-object. Верно?
Z>Но это же анти-паттерн! Разве так правильно делать?

Z>2) А нужен ли этот Фасад для веб-приложений?
Z>Ведь в веб-приложениях клиент и сервер "общаются" через веб. На стороне сервера есть единая "точка", которая принимает все запросы.
Z>Можно ли эту "точку" считать Фасадом?


Все очень сильно зависит.
Задача фасада в данном случае изолировать доменные сущности от UI.
Может получить так: имеем доменную сущность, она прорастает во все представления или модели представления. Потом разрабы доменной модели говорят, мы сейчас сущность распилим и данные будут приходить вообще по другому.
и вот такое изменение может затронуть очень больше количество кода, а еще могут не дай бог сериализовать эту модель в настройки и придется писать миграции и таскать ее везде.
По этому в развесистом приложении вешают фасад/адаптер, который интерфейс доменной модели преобразует в интерфейс модели представления и добавляет развязку сущностей и позволяет с меньшим количеством изменений менять либо доменную модель либо модель представления.
Вообще картинки странно нарисованы, в слоено компонентной архитектуре связи "знает" обычно идут сверху вниз.
Главное во всех MVC MVP MVVM соблюдать модульность и сегрегированные интерфейсы. Вырожденно писать под паттерны нафиг не надо.
При этом этих фасадов может быть 100500, и никаких god object