Всем привет! В книге Фаулера "Архитектура корпоративных програмных приложений" описаны три способа представления бизнес логики: Сценарий транзакции (Transaction Script), Модель предметной области (Domain Model) и Модуль таблицы (Table Module), в дальнейшем именую их, как СТ, МПО и МТ сооветственно. Так как СТ меня не интересует и врядли часто используется с asp.net mvc, я буду говорить только о МПО и МТ.
Представим такую архитектуру:
Контроллер - занимается исключительно роутингом и всем что связано с представленим, о получении данных он ничего не знает.
Модель - несколько классов которые не имеют точного соответствия ни с контроллерами, ни с сущностями БД. Делает однообразную работу, в основном получение через репозитории необходимых данных, без сложной логики.
Репозитории - простые операции запросов к Entity Framework. Один репозиторий, одна сущность Entity Framework.
Entity Framework - простые сгенерированные по БД сущности.
В основном много однообразной работы, но иногда при возникновении сложной логики код становится ужасным.
Так вот, как можно назвать архитектуру такого приложения МПО или МТ? С одной стороны здесь ничего общего с МПО, ведь никаких архитектурных изощрений нет, но по идее с МТ тоже мало общего. Цитата с книги - "Основное отличие модуля таблицы от модели предметной
области состоит в том, что если, например, приложение обслуживает множество заказов, в соответствии с моделью предметной области придется сконструировать по одному
объекту на каждый заказ, а при использовании модуля таблицы понадобится всего один
объект, представляющий одновременно все заказы.". А как мы знаем при использовании Entity Framework придется сконструировать по одному объекту на каждый заказ.
Как это все понимать, это основанная на EF мутация обоих видов? Также помнится, что в той книге автор писал, что присутствие EF в платформе .net побуждает писать в стиле МТ, но лучше писать с МПО, так как такая система легко расширяется. Я так и не понимаю, как это должно быть устроено? И как выглядят настоящие ООП приложения с использованием EF?
Ну кажется это все, надеюсь на ответы. Спасибо!
Продолжение размышлений в сторону роли контроллера в такой архитектуре ищите здесь
Ответ
(Это не совсем ответ на вопрос, скорее, некоторый поток мыслей, который, возможно, окажется вам полезным)
В архитектуре, которую "нужно представить", есть изъян — использование skinny models.
Модель не должна заниматься перекладывание объектов из пустого в порожнее, а должна быть близка к problem domain и должна содержать domain-specific логику. Все проверки, конвертации сущностей, вообще все, что можно вынести из контроллера без нарушения принципов MVC, должно быть в модели.
Довольно странным выглядит упоминание репозиториев и Entity Framework при разговоре об архитектуре.
Это — детали реализации интерфейса модели, которые к архитектуре имею довольно посредственное отношение. Хорошо спроектированном интерфейс модели должен допускать подмену Entity Framework на произольный ORM или, например, на stub реализацию, которая читает данные из .txt файла.
То есть, если мы уж говорим об MVC, то репозитории и EF напрямую с ним не связаны. А значит дизайн layer'a с Entity Framework нужно рассматривать отдельно.
На эту тему могу посоветовать избавиться от такой сущности как репозиторий, поскольку она, скорее всего, является лишним abstraction layer, вводит ненужную сложность и неявно приводит к написанию слишком обобщенного кода
"Ой, а чтобы протащить такой запрос к сущностям придется модифицировать Repository
Комментариев нет:
Отправить комментарий