У меня должен быть отдельный блок для интерфейсов?

Обычная обычная ожидаемая ^? практика состоит в том, чтобы поместить их в их собственную сборку, потому что тогда данный проект, использующий эти интерфейсы, не требует жесткого ссылка на реализацию этих интерфейсов. Теоретически это означает, что вы можете поменять реализацию практически без боли.

Тем не менее, я не могу вспомнить, когда делал это в последний раз, но, по мнению @David_001, это не обязательно «обычно». Мы стремимся согласовывать наши интерфейсы с реализацией, и чаще всего мы используем интерфейсы для тестирования.

Я думаю, что есть разные позиции в зависимости от того, что вы производите. Я обычно создаю LOB-приложения, которые должны внутренне взаимодействовать с другими приложениями и командами, поэтому есть некоторые заинтересованные стороны в общедоступном API любого данного приложения. Однако это не так сложно, как создание библиотеки или фреймворка для многих неизвестных клиентов, где общедоступный API внезапно становится более важным.

В сценарии развертывания, если вы изменили реализацию, вы могли бы теоретически просто развернуть эту единственную DLL - таким образом, оставив, скажем, UI и интерфейсные DLL в покое. Если вы скомпилировали свои интерфейсы и реализацию вместе, вам может потребоваться повторно развернуть UI DLL ...

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

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

Шаблон, которому я следую для того, что я называю разделяемыми типами (и я тоже использую DI), состоит в том, чтобы иметь отдельную сборку, которая содержит следующее для концепций уровня приложения (а не общие концепции, которые идут в общие сборки):

1. Разделяемые интерфейсы.
2. DTO.
3. Исключения.

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

Затем у меня есть дизайн типа времени выполнения, в котором я устанавливаю свой контейнер DI при запуске приложения или при запуске набора модульных тестов. Таким образом, существует четкое разделение между реализациями и тем, как я могу варьировать их с помощью DI. Мои клиентские модули никогда не имеют прямых ссылок на реальные библиотеки ядра, только на библиотеку "SharedTypes".

Ключевым для моего дизайна является наличие общей концепции времени выполнения для клиентов (будь то приложение WPF или NUnit), которая устанавливает необходимые зависимости, т.е. конкретные реализации или своего рода mocks\stubs.

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

Обновление

Для пояснения на примере того, как зависимости оказываются в целевом приложении.

В моей ситуации у меня есть клиентское приложение WPF. Я использую Prism и Unity (для DI), где, что важно, Prism используется для композиции приложения.

В Prism сборка вашего приложения - это просто оболочка, фактическая реализация функциональности находится в сборках "Модулей" (вы можете иметь отдельную сборку для каждого концептуального Модуля, но это не требование, у меня одна сборка Модулей ATM). В обязанности оболочки входит загрузка Модулей - композиция этих Модулей и есть приложение. Модули используют сборку SharedTypes, но оболочка ссылается на конкретные сборки. Конструкция типов времени выполнения, которую я обсуждал, отвечает за инициализацию зависимостей, и это делается в оболочке.

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

Эскиз зависимости:

Shell.dll <-- Application
  --ModuleA.dll
  --ModuleB.dll
  --SharedTypes.dll
  --Core.dll
  --Common.dll + Unity.dll <-- RuntimeDI

ModuleA.dll
  --SharedTypes.dll
  --Common.dll + Unity.dll <-- RuntimeDI

ModuleB.dll
  --SharedTypes.dll
  --Common.dll + Unity.dll <-- RuntimeDI

SharedTypes.dll
  --...