どの実装を使用するかを決定する時、各解決策の意味を理解することが重要です。たとえば、Visual Studio を使用してフォームにさまざまなデータベース エンティティをドラッグ アンド ドロップすることにより全体的なデータ モデルを簡単に作成することができます。これで DataTables とそれらの関係で DataSets が生成されます。これは WinGrid™ にバインドすることを可能にする IList、IBindingList、IEditableObject インタフェースのすべてをユーザーに提供します。WinGrid で操作する場合、WinGrid を編集、削除、および更新するアクションはデータ モデルを直接変更します。必要なのは、各 DataTable に適切な Data Adapters を使用してデータベースに変更を解決することだけです。
もうひとつのアプローチは、要件で定義したとおりにそれぞれが実際のエンティティを表すことができるように固有のカスタム ビジネス オブジェクトを作成することです。ユーザーの分析で識別された各ビジネス エンティティに対して単にクラスを作成することを選択できます。これで、複数のインスタンスで作業する必要がある時には必ずビジネス オブジェクトで標準配列を作成できます。オブジェクトの設計に基づき、これは軽量なアプローチとなりますが、IBindingList インタフェースによって提供される特徴や機能を持ちません。たとえば、標準配列を持っているので、リストから項目を追加または削除できません。このような配列に WinGrid をバインドする場合、WinGrid のインタフェースから行を削除することは許可されません。許可するとグリッドは例外を発生し、基本リストが追加または削除をサポートしないことを通知します。WinGrid を使用して行を削除または追加する時には必ず、リストにオブジェクトを挿入または削除するために実際に基本の IBindingList Add または Delete メソッドを呼び出すので、これは意味があります。この場合、WinGrid で適切なイベントを処理する必要があるので、追加または削除される行を識別でき、リストに直接削除および追加を実行することが必要になります。これは、Add を含むか特定のメンバを削除した新しい Array を作成することを要求し、新しい Array にグリッドをバインドする必要があります。このように、これはより多くの作業を必要とし、コードの管理が面倒になります。
あるいは、カスタム ビジネス オブジェクトのためのコレクション クラスを作成することによってもカスタム ビジネス オブジェクトについて詳細説明できます。Customer オブジェクトを持つ場合、CustomerCollection オブジェクトも作成することができます。すべてのイベントがコレクションによって適切に発生するように Collection オブジェクトは IList および IBindingList を実装するので、WinGrid によって操作を実行する場合は常に、コレクションがそれに従って更新されます。Visual Studio 2002 および 2003 では、これによってすべてのイベントが適切に発生することを保証するために何らかの作業とテストが必要となりますが、特徴および機能はその価値があります。.NET Framework 2.0 を使用している場合、そのような実装を作成することは、タイプ Customer の一般的な BindingList を継承していれば非常に簡単です。このアプローチをとる場合、データ バインディングに関連するすべての基本設備が含まれ、実行しなければならないのは、自分の要件を表すためのクラスを作成することだけで、データ バインディングやリスト通知ロジックについて心配する必要はありません。
もうひとつの留意すべき事は入れ子になったコレクションです。ADO.NET DataSets および DataTables、そして WinDataSource を使用する場合、DataRelation オブジェクトを使用して階層的なデータ モデルを簡単に表すことができます。複数のテーブルがある場合、ひとつのテーブルから別のテーブルに関係を作ることができます。最終結果は、親テーブルの各レコードが特定の関係から返される子レコードを含むことができるようになります。つまり、ひとつの顧客レコードは注文の多くの子レコードを持つことができます。これは、タイプ Collection となるカスタム オブジェクトそれぞれにパブリック プロパティを持たせることにより、固有のカスタム オブジェクトから達成することもできます。カスタム オブジェクト ルートを使用してデータ モデルを作成する場合、特定のタイプ（たとえば、CustomerCollection、OrderCollection、OrderDetailCollection）を受け付けるように設計される複数のコレクション オブジェクトを作成し、次にそれが意味を持つ場合にパブリック コレクション プロパティを作成します。Customer クラスはタイプ OrderCollection のパブリック プロパティを含み、Order クラスはタイプ OrderDetailCollection のパブリック プロパティを含みます。この方法でクラスを正しく作成することで、グリッドをデータ モデルにバインドし、入れ子になった階層的な形式でデータを視覚化することができます。WinGrid の良い点は、すべての階層を同時に表示することです。インボックス DataGrid が表示するのは常にひとつの個別コレクションだけです。
いずれかの方式の利点および欠点を理解すれば、時間制約、設計的な基準、および技術の熟練度に基づきデータ モデルを作成する時に最適なルートを自分で決定するのはユーザー次第です。いずれを選択しても、WinGrid はこれらの方式いずれでも機能します。