Где разместить интерфейсы в проекте Visual Studio для многоуровневого решения с использованием зависимостей Injection

Question

Я разрабатываю многоуровневое решение с использованием WinForms, Visual Studio 2015, Entity Framework 6 и инъекции зависимостей без стороннего контейнера. В настоящее время у меня есть структура, которая позволяет UI, BLL и DAL не связываться друг с другом, если я размещаю интерфейсы, необходимые для выполнения работы в совместном проекте. См вариант А на диаграмме ниже:

Услуги в УСК тонкие, как они в основном называют полной реализации в DAL (т.е. BLL.GetDepts называет DAL.GetDepts Первоначально я интерфейсы определены в. BLL, как показано в опции B. Вариант B также требовал, чтобы DAL имел ссылку BLL для понимания интерфейсов. Кроме того, пользовательский интерфейс также должен был иметь ссылку на BLL. Однако BLL не нуждался в ссылке UI или DAL, поэтому он не зависел ни от одного из них. Хотя опция B не имела всех зависимых от уровня уровней, я начинаю задаваться вопросом, действительно ли это была плохая идея. С вариантом B я все еще могу заменить интерфейс или DAL без влияя на BLL, пока сменные слои чтят интерфейс требования. Я использую опции A или B, любые изменения в пользовательском интерфейсе или DAL по-прежнему требуют тестирования с помощью BLL. Поэтому я начинаю думать, что стремление к тому, чтобы все слои, независимые друг от друга, не были действительно необходимы или прагматичны.

Причина, по которой я начал подвергать сомнению мой переход к опции A, заключается в том, что, увеличивая количество классов с интерфейсами для расширения функциональности BLL, я также увеличиваю количество записей интерфейса в общей области. Визуально глядя на мой проект Visual Studio, я думаю, что любой слой, который нуждается в чем-то из BLL, должен найти интерфейс, описывающий потребности BLL в слое BLL. Это то, что сделал вариант B. Теперь, с вариантом A, я говорю, что любой слой, желающий реализовать что-то, BLL должен искать в разделе разделов совместного проекта BLL. Все это работает пока, но я не уверен, что если преследовать этот путь, это вызовет некоторые проблемы.

Итак, вопрос: «Есть ли проблема с преследующей опцией А, как описано выше?».

Answer 1

Если интерфейсы должны идти, это зависит от вашей мотивации для введения интерфейсов в первую очередь.

Если мотивация заключается в сборе преимуществ слабосвязанного кода, вам лучше всего придерживаться SOLID principles. В частности, согласно Dependency Inversion Principle, «клиенты [...] владеют абстрактными интерфейсами« (APPP, глава 11).

Это означает, что интерфейс должен быть определен в той же библиотеке (проект сборки/Visual Studio) в качестве кода, который использует интерфейс.

Таким образом, вы можете иметь интерфейсы, определенные в разных библиотеках, в зависимости от использования. Вам не нужно размещать все интерфейсы в одной библиотеке.

Answer 2

Я бы выбрал вариант B, поскольку он выглядит достойной реализацией шаблона MVC. Вы можете прочитать несколько статей, которые я написал о шаблоне MVC, по адресу here. Преимущество MVC - читаемость. Если кто-то, кроме вас, может поддерживать код, тогда MVC будет знаком или, по крайней мере, легко найти их.