0

私は、仕事中のプロジェクトに Microsoft のエンティティ フレームワークを使用して調査してきました。Linq-to-Entity を使用して、標準の ADO.Net 実装と Entity Framework バージョンを記述できるように、IDataService インターフェイスを備えたシンプルで小さなデータ レイヤー ソリューションを作成しました。

まったく同じデータを要求するが、異なる実装を使用する 2 つのテストを作成しました。クエリは単純で、テーブルからデータを取得し、階層情報を使用して階層内のデータで DTO を生成します。

データベース内のデータは、

------------------------
ID  | Description
----|-------------------
1   | Item 1
2   | Item 2
3   | Item 3
4   | Item 4
5   | Item 5

----------------
Parent | Child  
-------|--------
1      | 2
1      | 3
3      | 4
1      | 5

Desired Output
--------------
Item 1
|-Item 2
|-Item 3
| |-Item 4 
|-Item 5

そのため、クエリは現在次の形式をとっています。

from a in tableA
join b in tableB on b.Parent equals a.ID
where b.Parent == root.ID
select new DTO.Entry {
  Id = a.ID
  ...
}

このクエリを含むメソッドは、処理する子要素がなくなるまで再帰的に実行されます。

Linq-to-entity を使用すると、テストが完了するまでに約 320 ミリ秒かかり、ADO.Net を使用すると、テストに約 8 ミリ秒かかります!

これは私が一緒に暮らす/考慮しなければならないものですか、それともパフォーマンスはほぼ同等であるべきですか? また、基礎となるデータ構造には参照整合性がないため (わかっています!)、ADO.Net でこれを補っていますが、エンティティではできません。これは影響を与える可能性がありますか?

現時点では、パフォーマンスが必要な場合は、ADO.Net を使用する必要があるようです。

4

1 に答える 1

2

顧客に尋ねます: パフォーマンスを向上させたいですか、それともバグを減らしたいですか?

もちろん、単純な ADO.Net は、ADO.Net を使用するデータ レイヤーよりも優れたパフォーマンスを発揮しますが、その前後ではさらに多くのことが行われます。さらに、効率に関しては EF が優れた競合相手ではない領域、つまり再帰クエリを選択しました。しかし、一般的に、許容できるパフォーマンスを発揮する正確で安定したコードを作成することになると、EF (または経験豊富な OR マッパー) は ADO.Net よりもはるかに優れています。これは、手書きの SQL およびデータ駆動型プログラミングと、linq およびオブジェクト指向プログラミングです。

それにもかかわらず、あなたが言うとき、あなたは正しい

現時点では、パフォーマンスが必要な場合は、ADO.Net を使用する必要があるようです。

確かに、パフォーマンスが重要な操作やマッパーの場合、内部オーバーヘッドが多すぎて請求書に収まらない傾向があります。再帰クエリに戻ると、データベース内の CTE を使用した再帰クエリに勝るものはありません。

于 2012-08-19T21:48:06.313 に答える