N アプリケーションがあります。各アプリケーションには、少なくとも次のアセンブリが含まれます。
一部のシナリオでは、アプリケーション 1 はアプリケーション 2 の BusinessLogic 層からメソッドを呼び出す必要があり、アプリケーション 2 はアプリケーション 1 の BusinessLogic 層からメソッドを呼び出す必要があります。この条件により、アプリケーション 1 とアプリケーション 2 の BusinessLogic 層の間でアセンブリの循環依存が発生します。ビルド プロセスで問題が発生する可能性があります。今、私の質問は、「それは建築設計の間違いですか? もしそうなら、それを解決するにはどうすればよいですか?」
これは単に、システムを再設計する必要があるかもしれないことを示しています。あなたは責任を混合しており、後であらゆる種類の問題を引き起こすため、私は常に循環依存を避けます。
コンポーネントと関係を描画し、それぞれを指定されたレイヤーに配置します。Onion アーキテクチャは、システムを設計し、すべての資産、責任、およびそれらの間の関係を特定するための優れたアプローチです。こことここを読んでください。
あなたの場合、両方のクライアントで使用され、共有されたものを含むコンポーネントが必要です。しかし、あなたが私たちに提供した情報に基づいて、その方法を推測することは不可能です.
App2 が App1 のビジネス ロジック層を呼び出さなければならない場合、それは循環依存関係に到達するかなり前に危険信号である必要があります (実際には app1 と app2 のビジネス ロジックになっているため)。
これに対する一般的な解決策は、OOP 言語で基本クラスを抽象化するときに行うこととまったく同じです。共有されている部分を見つけて、この場合は単一の「アプリ」の下から移動し、簡単に共有できるライブラリに配置します。
あなたの場合、共有されているビジネス ロジック操作を取得し、適切に名前が付けられた独自のアセンブリに配置して、両方が問題なく使用できるようにします。
2 つのアセンブリを相互に依存させることができます (たとえばSystem.dll、System.Configuration.dll.NET Fx では相互に依存します)。しかし、経験したことがあるかもしれませんが、それを回避するには、Visual Studio の強制に対して懸命に取り組む必要があります。
アセンブリ間の明らかに非循環的な依存関係は、達成しなければならない目標です。そうしないと、アセンブリを個別に開発、コンパイル、およびテストすることはできません。
一般的なパラダイムは、それをBusinessLogic使用することDataAccessであり、その反対ではありません。DataAccessコールバックできるようにしたい場合はBusinessLogic、通常の方法で次のようにします。
DataAccessアセンブリでコールバック インターフェイスを定義するBusinessLogicアセンブリに実装します (したがって、BusinessLogicアセンブリはアセンブリを参照しますDataAccessが、逆は参照しません)。BusinessLogicに渡し、コールバック インターフェイスをパラメーターとして受け取る でDataAccess定義されたメソッドを介して渡します。DataAccessDataAccessコールバックできるようにすることBusinessLogicは禁止されていることではありませんが、なぜそれを行う必要があるのかを自問する必要があり、これらのコールバックの数を厳密に最小限に制限するようにしてください。
個人的には、アセンブリ内の名前空間をコンポーネントと見なし、非循環的な名前空間の依存関係を持ち、アセンブリ アーティファクトを使用してコンポーネントを定義することを避けることで、さらに進んでいきたいと考えています。これは、私が作成した 2 つのホワイト ブックで公開されています。