よくある落とし穴に陥ったように見えますが、心配しないでください、それらは修正できます:)
最初に、アプリケーションを少し異なって見て、チャンクに分割する必要があります。チャンクを2方向に分割できます。最初に、UIコードから制御ロジック（ビジネスルール、データアクセスコード、ユーザー権利コードなど）を分離できます。次に、UIコードをチャンクに分割できます。
したがって、UIをチャンクに分割して、後半を最初に行います。これを行う最も簡単な方法は、ユーザーコントロールを使用してUIを構成する単一のホストフォームを作成することです。各ユーザーコントロールは、フォームの領域を担当します。そのため、アプリケーションにユーザーのリストがあり、ユーザーをクリックすると、その下のテキストボックスに詳細が入力されているとします。ユーザーリストの表示を管理する1人のユーザーコントロールと、ユーザーの詳細の表示を管理する別のユーザーコントロールを作成できます。
ここでの本当のトリックは、コントロール間の通信をどのように管理するかです。フォーム上の30のユーザーコントロールがすべて相互に参照をランダムに保持し、それらのメソッドを呼び出すことは望ましくありません。
したがって、各コントロールのインターフェイスを作成します。インターフェイスには、コントロールが受け入れる操作と発生するイベントが含まれます。このアプリについて考えるとき、リストボックスリストの選択が変わってもかまいません。新しいユーザーが変わったという事実に興味があります。
したがって、サンプルアプリを使用すると、ユーザーのリストボックスをホストするコントロールの最初のインターフェイスには、ユーザーオブジェクトを渡すUserChangedというイベントが含まれます。
リストボックスに飽きて3Dズームマジックアイコントロールが必要な場合は、同じインターフェイスにコーディングしてプラグインするだけなので、これは素晴らしいことです。
では、パート2、UIロジックをドメインロジックから分離します。さて、これは使い古されたパスなので、ここでMVPパターンを確認することをお勧めします。本当に簡単です。
各コントロールは、現在ビュー（MVPのV）と呼ばれ、上記で必要なもののほとんどを既にカバーしています。この場合、コントロールとそのインターフェイス。
追加するのは、モデルとプレゼンターだけです。
モデルには、アプリケーションの状態を管理するロジックが含まれています。知っていることは、ユーザーを取得するためにデータベースに行き、ユーザーを追加するときにデータベースに書き込むなどです。アイデアは、他のすべてから完全に隔離して、これらすべてをテストできることです。
プレゼンターの説明はもう少し複雑です。これは、モデルとビューの間に位置するクラスです。ビューによって作成され、ビューは前述のインターフェイスを使用してプレゼンターに渡されます。
プレゼンターは独自のインターフェイスを持つ必要はありませんが、とにかくインターフェイスを作成するのが好きです。プレゼンターに明示的にさせたいことを行います。
そのため、プレゼンターは、ユーザーのリストを取得するためにビューが使用するListOfAllUsersのようなメソッドを公開します。あるいは、AddUserメソッドをビューに配置して、プレゼンターから呼び出すこともできます。私は後者を好む。そうすることで、プレゼンターはユーザーを必要に応じてリストボックスに追加できます。
プレゼンターにはCanEditUserなどのプロパティもあります。これは、選択したユーザーが編集できる場合にtrueを返します。ビューは、知る必要があるたびにクエリを実行します。編集可能なものは黒で、読み取り可能なものは灰色で読みたい場合があります。技術的には、UIがフォーカスされているため、Viewの決定です。ユーザーが最初に編集可能かどうかはプレゼンター用です。プレゼンターは、モデルと話すため知っています。
要約すると、MVPを使用します。Microsoftは、私が説明した方法でMVPを使用するSCSF（スマートクライアントソフトウェアファクトリー）と呼ばれるものを提供しています。他にも多くのことが行われます。それは非常に複雑であり、彼らがすべてを行う方法が好きではありませんが、それは役立つかもしれません。