Консоль хранилища/услуг и согласованность данных

Question

В приложении, использующем шаблон репозиториев и сервисов, как убедиться, что сервисный уровень всегда вызывается, а не репозитории напрямую?

Пример:

class OrderRepository 
{ 
    void CreateOrder(Order o) 
    ... 
} 

class OrderService 
{ 
    void CreateOrder(Order o) 
    { 
     //make some business logic tests 
     ... 

     //call repository 
     _orderRepository.CreateOrder(o); 
    } 
} 

Я вижу две проблемы:

• Программист может вызвать хранилищу напрямую, потому что он не знает о существовании службы (иногда его не так просто как в этом примере (1 сервис = 1 репозиторий с одинаковыми именами методов). Некоторые приложения не очень хорошо документированы, или кто-то в спешке может забыть проверить, существует ли соответствующая служба (ошибка)).

• Совершенно иная: давным-давно кто-то создал несколько представлений + контроллеры, которые используют репозиторий заказов напрямую. В то время не было необходимости в проверке бизнес-логики или дополнительных операций, существует только репозиторий заказов (потому что там вообще не было необходимости). Если позже потребуется несколько дополнительных операций при создании заказа, будет создана служба. проблема в том, что все контроллеры, которые делают вызовы старых репозиториев, должны быть изменены. Не является ли принцип/идея репозитория (и разделение кода в слоях), чтобы сделать части независимыми друг от друга?

Answer 1

Вы можете структурировать свое решение, чтобы все хранилища и службы находились в их собственных проектах, например. Repositories и Services.

Единственный проект, который должен ссылаться на Repositories, будет Services. Таким образом, другие проекты не будут иметь доступа к репозиториям. Конечно, ничто не мешает разработчику включать проект репозиториев в проект контроллеров, но, надеюсь, на этом этапе они будут спрашивать себя, почему он не был включен в первую очередь.

Answer 2

Static analysis Инструменты могут помочь в этом отношении.

nDepend - это коммерческий инструмент, который может быть интегрирован в процесс сборки и ошибки при таком условии (любой класс без обслуживания, вызывающий класс репозитория напрямую).