5

私はこれまで、オブジェクトを処理するために常に直接データ アクセスを使用してきました (手動でクエリを実行し、結果をデータ オブジェクトにマッピングします)。Microsoft は現在、顧客がデータ オブジェクトのクエリに使用する EF を推進していることを知っています。

これに関してコミュニティにいくつか質問があります :-

  • 複雑なデータベース、つまり数百のテーブル、かなりの量のストアド プロシージャ、ビューがある場合、すべてが 3NF になります。2 つのスキーマ (1 つのローカル EF スキーマ マッピングと 1 つの DB) を管理する負担は、トレードオフの価値がありますか?

  • データ アクセスを増やし始めたら、キャッシングは 2 つを比較してどうなるでしょうか? 直接アクセスでは、任意の形式のキャッシュを実装できることを知っていますが、EF では同様のことができますか?

  • 製品を強くプッシュし、人々に製品を書いてもらった後 (SQL-NS、Linq-to-Sql)、Microsoft が製品を破棄してきた歴史を考えると、これが EF にどのように発生する可能性がありますか?

私が言ったように、私は現在 Direct Access を頻繁に使用していますが、移行を検討しており (つまり、新しいクエリを進めており、まだすべてを後戻りするのではありません)、コミュニティの他のメンバーからの意見についてアドバイスを求めていました。 .

4

3 に答える 3

4

複雑なデータベース、つまり数百のテーブル、適切な量のストアドプロシージャ、ビューがある場合、すべてが3NFになります。2つのスキーマ（1つはローカルEFスキーママッピングと1つはDB）を管理する負担は、トレードオフの価値がありますか？

自動化されたツールを使用してEFスキーマを最新の状態に保つことができるので、それほど悪くはありません。

データアクセスを増やし始めたら、キャッシュは2つでどのように比較されますか？ダイレクトアクセスでは、任意の形式のキャッシュを実装できることを知っていますが、EFは同様の機能を許可しますか？

私の知る限り、そうです。

製品を大量にプッシュし、人々に製品（SQL-NS、Linq-to-Sql）を書かせた後、製品を殺したというMicrosoftの歴史を考えると、これはEFにどのように起こりますか？

この質問はあまりにも仮説的です。

私がEFで抱えている問題は、パフォーマンスです。ええ、あなたは急速な開発を手に入れますが、パフォーマンスとトレードオフします。EFを使用すると、悪くて遅いコードを書くのは本当に簡単です。何をしているのかを100％知らないと、後で深刻なパフォーマンスの問題が発生する可能性があります（特に、数百のテーブルを処理している場合）。 。

私が提案するのは、DapperやMassiveなどのいくつかのMicro-ORMフレームワークを試すことです。それほど多くのパフォーマンスを犠牲にすることはありませんが、従来のAdo.netアプローチよりも保守が簡単です。

しかしねえ、それは私だけです、あなたはEFを愛するかもしれません。

于 2012-06-17T12:14:45.463 に答える
1

直接データアクセスと比較したEFの主な利点は、開発者の生産性です。

アセンブリコードを作成する開発者はほとんどいないので、コンパイラに生成させます。EFのようなツールが良くなるにつれて、それらをより多く使用し、SQLの記述をやめます。

ただし、必要なパフォーマンスを得るために追加の制御が必要になる場合があるため、SQLコードを作成する必要がある場合もあります。まだいくつかのアセンブリコードが書かれているのと同じです。

動作するソリューションを変換することにビジネス価値はありません。新しい開発のためにEFを試すことができます。

于 2012-06-17T20:55:02.907 に答える
1

EF またはその他の ORM ツールで留意すべきことは、何か (EF および Linq2Entities の場合は Linq 式ツリー) を SQL ステートメントに変換するだけであるということです。そこには抽象化と解析の追加レイヤーがあるため、単純なクエリよりも常に遅くなります。ただし、通常、開発者は ORM を使用する方が簡単です。幸いなことに、ほとんどの ORM (特に EF については不明) は、必要に応じてクエリを直接実行する方法を提供しています。

あなたは「複雑な」データベースを持っていると言いましたが、それは通常、複雑なクエリを持っていることを意味します。それは、Linq があまり好きではないことです。たとえば、13 個のテーブルを結合するクエリがあり、返されたほぼすべての列が db 関数に渡され、多数の case ステートメントと多数のサブセレクトがある場合、Linq に変換することはほとんど不可能になります。 . より簡単なのは、その複雑さをビューにラップし、EF を使用してビューをクエリするだけです。

プラス面としては、実際のクラスは DB を模倣するように構築されているため、EF は開発者にインテリセンスを提供します。EF のレイアウト方法に応じて、クラスがすべて DB から生成されるようにプロジェクトを設定できます。そのため、誰かが DB スキーマを編集したり、列のデータ型を変更したりすると、C# コードはコンパイルしなくなりました。従来の直接 SQL クエリでは、実行時 (または統合テスト時) までそれを見つけることはできません。

それはすべてトレードオフです... IMOの最善の方法は、両方を試してどちらが良いかを確認するか、どちらかのオプションを提供するような方法でソリューションを構築することです。私が最後に取り組んだアプリには、他のデータ アクセス クラスが使用する "データベース ファクトリ" クラス (ファクトリ パターン) があり、ファクトリにプレーンな古い ADO.NET コマンド オブジェクトを要求するか、 ORM オブジェクト (EF の場合は Context ですが、SubSonic を使用していたため、代わりに IQueryable 実装でした)。そうすれば、EF を介して「単純な」クエリを実行したり、SQL で「複雑な」クエリを実行したりできます。

于 2012-06-17T12:51:15.120 に答える