-1

EF がデータ アクセスの望ましいソリューションではない状況はありますか? DataReader と DataSet の対比と、大量のデータをストリーミングしようとするときに後者がしばしば望ましくないことを思い出してください。そのため、EF が適切ではないユースケースがあるかどうかに興味があります。あるいは、EF がどのように使用されるかという課題や落とし穴を提示する場所でしょうか? ありがとう

4

2 に答える 2

1

一般的に言えば、すべての抽象化は、何かにファサードを提示することです。ファサードの理由には多くの理由があるかもしれませんが、通常は複雑さよりも単純化を示しています。

EF は、オブジェクト指向の世界からリレーショナルの世界へのマッピングの複雑さに起因するインピーダンスを軽減するための ORM 階層化を提供します。そうすることで、独自のマッピングをローリングする場合とは異なるオーバーヘッドが発生します。ある意味では簡単で、ある意味では難しい。機能を提供することの一部は、オーバーヘッドの増加 (パフォーマンスまたは問題ドメインへの有効性) であり、これを管理する必要があります。さらに、(私の経験では)何かを単純化する抽象化は、通常、できることとできないことに制限をもたらします。これは、どの設計でも考慮する必要があります。

答えは、EF が提供する機能が、そのやり方によって制限されるという利点と労力を克服できない場合です。

これが単純な CRUD クライアント サーバー アプリケーションである場合の典型的な例で、最近では通常、Codesmith や IronSpeed などのツールを使用して自動生成できます。

于 2012-06-01T12:24:07.177 に答える
-7

ほぼすべての重要な現実世界の状況で、ユーザーの満足度を重視する場合は、シンプルさとプログラマーの利便性という空虚な約束があります。そして、物事を成し遂げることにもっと関心がある場合は、漏れやすい抽象化をデバッグしてください。

于 2012-06-01T12:22:59.070 に答える