인터페이스는 어디에 "물리적으로 존재"해야 합니까?

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 dll 중 하나 이상을 참조할 수 있다는 아이디어입니다.

소규모 애플리케이션에는 이러한 종류의 분리가 필요하지 않습니다.그러나 인터페이스를 어디에 보관하든 기본 클래스와 동일한 네임스페이스에 보관합니다.