Где должны интерфейсы "физически жить"?

Question

Мне нравится идея разделить интерфейсы и реализацию. Но как отдельно? Определения интерфейса находятся в отдельной сборке .Net? У вас есть один проект, который определяет все интерфейсы для решения? Иначе есть ли проблемы с циклическими зависимостями интерфейсов?

Answer 1

Поместите ваши доменные объекты и интерфейсы в отдельную "доменную" сборку.
Эта сборка никогда не должна ссылаться ни на что, кроме основных сборок .net.

Таким образом, вы получаете чистое разделение от модели вашего домена / сервиса и вашей реализации.

Edit:
http://jeffreypalermo.com/blog/the-onion-architecture-part-1/

Answer 2

Я бы не стал помещать интерфейсы в отдельную сборку только ради этого. Однако, если интерфейсы участвуют в любой форме IPC или расширяемой архитектуры, то часто имеет смысл дать им собственную сборку.

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

Answer 3

Я предпочитаю хранить самые распространенные или простые реализации интерфейса в подпапке (и пространстве имен) после имени интерфейса.

\project\
\project\IAppender.cs
\project\Appender\
\project\Appender\FileAppender.cs
\project\Appender\ConsoleAppender.cs

Если я расширю этот класс за пределами проекта. В специальном проекте повторите папки / пространство имен аналогично.

\specialproject\
\specialproject\Appender\
\specialproject\Appender\MemoryAppender.cs

Answer 4

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

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