5

さまざまなシナリオで単純な DTO を使用しているときに、同じ種類の問題に頻繁に遭遇し、それを処理するためのより良い方法があるかどうか常に疑問に思っていました。

問題は、たとえば、一連のプロパティ、子オブジェクト、および計算フィールドを持つビジネス オブジェクトがありAsset、そのうちのいくつかは時間の意味で計算するのに高価であり、いくつかはデータ量の意味で巨大です。UI のさまざまな画面で、このオブジェクトの別のフレーバーを使用する必要があります。

  • 階層が表示されているツリーで、表示名以外は必要ありません
  • いくつかのプロパティのみを表示しているグリッドで
  • 詳細ペインには利用可能な情報の大きなサブセットがありますが、その一部 (マップされたオブジェクトなど) はオンデマンドでのみ表示されます

このシナリオで最適なパフォーマンスを達成できるようにするために、私は常にコンテキストごとに異なる DTO を作成し、そのコンテキストで実際に使用される情報のサブセットのみを含めました。リソースを最適化するソリューションですが、これはいくつかの問題を引き起こします。

  • 膨大な数の DTO クラスでクラスが急増しています
  • のような同じものに異なる名前を付けるのにかなり苦労AssetDtoForGridInTheOverviewScreenInTheUpperPaneAboveTheSplitterします。後でそれらを維持することは言うまでもありません
  • ほとんどの DTO で使用されているがすべての DTO では使用されていないプロパティがあるため、変換メソッドで頻繁に繰り返します (したがって、それらをスーパークラスに入れて変換ロジックを再利用することはできません)。

私が使用しているテクノロジは ASP.NET SOAP WebServices と C# 3.5 ですが、これは言語に依存しない問題である可能性があると思います。どんなアイデアでも大歓迎です..

4

2 に答える 2

4

これは、DTO の既知の問題です。MSDNのこの平凡な記事で説明されています。言い換えると、DTO は最も用途の広い n 層データ アクセス パターンですが、ほとんどの作業が必要です。

AutoMapperなどの規則ベースのマッピングを使用して、マッピングに関するいくつかの問題に対処できます。

クラス爆発に関して言えば、あまりにもフラットなデータ構造を使用している可能性がありますか?

DTO には論理的な繰り返しではない大量の意味的な繰り返しが自然に含まれているため、これを判断するのは難しい場合があります。たとえば、意味的に類似した型を持っていても、一方が ViewModel で、もう一方がドメイン オブジェクトである場合、それらは意味構造を共有している可能性がありますが、責任は大きく異なります。

一方、同じアプリケーション層(UI など) で多くの繰り返しがある場合は、DRY 原則に違反している可能性があります。この場合、関連するデータを最初はフラットなデータ構造として別のクラスにカプセル化すると役立つことがよくあります。私が知っているほとんどの UI フレームワークでは、フラット ディスプレイを階層構造のクラスにデータバインドすることができます。

于 2010-02-14T08:41:58.170 に答える
1

クラス爆発の問題は DTO アプローチに固有のものであり、おそらくそれについてできることはあまりありません。ビューモデルと DTO モデルを混同しないように注意してください。DTO は、データ層からフロント エンドにデータを取得するためにのみ使用し、プレゼンテーションには使用しないでください。

.NET 3.5 の出現により、いくつかの基本的でより粗い DTO を実装することを選択し、ViewModel を、DTO から動的に作成できる匿名型に置き換えることができます。これは非常に柔軟なソリューションであることがわかりました。

命名規則に関しては、DTO をシナリオにグループ化し、対応する名前空間に配置すると便利です。たとえばSolution.AssetManagement.Asset、Solution.AssetReporting.Asset

于 2010-02-14T09:23:56.047 に答える