В многоуровневой архитектуре MVC класс репозитория является частью бизнес-уровня или нет?

Question

предположим, что у вас есть приложение MVC с Model , представленной Entity Framework (EF), которая "получает" данные из базы данных и методы действий Controller , который реализует все бизнес логика. Контроллер получает данные из базы данных через EF.

Представьте себе, что теперь вы создаете класс репозитория , который помещается между контроллером и моделью. Таким образом, у вас есть:

1) Контроллер : реализует большую часть бизнес-логики;

2) A Класс репозитория , отвечающий за реализацию простой бизнес-логики, предоставляет данные каждому контроллеру в приложении через методы и получает данные из EF;

3) Модель : классы EF, которые получают данные из базы данных и передают их в класс репозитория .

Является ли класс Repository уровнем бизнес-службы или существует необходимость добавить бизнес-уровень, помещенный между контроллерами и репозиторием? В этой последней ситуации мы имеем:

1) Контроллеры : реализует только обработку запроса;

2) Бизнес-уровень : набор классов, отвечающих за реализацию большей части бизнес-логики и предоставление данных каждому контроллеру в приложении с помощью методов;

3) A Класс репозитория : получает данные из EF и предоставляет методы для Бизнес-уровня для запросов к базе данных;

4) Модель : классы EF, которые "получают" данные из базы данных и предоставляют их в класс репозитория .

Я не рассматриваю вид, потому что он не актуален. Я надеюсь, что кто-то может объяснить мне это различие. Большое спасибо

Приветствия

Francesco

Answer 1

Определения, которые вы предложили для Модели и Контроллера, отличаются от традиционного использования терминов в паттерне MVC - или, по крайней мере, паттерна, определенного здесь Мартином Фаулером .

Обычно это Модель, которая содержит большую часть бизнес-логики, и Контроллер отвечает за управление потоком информации между Представлением и Моделью.Цитата из статьи Фаулера:

Работа контроллера заключается в том, чтобы взять ввод пользователя и выяснить, что с ним делать.

Рассматривая ваш актуальный вопрос относительногде должен быть размещен репозиторий, он будет находиться внутри модели, но инкапсулирован как часть вашей инфраструктуры доступа к данным (это почти само определение того, что такое репозиторий).

Таким образом, модель становится составленнойиз двух ключевых частей - доменные объекты, которые имеют выразительную бизнес-логику, и сервисную инфраструктуру, которая делает доступ к уровню доступа к данным.(Другой распространенный подход состоит в том, чтобы Модель была составлена ​​из сервисов, которые на самом деле не обладают моделью расширенного домена, но все же она содержит всю бизнес-логику и доступ к данным.)размышляя или абстрагируясь от этого, сохраняйте его как можно более простым и вводите новый слой в свою архитектуру только тогда, когда вы уверены, что он принесет пользу.Например - сам EF может выполнять роль вашего репозитория в большинстве сценариев, поэтому его непосредственное использование без уровня репозитория может удалить ненужную абстракцию.