この問題にまつわる言葉をさらに調べたい場合は、MVP と MVC を調べてください。(これらは Model View Controller と Model View Presenter の略です)。これを言って私を撃つ人もいますが、コンセプトは非常に似ています.
MVP と MVC の目的は、アプリケーションの外観について考えなくてもアプリケーション ロジックを設計できるようにすることです。また、実際の GUI を実装せずにユーザー インタラクションを定義することもできます。基本的に、モデルはアプリケーション ロジック、データ、データベースとの通信などを実際に行うクラスです。プレゼンターまたはコントローラーは、モデルと対話するものであり、ユーザー インターフェイスを制御し、インターフェイスでのユーザー操作に反応するものです。最後に、ビューは winforms デザインまたは Web ページです。
これについてはウェブ上でたくさんの資料を見つけることができると確信していますが、この問題に関する具体的な助けを提供することは、あなたの読書を知らせ、説明するのに役立つはずです.
最初に、データを表すオブジェクトの作成を開始する必要があります。したがって、casenote データを含む CaseNote オブジェクトが作成されます。ケース ノート データベースなど、ある種のケース ノート データ コンテナがあります。これらの論理演算とプロパティを、実際のアイテムの場合と同様に定義できます。
次に、GUI からサポートする操作を定義するプレゼンターまたはコントローラーの定義に進みます。同時に、プレゼンター/コントローラーに対して GUI で実行できる操作を定義するインターフェイスを定義する必要があります。たとえば、プレゼンターは、文字列パラメーターを取る SearchForCaseNote というメソッドを公開する場合があります。ビュー インターフェイスは、DisplayCaseNote というメソッドを公開します。ユーザーが検索ボタンをクリックすると、ビューはコマンドを介してプレゼンターに渡され、プレゼンターはモデルを呼び出してデータを取得します。プレゼンターはこの時点でデータをフォーマットできます。つまり、DateTime オブジェクトを文字列に変換し、DisplayCaseNote と呼ばれるインターフェース定義メソッドを介してデータをビューに戻します。
View インターフェイスを使用する必要はありません。ビューを直接呼び出すこともできますが、インターフェイスがあるということは、さまざまなビューの実装を持つことができるということです。
最後に 1 つ言及する必要があるのは、アプリケーションのこれらのさまざまな部分を作成する場所です。私の見解は、プレゼンター/コントローラーからすべてのものが出てくるはずです。したがって、アプリケーションが起動すると、プレゼンター/コントローラー オブジェクトが作成され、ビューが変数として渡されてビューが作成および表示されます。次に、プレゼンター/コントローラーは、ディスクからロードして初期モデルを作成するか、理想的には unity のような依存性注入コンテナーを介してモデルを検出できます。実際、ユニティを使用してビューの実装を発見することは、ビューとプレゼンター/コントローラーを真に分離できるため、おそらくより良いアイデアです。別のビューに移動するとき (つまり、別のウィンドウを開くとき)、プレゼンター/コントローラーは、ボタンがクリックされたときにビューが呼び出す DisplayDetailPage などのメソッドを公開する必要があります。
お役に立てれば。