コンテキスト: 多数の列が含まれる複雑なデータベース モデルがある .NET プラットフォームでスマート クライアント アプリケーションを構築する。自然なアプリケーション スタイルは、典型的なデータ ドリブン CRUD です。場合によってはかなりの量のサーバー側のロジックと、やや複雑な検証もあります。クライアントとサーバーを完全に制御できるため、相互運用性の必要性は最小限です。
この質問には多くの詳細がありますが、それは申し訳ありませんが、回答に適切なコンテキストを設定したいからです。
いくつかの前提条件
- Microsoft の世界では珍しくありませんが、以前のほとんどのアプリケーションは DataSets を使用して作成されているため、関係する開発者にとって最もよく知られているテクノロジです。しかし、開発者が OO の考え方にも精通しているとしましょう。
- クライアントとサーバーの両方で検証を実行する必要があります。
- ほとんどのデータを表形式で表示していません。
- これはイントラネット アプリケーションではないため、帯域幅についてあまり多くを想定することはできません
最大の問題: データセットですか、それともオブジェクトですか?
データセットを使用する場合、いくつかの長所と短所があります。長所
としては、データベースからデータを取得する、ネットワークを介してデータを取得する、ネットワークを介して変更されたデータを返すという点で、Microsoft のサポートが少し得られます。小さいチャンク – 変更の送信のみを指定できるため。かなりの量のデータが含まれる可能性があるため、送信するデータが少ないのは良いことです。
- マイナス面は次のとおりです。検証、ビジネス ロジックなどに関して、手続き型のコードが得られ、オブジェクト指向コードの利点が得られません。動作とデータが一緒になって、より自然な作業スタイルと思考スタイルが得られます。あなたがしていること、そしておそらく検証ロジックとの密接な関係。また、データセットをグリッドに配置する利点から目を背けることもできます。これは一般的なユース ケースではないためです。
オブジェクトを選択する場合も同じドリルですが、より多くのオプションが含まれます
。 良い点
: 動作とデータが一緒に。検証ロジックを近づけます。オブジェクト間の関係が見やすく、理解しやすくなります。より読みやすいコード。単体テストが容易になります。しかし、かなりの数の選択肢と実行する必要がある作業もあります。
OR/マッピング
- リレーショナル モデルからオブジェクトへのデータの取得。OR マッパーはそれほど複雑ではなく、うまく処理できます。しかし、それは開発時間に追加されます。
コントラクト マッピング
- サーバー側オブジェクトからコントラクト オブジェクト (DTO の可能性が高い) にデータをマップすることは、一般的に良い方法です。これは CRUD スタイルのアーキテクチャに適したアプリケーションであるため、DTO は画像にあまり価値を追加せず、作業をマッピングするだけです。
共有コード
- ドメイン データとロジックを含むアセンブリがクライアント側とサーバー側の両方で利用できる、共有コード シナリオに進むことができます。これは密結合ですが、クライアント サーバー アプリが自然に密結合している場合は、必ずしも悪いことではありません。
コントラクト レイヤーを追加するかどうかに関係なく、ワイヤ経由で送信する必要がある大きなオブジェクト構造があります。クライアントとサーバーの両方を制御しているため、トランスポートとエンコーディングは TCP を介したバイナリ エンコーディングである必要があります。それは役に立ちます。データセットでは、変更のみを送り返すオプションがあります。オブジェクト構造全体を前後に送信すると、パフォーマンスの問題が発生する可能性があります。オブジェクト構造全体を送信するオプションは、関連する変更 (作成、更新、削除) を何らかの方法で識別し、それに関する情報のみを送信することです。理論的には、集約ルート ID と変更内容をサーバーに送信し、サーバーに集約ルートを遅延ロードして変更を実行し、再度保存するように依頼することはそれほど難しくありません。しかし、これに伴う大きな複雑さは、行われた変更を特定することです。このアプローチを採用することはありますか? なんで？どのように正確にそれを行いますか？
プレゼンテーション
正確な UI テクノロジは、質問にとってそれほど重要ではありません。WinForms、Silverlight、または WPF が可能です。新しいスマート クライアントであるため、WPF を使用していると仮定しましょう。つまり、双方向バインディングがあり、MVVM を適切に使用できます。
ユーザー インターフェイスにバインドされたオブジェクトは、INotifyPropertyChanged を実装し、プロパティが更新されるたびにイベントを発生させる必要があります。これをどのように解決しますか？共有コードのシナリオに進む場合は、それをドメイン オブジェクトに追加できますが、サーバー側で使用することを意図していないコードとロジックをサーバー側に追加する必要があります。コントラクト オブジェクトを使用すると、分離はより自然になりますが、マッピングのレイヤーを追加するだけでは、多くの付加価値は得られません。
テクノロジ
一部の問題の解決に役立つテクノロジはいくつかありますが、他の問題を複雑にすることがよくあります。それらを使用しますか、それともゼロから自分で構築しますか?
**
- CSLA は可能ですが、単体テストが難しくなり、データ アクセスへの結合がより緊密になるようです。それは多くの問題に役立ちますが、個人的に私はこの技術に精通していません。
- WCF RIA サービスは、Silverlight ソリューションで可能ですが、明らかに制限があります。データのサイズは 1 です。
- WCF Data Services は、何かをすばやく起動するための別のアプローチですが、REST はあまり役に立ちません。また、RIA Services にある検証サポートも不足しています。
まとめ
ここまで読んでいただければ、私がこれからどこへ向かうのか、お分かりいただけると思います。一度にすべてを話すことを避けるために範囲を絞ろうとしましたが、分散開発は複雑であるため、多くの部分を考慮する必要があります。
アップデート
返信ありがとうございます！私は、さまざまな回答を受け入れるのに十分なオープンな質問をしようとしていましたが、珍しいことではないいくつかの要件に対処するのに十分具体的でした.
さまざまな長所と短所があり、システムごとに異なるさまざまな考慮事項があります。通常、それぞれが解決策を見つけることの複雑さを増します。この質問のポイントの 1 つは、タスク ベースの UI を使用して、今日では正しい答えであることが多い 1 つの答えに必ずしも直接適合しないいくつかの追加の要件を特に指定して、答えを得ることでした。もしそうなら、私は「CRUD-guy」ではありません。しかし、いくつかのシステムは、さまざまな理由 (ほとんどの場合レガシー) から、CRUD に適しています。
多くのビジネス アプリには、さまざまな方向に向かう同様の要求があります。
ビジネス関連
- 表示: ユーザーにデータを表示し、同じデータを更新する (読み取りと CUD - 作成、更新、削除)
- 検証: ビジネス ルール
UI 関連
- 検証: UI ルール
- UI 更新: オブジェクトの変更時に UI を更新するためのコード (INotifyPropertyChanged)
ネットワーク関連
- データ サイズ: ネットワーク経由で送信するデータの量
DB 関連
- 遅延読み込み
SRP/再利用関連
- マッピング: オブジェクトの複数のレイヤーによって引き起こされる/関心の分離
メンテナンス/変更関連
- 変更: 新しい情報 (列/フィールド) の追加
- コードの量
- 再利用と「変更する理由」
技術的な制限
- 変更の追跡
しかし、これらは非常に具体的なものにすぎません。どの「-ilities」が最も重要であるかを常に把握する必要があります。したがって、スケーラビリティ、可用性、拡張性、相互運用性、ユーザビリティ、保守性、およびテスト容易性がどの程度必要かを知る必要があります。
ほとんどの状況で何かを一般化しようとすると、次のようになります。
クライアント
- 分離とテスト容易性のために MVVM を使用します -
DTO の上に VM を作成します - VM に
INotifyPropertyChanged を実装します。
- XamlPowerToys、Postsharp、またはこれを支援するその他の手段を使用する価値があります
- UI で読み取りと CUD を分離し
ます - CUD をタスクベースにし、コマンドなどを使用してそれらの操作をサーバー側に送信します
サーバー
- 画面ごとに dto
を調整する -または Ayende がhttp://msdn.microsoft.com/en-us/magazine/ff796225.aspx
で説明しているマルチクエリ アプローチを使用するあなたが解決しようとしている問題とは完全に無関係なステップです。そのマッピングは
- ドメインモデルを、読み取りではなく、CUD 関連の操作を含む主にビジネス操作に関係させます
- 変更する理由の数を増やす再利用性を避けます
-カプセル化の問題を回避する
- (それにより、CQRS スタイルのアーキテクチャを有効にし、読み取りと CUD のスケーリングを時間内に分離する可能性があります
)
http://www.lostechies.com/blogs/jimmy_bogard/archive/2009/02/15/validation-in-a-ddd-world.aspx )
これは必然的に、この特定の状況で私がとるアプローチですか?
ええと、それが私が議論を始めたかったことです:)しかし、それは私が望んでいたよりも難しかったようです（あなた方2人を除いて）。