5

インターフェイスと実装を分離するというアイデアが気に入っています。しかし、どのように分離しますか？インターフェイス定義は別の .Net アセンブリにありますか? ソリューションのすべてのインターフェイスを定義する単一のプロジェクトはありますか? そうでなければ、インターフェースの循環依存に問題がありますか?

4

4 に答える 4

7

ドメイン オブジェクトとインターフェイスを別の「ドメイン」アセンブリに配置します。
このアセンブリは、コア .net アセンブリ以外は参照しないでください。

このようにして、ドメイン/サービス モデルと実装を明確に分離できます。

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

于 2008-09-11T19:22:14.997 に答える
3

そのためだけに、インターフェイスを別のアセンブリに入れることはしません。ただし、インターフェイスが何らかの形式の IPC または拡張性アーキテクチャに参加する場合は、多くの場合、インターフェイスに独自のアセンブリを与えることが理にかなっています。

相互に参照する必要があるプロジェクトがある場合は、インターフェイス用に別のアセンブリが必要になりますが、アーキテクチャを注意深く調べて、循環依存関係を解決する別の方法があるかどうかも確認する必要があります。

于 2008-09-11T19:23:30.733 に答える
1

インターフェイスの最も一般的または単純な実装を、インターフェイスの名前に続くサブフォルダー (および名前空間) に保持することを好みます。

\事業\
\project\IAppender.cs
\プロジェクト\アペンダー\
\project\Appender\FileAppender.cs
\project\Appender\ConsoleAppender.cs

このクラスをプロジェクトの外に拡張すると。特別なプロジェクトでは、フォルダー/名前空間を同様に繰り返します。

\特別企画\
\specialproject\Appender\
\specialproject\Appender\MemoryAppender.cs
于 2008-09-11T19:27:31.707 に答える
0

私が現在取り組んでいるプロジェクトでは、インターフェイスと関連する基本クラスは、関数間で論理的に分割されたアセンブリになります。これらのプロバイダーとクラスの実装は、コア アセンブリ内に入ります。私たちの API を使用する人々が、複数または 1 つの API dll を明確かつ論理的な方法で参照できるようにするという考えです。

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

于 2008-09-11T19:38:54.143 に答える