3

私が現在取り組んでいるプロジェクトには、多くの検索/フィルタリングページが必要です。たとえば、データ、カテゴリ、ユニットなどで問題を取得するための複雑な検索ページがあります。

問題ドメインクラスは複雑で、多くの値オブジェクトと子オブジェクトが含まれています。

。UIの検索/フィルタリング/レポートをどのように処理するのか疑問に思っています。私の知る限り、私には3つの選択肢がありますが、どれも私を幸せにするものではありません。

1.）パラメータをRepository / DAOに送信して、DataTableを取得し、DataTableをUIコントロールにバインドします。たとえば、ASP.NETGridViewに送信します。

DataTable dataTable =issueReportRepository.FindBy(specs);
.....
grid.DataSource=dataTable;
grid.DataBind();

このオプションでは、ドメインレイヤーを渡すだけで、指定された仕様のデータベースをクエリできます。そして、完全に構築された複雑なドメインオブジェクトを取得する必要はありません。値オブジェクト、子オブジェクトなどは必要ありません。データベースから直接DataTableのUIに表示するデータを取得し、UIに表示します。

しかし、メソッドの戻り値のようにUIで計算フィールドを表示する必要がある場合は、完全なドメインオブジェクトがないため、データベースでこれを行う必要があります。インテリセンスなどのロジックとDataTableの問題を複製する必要があります...

2.）パラメータをリポジトリ/ DAOに送信してDTOを取得し、DTOをUIコントロールにバインドします。

IList<IssueDTO> issueDTOs =issueReportRepository.FindBy(specs);
....
grid.DataSource=issueDTOs;
grid.DataBind();

このオプションは上記と同じですが、検索ページごとに貧血のDTOオブジェクトを作成する必要があります。また、さまざまな問題検索ページについて、問題オブジェクトのさまざまな部分を表示する必要があります。IssueSearchDTO、CompanyIssueTO、MyIssueDTO...。

3.）パラメータをReal Repositoryクラスに送信して、完全に構築されたドメインオブジェクトを取得します。

IList<Issue> issues =issueRepository.FindBy(specs);
//Bind to grid...

私はドメイン駆動設計とパターンが好きです。このオプションにはDTOまたは複製ロジックはありませんが、このオプションでは、UIに表示されない多数の子オブジェクトと値オブジェクトを作成する必要があります。また、完全なドメインオブジェクトと針の子のパフォーマンスコストを取得するには、ロットのob結合が必要です。オブジェクトと値オブジェクト。

私はORMツールを使用していません。このバージョンでは手動で遅延読み込みを実装できるかもしれませんが、少しやり過ぎのようです。

どちらが好きですか？それとも私は間違っていますか？これを行うための提案やより良い方法はありますか？

4

2 に答える 2

2

いくつかの提案がありますが、もちろん全体的な答えは「場合による」です。

まず、ORM ツールを使用する必要があります。または、そうしない十分な理由がある必要があります。

次に、遅延読み込みを手動で実装するのは比較的簡単なので、ORM ツールを使用しない場合は、次のようなプロパティをオブジェクトに作成するだけです。

private Foo _foo;
public Foo Foo
{  
  get {  
         if(_foo == null)
         {
            _foo = _repository.Get(id);
         }
         return _foo;
       }
}

第 3 に、パフォーマンスは最初に考慮する必要がありますが、エレガントなデザインから離れるべきではありません。最初は (3) を使用し、そのパフォーマンスが不十分な場合にのみそれから逸脱する必要があると私は主張します。これにより、最小限のコードを記述し、設計の重複を最小限に抑えることができます。

パフォーマンスが低下した場合は、キャッシングを使用して UI レイヤーで、または遅延読み込みを使用してドメイン レイヤーで簡単に対処できます。これらの両方が許容できるパフォーマンスを提供できない場合は、必要な値オブジェクトの軽量コレクションのみを返す DTO アプローチにフォールバックできます。

于 2009-01-28T04:08:38.980 に答える
1

これは素晴らしい質問であり、私も答えを提供したいと思いました。技術的に最良の答えは、オプション #3 を使用することだと思います。レポート/検索要求に対する将来の機能強化のためのスケーラビリティとともに、データを最適に記述および整理する機能を提供します。

ただし、これは全体的には最良のオプションかもしれませんが、レポートのニーズをサポートするために必要なすべてのクラスと関係の追加の設計時間である他の (2) オプションと比較して、IMO に莫大なコストがかかります (これも、あるという前提の下で)。 ORM ツールは使用されていません)。

私も多くのアプリケーションでこれに苦労していますが、現実には、時間と設計の間の最良の妥協点は #2 です。あなたのビジネスオブジェクトとそのすべてのニーズについて尋ねているなら、完全にレイアウトされ、適切に設計されたモデルが重要であり、代替がないことに疑いの余地はありません. しかし、これを報告して検索することになると、私は別の動物です. #2 は貧血クラスで厳密に型指定されたデータを提供し、#1 のような DataSet のハードコードされた値ほどプリミティブではなく、それでも #3 と比較して設計を完了するのに必要な時間を大幅に短縮します。

理想的には、オブジェクト モデルを拡張してすべてのレポート ニーズを網羅したいと考えていますが、これを行うために必要な作業が非常に膨大になる場合があるため、レポート ニーズのためだけに別のクラス セットを作成する方が簡単ですが、それでも実行可能なオプションです。実際、私は数年前にほぼ同じ質問をしましたが、レポートのニーズのために別のクラス セット (本質的には DTO) を作成することは悪い選択肢ではないとも言われました。

まとめると、技術的には #3 が最良のオプションですが、複雑なレポート作成と検索のニーズに合わせて時間と品質を考慮すると、おそらく #2 が最も現実的で実行可能なオプションです。

于 2012-03-05T15:01:40.590 に答える