私は現在、大規模なアプリケーションの基盤を設計しています。データレイヤーにEF、ビジネスレイヤーにプレーンジェーンc＃クラス、UIレイヤーにMVC/WCFを使用する従来の3層システムを使用します。アプリケーションのプロトタイプを作成して、これが機能することを認識しましたが、ビジネス要件が複雑なため、一部のビジネスコンポーネントが相互に作用するのが一般的です。
次の2つのビジネスコンポーネントについて考えてみます。
- RetailManager-システム内の小売に関連するすべてを処理します
- CartManager-ショッピングカートのエクスペリエンスに関連するすべてを扱います
この2つは、たとえば、アイテムが購入されたときのチェックアウトプロセス中に相互作用します。購入したアイテムの在庫を減らす必要があります。
これまでの私の思考プロセスは次のとおりです。
ビジネスコンポーネントが相互に参照し、循環参照が発生しないようにします（CartManagerはRetailManagerを参照しますが、その逆はありません）。「Checkout」はCartManagerクラスのメソッドであり、RetailManagerのメソッドを呼び出して在庫を調整します。これは機能しますが、どれだけ拡張できるか、また時間の経過とともに維持費がいくらになるかはわかりません。それは私にとって100％「正しい」とは感じません。
ビジネスコンポーネントとUI層の間にファサードを作成します。この例では、ファサードにはチェックアウト方法と両方のマネージャーへの参照があります。私はこのアプローチが最初のアプローチよりも好きですが、すべてのビジネスオブジェクトにFacadeが必要なわけではないことを知っています。また、空のパススルーメソッドを作成するためだけに大量のFacadeクラスを作成したくありません。
私は2に傾いていますが、必要な場合にのみファサードクラスを作成することに注意してください。UI層は、ファサードとビジネスレイヤーの両方のコンポーネントにアクセスでき、どちらをいつ使用するかを知る必要があります（このソリューションについて私が気に入らない部分は1つだけです）。
私はたくさんの研究をしましたが、完全に正しいと感じる解決策を思い付くことができませんでした。
このようにファサードパターンを使用することについての考え、または問題を解決するための他のアイデアは大歓迎です。
前もって感謝します。