17

私のGUIクラスからロジックを除外するためのアドバイスはありますか? 私は優れたクラス設計を使用し、できるだけ分離したままにしようとしていますが、通常、私のフォーム クラスには、必要以上に多くの非 UI 要素が混在してしまい、メンテナンスが非常に面倒になる傾向があります。

(Visual Studio 2008 Professional、C#、Windows アプリ)。

どうもありがとう。

4

8 に答える 8

16

ロジックを別のアセンブリに入れます。そして、GUI パッケージを参照せずにそのアセンブリをビルドします (例: System.Drawing、System.Windows.Formsなど)。

于 2010-06-25T12:08:36.140 に答える
9

それは本当に練習と自己規律の問題です。つまり、私たちは皆それをやったのです。そして、私たちは皆、時々間違った状況でそれをやり続けています (マネージャー/顧客が何かを「今すぐ」対「正しい」と叫ぶなど)。

UI を駆動するコードを作成するときに私が行うことの 1 つは (Web 側の詳細ですが、同じことが当てはまります)、コードの各単位 (1 行、条件、ループなど) について、その部分がコードの数は、UI の存在に依存します。テキスト ボックスに書き込んでいる場合、それは UI に依存するため、そこに移動します。しかし、そのテキスト ボックスに入る結果を計算している場合、それはおそらくビジネス ロジックです。

もう 1 つのアプローチ (入力中に ChrisW がほのめかしたように) は、最初に非 UI クラス ライブラリでロジックを開発することです。UI ベースのライブラリに依存しない、できるだけ多くのロジックをそこに入れます (ただし、「ロジック」を定義するものについては判断してください)。次に、そのロジックを利用する UI を構築します。これら 2 つの部分の同時開発を可能にするさまざまなアプローチがあります。たとえば、インターフェイス クラスの背後にあるロジック アセンブリをスタブ化し、UI 部分をそれらのインターフェイスにコーディングするだけです (その後、依存性注入を使用してアセンブリ クラスをインターフェイスにプラグインします)。

于 2010-06-25T12:14:05.743 に答える
5

次のような設計パターンを調べる必要があります。

Web サイト (ASP.NET) でよく使用されるModel-View-Controller (MVC) WPF でよく使用される
Model-View-View Model (MVVM)

これらのいずれかを維持することで、アプリケーションのさまざまな部分を分離しておくことができます。

同様の仕事をする他のパターンがあります。

また、UI は XAML によって定義され、作業を行うコードは C# であるため、WPF を使用した開発が役立ちます。これにより、基本的な分離度が得られます。UI を操作するだけの C# コードを書いていることに気付いた場合は、一歩下がって「これを XAML で行うべきか」と考えることができます。明らかに、コード ビハインドでやらなければならないことがあるかもしれませんが、それは始まりです。

于 2010-06-25T12:09:43.297 に答える
5

3 層アーキテクチャは、探しているものです。

2 つの再利用可能なレイヤーを構築します。

  • データベースからの読み取り/書き込みに必要なコードのみを含むデータ アクセス レイヤー (DAL)
  • DAL を使用し、ビジネス ルール、検証を含み、使用する UI のファサードを提供するビジネス ロジック層 (BLL)

次に、UI プロジェクトで再利用可能なレイヤーを参照し、UI 固有のもののみを処理します。UI プロジェクトは BLL とのみ通信し、DAL に直接接続することはありません。

UI <---> BLL <---> DAL

複数のデータベース タイプをサポートする場合は、再利用可能なコンポーネントを使用する複数の UI レイヤーと、複数の交換可能な DAL を使用できます。

于 2010-06-25T12:14:03.013 に答える
2

フォームにデータバインドできるコントローラ クラスを作成する方法と、データバインドを実行する方法を学びます。WinForms では、これは主にコントローラー クラスの INotifyPropertyChanged および IDataErrorInfo インターフェイスと、フォーム クラスの BindingSource インスタンスの使用に帰着します。

次に、UI のすべてのデータとロジックを含むコントローラー クラスを作成すると、UI クラスは単純にそれにバインドされます。UI クラスは非常に薄くなり、UI ロジック (コントローラーに保持される) は非常にテストしやすくなります (単体テストは、UI クラスに対して実行する場合は注意が必要ですが、コントローラー クラスに対して実行する場合ははるかに簡単です)。

これは、すべての MVC/MVVM 設計の基礎です。

ハービー

于 2010-06-25T12:53:20.963 に答える
1

次のパターンを確認する必要があります。

MVC (Model-View-Controller) MVVM (Model-View-View-Model) - 主に WPF で使用され、豊富なデータ バインディングがサポートされています。MVP (Model-View-Presenter) - WinForms および Web アプリによく使用されます (ステートレス ビューのため)。

MVP を使用して Web ビューと WinForms ビューの両方を 1 つのプレゼンターで強化する方法の例を示すこのブログ投稿を確認してください: http://www.cerquit.com/blogs/post/MVP-Part-I-e28093-Building- it-from-Scratch.aspx

また、別のブログ投稿では、MVP パターンを使用してビジネス ロジックを単体テストする方法について説明しています: http://www.cerquit.com/blogs/post/Model-View-Presenter-Part-II---Unit-Testing. aspx

于 2010-06-25T12:27:45.917 に答える
1

通常、このような状況では。すべての面倒な作業を行うヘルパー メソッド クラスを作成します。

ロジックを分離しておくことについて。重要なコンポーネントを特定し、それらをそのヘルパー メソッド クラスにリファクタリングします。例えば; 選択されているかどうかに基づいてレコードを更新するために GridView を処理している場合。そうである場合は、ShipDate をフォームで更新します。行が選択されているかどうかを最初に把握します。次に Id フィールド、次に ShipDate を抽出し、すべての作業を行うヘルパー クラスのメソッドに Id と ShipDate を渡します。

ここでは単体テストが友達になります。基本的に、「ロジック」タイプのものを実行するコードがある場合。単体テストが必要です。GUIクラスにある場合。テストが難しい。ただし、一度リファクタリングすると。単体テストは自明である必要があります。

于 2010-06-25T12:16:53.990 に答える
1

一言でいうとリファクタリングです。

UI にコードを配置する理由はいくつかあります。

  1. フォーム上のコントロールとの相互作用
  2. これはビジネスロジックレイヤーに配置できますが、検証は通常UIにヘルパーメソッドを追加します（はるかに簡単です）

他のすべての「ビジネス ロジック」コードは、ビジネス ロジック クラスと呼ばれる別のクラスに入ります。すべてのデータベース対話コードは、データ アクセス クラスと呼ばれる別のクラスに入ります。

UI にコードを記述するときは、コードがフォーム上のコントロールと対話しているかどうかを自問してください。そうでない場合は、おそらく他の 2 つのクラスに属します。

「Refactoring: Improving the Design of Existing Code」などのリファクタリングに関する Martin Fowler の書籍を参照してください。もう 1 つの流行語は、関心の分離です。これらすべてを 1 つのクラスで実行できることはわかっていますが、上記のようにクラスに分割すると、コードがはるかに読みやすくなり、デバッグが容易になります。

于 2010-06-25T13:18:12.213 に答える