9

質問全体がより明確になるように書き直されました..

新しいプロジェクトの設計:

  1. SQL Server 2012
  2. Visual Studio 2012 .Net 4.5
  3. ビジネスロジックはストアドプロシージャで実装されます
  4. ASP.Net Web フォーム
  5. DBA が提供するストアド プロシージャを使用してデータベースと通信するための WCF SOAP XML Web サービス
  6. エンティティ フレームワークまたはデータセット

ここでは Dataset を使用できます - 問題ありませんが、Dataset に対する Entity Framework の利点をより詳細な説明で知りたいと思います。私はエンティティ フレームワークに関する記事を読んでいましたが、次の理由により、データセットよりも EF を使用した方が優れていることがわかりました。

私の場合、これらがまだEFを使用して得られる利点であるかどうかを知りたいです-データベース関連のアクションは常にストアドプロシージャで行われます：

  1. EF は非常にクリーンで、保守とプログラミングがはるかに簡単です。EF ObjectContext に対するクエリは、常にデータベースに対して実行されます。

  2. オブジェクトとデータベース間のマッピングはコードではなく宣言的に指定されるため、データベース スキーマを変更する必要がある場合、アプリケーションで変更する必要があるコードへの影響を最小限に抑えることができます。アプリをデータベースから分離するのに役立つ抽象化。したがって、EF は、そうでなければ自分で作成して維持する必要があるコードの大部分を置き換えることができます (ストアド プロシージャの設計が変更された場合はどうなるでしょうか?)。

  3. EF は、オブジェクトの構築と変更の追跡から、クエリのマッピング/結果の形成のプロセスを分離するように特別に構成されています。

  4. DataSets は、特に WCF シナリオでは最悪です (メモリ内データ操作を処理するために多くのオーバーヘッドが追加されます) -> WCF を使用した EF の方がパフォーマンスが優れていることを意味しますか?

4

2 に答える 2

12

1. EF は非常にクリーンで、保守とプログラミングがはるかに簡単です ->> 詳しく説明していただけますか?.. これは以下の #2 によるものですか?

EF はオブジェクト リレーショナル マッパー (ORM) であり、#2 で説明したように、データベース スキーマに関連するオブジェクトを自動的に生成します。EF は、データ アクセス レイヤーのすぐに使える抽象化であり、現在のバージョンではリポジトリ パターンを実装しています。これにより、LINQ、オブジェクト グラフの CRUD 操作、EF チームが .NET 経由でデータにアクセスするためのベスト プラクティスと見なすものなどの利点が得られます。

すぐに使用できる機能と、データベース (特に SQL Server) との統合の容易さにより、保守とプログラミングが容易になります。ただし、ORM の使用が最善の選択肢ではない場合もあり、慎重に判断する必要があります。以下に、ORM を使用しないことを検討するシナリオをいくつか示します (特に、チームが現在の EF の知識を持っていない場合): データ クエリが限られている、アプリケーションが複雑でない、データ アクセス レイヤーを快適に作成または使用できる、アプリケーションの期限が迫っている、など。以下に記した他のオプション。

2. データベース スキーマを変更する必要がある場合、アプリケーションで変更する必要があるコードへの影響を最小限に抑えることができます ->> ストアド プロシージャのパラメーターと返されるフィールドが変更された場合はどうなりますか? EF は依然として影響を最小限に抑えますか?

はい、EF は、データベース スキーマの単なる XML ファイルである EDMX ファイルに基づいて生成します。これには、ストアド プロシージャにマップされるオブジェクトの更新が含まれます (注: EF6 がリリースされるまでコードを最初に使用する場合、これは適用されません)。ストアド プロシージャを変更すると、EF は更新されたスキーマを取得してコードを更新できます。ただし、EF ストアド プロシージャ メソッドを呼び出してパラメーターが変更されたコードを修正する必要があります。オブジェクト メソッドとしてストアド プロシージャ呼び出しを提供する EF に慣れていない場合は、LINQ to SQL を使用することもできます。

3. DataSet は、特に WCF のシナリオでは最悪です (メモリ内のデータ操作を処理するために多くのオーバーヘッドが追加されます) ->> 詳しく説明していただけますか?

「DataSets suck」は明らかに一般的なステートメントです。.NET を使用してメモリ内のデータを処理する目的で DataSet を使用します。DataSet はメモリ内にあるため、単純な CRUD 操作を行う場合、効率が悪いと見なされます。SQL データベースでの効率的なデータ読み取りのために、ストアド プロシージャとデータ リーダーを使用することをお勧めします (データの読み取りが終了したら、それらを閉じてください)。

そこにはEF以外のオプションがあります：

  1. 自分でやる - ストアド プロシージャを記述し、データ リーダーを使用し、POCO オブジェクトにマップする

  2. 動的ライブラリを使用する - Dapper、ServiceStack ORM Lite、Simple POCO、Simple Data、Massive

  3. LINQ to SQL を使用する - 軽量データ アクセス レイヤー (SQL Server のみ)

  4. その他の ORM - NHibernate が一番の選択肢です。

于 2013-01-03T22:38:05.300 に答える