モジュールコアプログラムでは、モジュールはどのように相互作用する必要がありますか？
短い背景：1つのコア（シングルトン）と複数のMEFパーツを持つプログラムの開発にMEF/C＃を使用しています（モジュールと呼びます。各モジュールは、MEFエクスポートを含む1つのクラスを持つ個別のアセンブリです）。コアは、必要な/利用可能なすべてのパーツをインポートし、それらを初期化します（構成ファイルを読み取らせる、コンストラクターで発生する、通常どおりのビジネス）
今、私の問題は、相互に対話するためのモジュールが必要なことです（たとえば、グラフィカルユーザーインターフェイスであるモジュールAは、データベースからデータを取得する必要があり、データベースモジュール（モジュールB ））
どうすればいいですか？確かに、これらのパーツ/モジュールをコアで公開し、モジュールにコアへの参照を追加してそれで済ませることはできますが、どういうわけか、それは醜い/悪いと感じます。 （主に、このような実装に関するセキュリティ上の懸念があるため、 this のようなものを使用しない限り、誰でもその関数を呼び出すことができますが、それでも正しく感じられません）。
もう1つのアプローチは、これらの関数をすべてコアに配置し、モジュールの対応する関数を呼び出すだけです。コアに多くのものを追加する必要があり、場合によっては、特定のモジュールを必要としない/持っていないために潜在的な顧客が使用することのないものになるため、それも気分が悪くなります。
誰かがこれを行うためのより良い方法を知っていますか？たぶん私の考えの列はどこかで完全に間違っていましたか？
グラフィカルユーザーインターフェイスであるモジュールAは、データベースからデータを取得する必要があります
これは、モジュールの設計が正しくないことを示しています。
コードをモジュールに分割するポイントは、機能の区分化です。つまり、各モジュールには特定の機能領域があり、それだけを行う必要があります。
GUIモジュールはonlyユーザーインターフェイスを処理する必要があります。
データベースモジュールは、onlyデータベースと対話する必要があります。
一方から他方への情報の受け渡しは、より高いレベルで行われる必要があります。これはコアモジュールかもしれません。または、何をしようとしているのかによっては、別のレイヤーを追加することが理にかなっている場合があります。
例：
ユーザーが「データを取得」ボタンをクリックすると、GUIモジュールのイベントハンドラーがデータを要求するコアメソッドを呼び出します。次に、このコアメソッドはデータベースモジュールを呼び出してデータを取得します。
なぜコアがあるのですか？
すべてがモジュールで構成されている場合、コアは何をするのですか？モジュールが（インターフェースを介して）相互に参照し、MEFを使用して具体的な実装をスピンアップしないのはなぜですか？
次に、UIの一部のコンポーネントが一部のデータリポジトリにアクセスする必要がある場合、モジュールの残りの部分と提供されている実装を無視して、Importを介してそれを要求します。モジュールのコンポーネントは、相互に（および/またはモックされたバリアント）動作できます。スリムなインターフェイスを使用するように注意してください。責任に夢中にならないようにしてください。
責任について話しましょう。
GUI
- ユーザーからの入力を処理する
- リクエストデータ
- 要求されたデータを受信する
- データの見栄え/表示
DBアクセスレイヤー
- クエリデータベース
- クエリされたデータを処理する
- 処理されたデータを返す
追加の責任
- データリクエストを調べて、悪意のないものではないことを確認します。セキュリティの別名スクラブリクエスト。
あなたの場合、誰が（どの領域）追加の責任を処理するかについて、2つの基本的なオプションがあります。
GUIはスクラブの責任を処理します。これにより、GUIコードが混乱するリスクを冒して、DBレイヤーをクリーンに保つことができます。さらに、適切でない可能性のあるGUIコード内に信頼を置きます。
DBAレイヤーはスクラブの責任を処理します。これにより、信頼の懸念は解決されますが、DBAレイヤーコードが混乱する可能性があります。
別の方法として、受信データ要求をスクラブする責任を持つ追加のレイヤーを作成することを検討してください。セキュリティレビューを容易にするために、クエリの対象となる可能性がある主要な要素（ユーザーID、注文番号、日付範囲、ステータスコードなど）を保持する特定のdata requestオブジェクトを作成することをお勧めします。
このレベルの抽象化には、いくつかの顕著な利点があります。
- GUIは、DBAレイヤーで簡単に使用できるようにフォーマットすることを心配しなくなりました。
- スクラビングレイヤーには明確な目的があり、セキュリティ/検証コードは同じエリア内にあります。
- DBAレイヤーは、スクラビングレイヤーにリンクして、要求に応じて操作する前に
data requestでセキュリティチェックをトリガーできます。 - 契約が結ばれているので、GUIとDBAレイヤーの両方に対する将来の変更が容易になります。データフローは次のようになります：
GUI <=> AR <=> DBA。将来の変更は、契約全体ではなく、契約の半分に関してのみ検証する必要があります。
幸いなことに、かなりの数の人々が以前にこの課題に取り組んだことがあります。 MVVMパターン ref 1 、 ref 2 、 ref は、抽象化の概要とアイデアについて、読むことを選択しなくても読む価値がありますパターン全体を利用します。あなたがやりたいことよりも実装するのが重いかもしれません。 MEFはこのパターン、AFAIKとうまくメッシュします。 プロのヒント：その最後の参照はプリズムへのMS開発者ガイドであり、あなたが作業している領域の情報の確かな宝庫です。