Onion Framework: должны ли UI/контроллеры иметь прямой доступ к репозиторию

В структуре Onion внешний слой может получить доступ ко всем внутренним слоям. Если я пойду по этому пути, мой внешний уровень (который является уровнем пользовательского интерфейса/контроллером в MVC) также может напрямую обращаться к приложениям/бизнес-сервисам и репозиториям. Теперь мой контроллер может создать модель предметной области и сохранить ее в хранилище данных с помощью репозитория. И, таким образом, обойти проверку и другие бизнес-правила, написанные на бизнес-уровне. Я верю, я что-то упускаю. Пожалуйста помоги.

public SpeakerController(IConferenceRepository conferenceRepository,
                         IUserSession userSession, IClock clock)
    : base(userSession) {
    _conferenceRepository = conferenceRepository;
    _clock = clock;
    _userSession = userSession; }

с http://jeffreypalermo.com/blog/the-onion-architecture-part-2/


onion-architecture
person Pragmatic    schedule 09.04.2016    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Я говорю «нет», хотя сам Палермо указал обратное в разговорах в Твиттере. Я говорю, что каждому уровню разрешено общаться со следующим внутренним уровнем и не обходить его. Исключение, которое я делаю из этого правила, заключается в том, что рассматриваемая функциональность в основном представляет собой просто CRUD для справочных данных. Не вижу смысла вводить дополнительную сложность для такого рода данных.

Другая альтернатива состоит в том, чтобы ваша реализация репозитория принудительно проверяла бизнес-правила. Поскольку реализация находится на самом внешнем слое луковицы, это должно быть довольно легко сделать.

Я нашел гексагональную архитектуру Алистера Кокберна яркой и простой, чем луковая архитектура. В основном есть «внутри моего приложения» и «вне моего приложения». В любое время, когда вам нужно пересечь эту границу, вам понадобится адаптер для защиты вашего приложения от деталей реализации.

person Chris McKenzie    schedule 10.04.2016
comment
Если я вас правильно понял, вы хотите сказать, что нет необходимости иметь методы-оболочки/сквозные методы в бизнес-классе для работы CRUD. Можно использовать методы репозитория в пользовательском интерфейсе. Для меня «Проверка бизнес-правил» в репозитории не очень хорошая идея. Это сведет на нет цель наличия бизнес-уровня. - person Pragmatic; 11.04.2016
comment
Есть две отдельные проблемы: справочные данные и проверка. Я разберу их в отдельных комментариях. Re: Справочные данные Допустим, у меня есть таблица с именем StateOrProvince. Возможно, у меня нет бизнес-правил для этих данных, кроме обязательных полей и уникальности. Эти правила могут применяться базой данных. Для этих данных нет никаких операций, кроме CRUD. Разработка модели предметной области для такого рода данных может оказаться излишним. В этом случае я обычно просто привязываю свое представление непосредственно к моему ORM. - person Chris McKenzie; 11.04.2016
comment
Re: Проверка Вы пишете свою логику проверки на уровне домена. У вас должны быть абстракции, которые представляют ваш уровень сохраняемости, определенный на уровне вашего домена, который могут использовать ваши объекты домена. Нет никаких причин, по которым вы не можете invoke логику проверки вашего объекта предметной области в реализации вашего уровня постоянства. На самом деле, если вы внимательно посмотрите на диаграмму OA, реализация постоянства находится на одной из самых внешних ступеней диаграммы. Это означает, что вы получаете полный контекст домена на уровне сохраняемости. Вы могли бы также использовать его. - person Chris McKenzie; 11.04.2016
comment
И последнее: я обнаружил, что видео Pluralsight по основам проектирования, управляемого доменом, очень полезно для решения подобных вопросов. app.pluralsight.com/library/courses/ - person Chris McKenzie; 11.04.2016