8

アプリケーションで DTO または自己追跡エンティティを使用する必要があるかどうかを判断するために、設計について自問できる質問は何ですか?

考慮すべきことがわかっていることを次に示します。

  • WPF/MVVM クライアント、WCF サーバー、および MS SQL データベースを備えた標準の n 層アプリケーションがあります。
  • ユーザーは独自のインターフェイスを定義できるため、WCF サービスから必要なデータは、ユーザーが定義したインターフェイスに基づいて変化します。
  • モデルは、検証のためにクライアント側とサーバー側の両方で使用されます。DTO または STE に直接バインドすることはありません。
  • 一部のモデルには、必要に応じて WCF サービスから遅延ロードされるプロパティが含まれています
  • データベース層は、複数のサーバー/データベースにスパムを送信します
  • サーバー側には、データが返される方法に影響する権限チェックがあります。たとえば、一部のデータは、ユーザーの役割に基づいて部分的または完全にマスクされます
  • 私たちのリソースは限られています（時間、人員など）

では、私たちにとって何が正しいかをどのように判断すればよいのでしょうか? 私はこれまで EF を使用したことがないので、STE が適切かどうかはわかりません。

STE から始めて、問題が発生した場合にのみ DTO を実装することを提案する人を見てきましたが、現在 DTO が導入されており、STE を使用することで作業が楽になるかどうかを判断しようとしています。切り替えにそれほど時間はかからないプロセスの初期段階にありますが、STE に切り替えて、それがうまくいかず、すべてを元に戻す必要があることを知るためだけに切り替えたくありません。

4

3 に答える 3

9

あなたのアーキテクチャを理解していれば、次の理由からSTEには適していないと思います。

  • モデルは、検証のためにクライアント側とサーバー側の両方で使用されます。DTO または STE に直接バインドすることはありません。

STE の主な利点 (および唯一の利点) は追跡機能ですが、追跡機能は STE が両側で使用されている場合にのみ機能します。

  • データのクライアント クエリ サーバー
  • サーバーは EF にクエリを実行し、一連の STE を受け取り、それらをクライアントに返します。
  • クライアントは STE を処理し、変更してサーバーに送り返します。
  • サーバーは STE を受信し、転送された変更を EF => データベースに適用します

つまり、クライアント側またはサーバー側に追加のモデルはありません。STE を完全に使用するには、次の条件を満たす必要があります。

  • サーバー側モデル (= 別のモデルなし)
  • WCF で転送されたデータ (= DTO なし)
  • クライアント側モデル (= 個別のモデルなし、STE に直接バインド)。そうしないと、バインドされたオブジェクトの変更イベントを処理し、STE を変更するときに、追跡ロジックが複製されます。(クライアントとサーバーはアセンブリを STE と共有します)。

他のシナリオは、自己追跡機能を利用しておらず、必要がないことを意味します。

他の要件はどうですか？

  • ユーザーは独自のインターフェイスを定義できるため、WCF サービスから必要なデータは、ユーザーが定義したインターフェイスに基づいて変化します。

これはおそらく可能ですが、各「遅延ロード」部分が個別の構造であることを確認してください。クライアント側で複雑なモデルを構築しないでください。エンティティ グラフ全体を更新のために送り返さなければならないという質問を既に見てきましたが、これは常に必要なものではありません。そのため、ロードされたパーツを単一のエンティティ グラフに接続するべきではないと思います。

  • サーバー側には、データが返される方法に影響する権限チェックがあります。たとえば、一部のデータは、ユーザーの役割に基づいて部分的または完全にマスクされます

実際にこれをどのように達成したいのかわかりません。STE はプロジェクションを使用しないため、エンティティ内のフィールドを直接 null にする必要があります。エンティティが追跡状態でない場合、またはマスキングがデータベースに保存される場合に、これを行う必要があることに注意してください。

  • データベース層は、複数のサーバー/データベースにスパムを送信します

それはSTEの問題ではないものです。サーバーは、正しい EF コンテキストを使用してデータを読み込んで保存する必要があります。

STE は変更セット パターンの実装です。それらを使用したい場合は、そのルールに従ってパターンを最大限に活用する必要があります。正しく使用すれば時間を節約できますが、この高速化には、いくつかのアーキテクチャ上の決定が犠牲になります。他のテクノロジーと同様に、これらは完璧ではなく、使いにくい場合があります (自己追跡エンティティタグに従って質問を参照してください)。これらにはいくつかの重大な欠点もありますが、.NET WPF クライアントではそれらを満たすことはできません。

于 2011-03-28T19:12:48.397 に答える
4

特定のシナリオで STE を選択できます。

  • すべての STE は POCO であり、.Net は変更追跡のために 1 つのレイヤーを動的に追加します。
  • T4 テンプレートを使用して STE を生成すると、時間を節約できます。
  • Automapper などのツールを使用すると、 WCF から返されたデータ コントラクトをエンティティまたは DTO に手動で変換する時間を節約できます。

STE の長所 -

  1. 変更を手動で追跡する必要はありません。
  2. WCF の場合、applydbchanges と言うだけで、エンティティが自動的に更新されます

STEの短所 -

  1. 動的追跡のため、STE は POCO よりも重い

POCOの長所 -

  1. 軽量
  2. EFまたはnHで簡単にブリッジ可能

POCOの短所 -

  1. EFで変更を手動で追跡する必要があります。(痛い)
于 2011-03-25T19:47:12.953 に答える
0

POCO は動的にプロキシされ、回線上では適切に動作しませんが、回避策についてはこの MSDN の記事を参照してください。したがって、それらを作成することはできますが、WPF/MVVM 開発とうまく連携していると私は信じているため、STE を使用する方がよいでしょう。

于 2011-03-28T18:13:42.833 に答える