エンティティフレームワークによるエンタープライズライブラリデータアクセスブロックの置き換えについてのアドバイス

Question

数年前、「データベースエンジン」に依存しない大きなASP.Netアプリケーション（C＃/ .net 3.5）を開発しましたSQL Server、Oracle、MySQL ...をDBエンジンとして使用してください）。そのために、エンタープライズライブラリデータアクセスブロック4.1を使用しました。

しかし、私たちは「パフォーマンス/スケーラビリティの向上」段階にあるため、アプリケーションの基礎の技術のアップグレードや再設計について考えています。

したがって、問題は、Entity Frameworkに移行する利点はありますか？ EFは非従属の「データベースエンジン」基準を維持しますか？ EntLib DAABの実装を維持し、最新のバージョン（5.0）にアップグレードする必要がありますか？

おかげ

Answer 1

ありオラクル（Devart dotConnect for Oracle、DataDirect）とMySQL（Devart dotConnect for MySQL、MySQL Connector /NET）のためのEFプロバイダの数であり、MicrosoftはSQL ServerのEntity Frameworkのプロバイダを提供し、これで何か問題があってはなりませんデータベースの独立性。

Answer 2

これらの間で最大の問題は、データベースの独立性に関するものではなく、使用パターンが根本的に異なることです。データアクセスブロック（DAAB）は、主にADO.NETの便利なラッパーです。ストアドプロシージャを呼び出すのが面倒ですが、データセットやデータリーダーを扱っています。実際にデータベースとのやりとりの仕方が変わることはありません。迷惑なことはありません。

一方、エンティティフレームワークは、データモデリングとオブジェクトリレーショナルマッピングに関するものです。 DAABよりも高いレベルで動作します。 DataSetsやDataReaderではなく、オブジェクトの観点からコードを記述します。データベースからオブジェクトの「マテリアライゼーション」を自動化するので、コードを書く必要はなく、それらの間の関係を維持するなど、データベースとはかなり異なった作業方法です。

まず、データアクセスのORMスタイルに移行するかどうかを検討する必要があります。そこから、.NET空間内のEFまたは他の多くのORMのいずれかがニーズに最も適しているかどうかを判断できます。

EFで利用できるプロバイダはたくさんあります（リストについてはDevartの回答を参照してください）が、すべて外部/追加コストです。このボックスの唯一のものはSql Server用です。 DAABは実際にはデータベースの独立性を完全にはカバーしていないと付け加えますが、実際のSQLをDAAB呼び出しに使用すると、SQLの方言の違いに役立ちません。 EFの意志。

Answer 3

エンティティフレームワークに移行する利点はありますか？

通常、データアクセスの作業が迅速になります。 Linqの構文は素晴らしいですし、SQLを照会することができます。

EFは依存しない "データベースエンジン"基準を維持しますか？

3rd partyのサポートなし。実際に機能しているアプリケーションを使用し、SQLとの間でデータベース技術を交換した開発者はいませんが。

EntLib DAABの実装は維持しますが、 最新バージョン（5.0）にアップグレードする必要がありますか？

DAAB is awesome !!私はコードgeneratorを書きました。また、非常に貧弱なリレーショナル・スキーマを持つ大規模なデータベースのEFを実装した後、EFの「ウィザード」が110 SQLテーブル（約3分）を更新するのに長い時間を要していました。それは遅すぎて、私はDAABに戻りました...しかし、私は前方がEFだと言うでしょう。私はストアドプロシージャとNo Tracking for with performanceを使用してみてください。もう1つは、2人が別々にエンタテインメントを更新するときにEFで認識しなければならないことは競合をマージすることです。それは混乱することがあります。