4

適度に大きなVB.NET2.0アプリ（データセットを使用）をC＃4.5（EF4を使用）に移行する新しいジョブを開始しました。

ビジネスレイヤーから、「検索」関数がEDMXで定義されたクラスのIEnumerablesを返すようになりました。したがって、このようなものは簡単です。

public IEnumerable<Product> GetProductsByCategory(int categoryId)

ただし、EF4の「Select（）」メソッドがより複雑でカスタマイズされた（匿名の）型を生成する場合は、より複雑になります。結果に対応する生成されたクラスはありません。

この関数は層の境界（ビジネスからUI）を越える必要があるため、適切な解決策は、このクエリのカスタムタイプを定義してから、そのタイプのIEnumerableを返すことだと思いました。例えば

public IEnumerable<ProductAccountSummary> GetProductAccountSummariesByCategory(int categoryId)

ProductAccountSummary手作りのDTO（つまりPOCO）はどこにありますか。

ただし、コードレビュー中に、チームリーダーは私のアプローチに失敗しました。彼は私にDTOを削除し、メソッドシグネチャを次のように変更するように求めました。

public IEnumerable GetProductAccountSummariesByCategory(int categoryId)

....その理由は、カスタムタイプを使用する必要があるたびにDTOを手作りするオーバーヘッドなしに、IEnumerableをUIグリッドなどにバインドできるためです。

だから私の質問は：

  • EF4では、カスタムタイプのコレクションを層の境界を越えて渡すための一般的なアプローチは何ですか？IEnumerable（暗黙的に「オブジェクト」の）を返すことは、私には正しくないようです。私は何かが足りないのですか？
4

1 に答える 1

4

あなたのチームリーダーは単に間違っていると思います。強く型付けされたオブジェクトを扱うことは、一般的に物事を行う方法と見なされます。このアプローチを使用すると、データセットなどのタイプを再び操作する世界に戻ります。オブジェクトを変更してビジネスレイヤーに戻す必要が生じ始めると、長期的なメンテナンスの問題が発生します。ビジネス層に何も返す必要がない場合でも、クライアント側でメンテナンスの問題が発生することさえあります。

はい、DTOの作成にはオーバーヘッドがありますが、短期的な速度が最終的な長期的なメンテナンスの問題に使用される理由であってはなりません。

于 2012-11-04T03:33:16.617 に答える