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

Question

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

Answer 1

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

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

Редактировать:
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 в ясной и логичной форме.

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