インターフェイスはどこに「物理的に存在」すべきでしょうか?

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 を使用するユーザーが、明確かつ論理的な方法で複数または 1 つの API DLL を参照できるようにすることです。

小規模なアプリケーションでは、この種の分離は必要ありません。ただし、インターフェイスをどこに保存しても、基本クラスと同じ名前空間にインターフェイスを保存します。