Entity Frameworkを使用する必要がありますか？

現在、次のスタックがあります。

• VS 2005
• Webフォーム
• SQL Server 2005
• IIS 6

これへの移行を計画しています：

• VS 2010
• MVCとWebフォーム
• SQL Server 2008
• IIS 7

私の質問は、VS 2010でMVCに移行するとき、Entity Framework（または別のORM）、micro ORM（Massiveなど）、または単なるSQLを使用する必要がありますか？

VS 2010について読んだすべてのチュートリアルは、データトランザクションにEntity Frameworkを使用することを目的としていますが、それは近い将来（5年以上）続くでしょうか？

問題があれば、クライアントのアプリケーションには10〜1,000人のアクティブユーザーを含めることができます。

私は最近、インラインSQLクエリの使用からEFの使用に切り替えましたが、次のことがわかりました。

長所

• DALの構築がはるかに高速になりました（SQLクエリを記述しないのが大好きです！）
• メンテナンスがはるかに簡単
• インラインsqlステートメントを作成する前に入力を解析することを覚えておく必要がなくなりました。これは、SQLインジェクション攻撃の可能性が低いことを意味します（もちろん、クエリによっては可能ですが、可能性は低いです）

短所

• 複数のデータベースにまたがることはできません...少なくとも簡単にはできません
• すべてのエンティティ（テーブル、ビューなど）には主キーが必要です
• 100以上の必須列テーブル（私のテーブルデザインではない）の単一の列を更新する場合は、更新を行うために100列すべてをプルダウンする必要があります。または、ストアドプロシージャを使用します。
• 新しいレコードが追加された後、SQLサーバーで定義されたいくつかのデフォルト値がエンティティモデルに取り込まれないという問題がありました。通常、これは計算値、またはINSERTトリガーで追加される値を使用します
• 場合によっては、SQLクエリが誤って記述され、実行に時間がかかることがあります。実行に時間がかかるクエリがある場合は、SQLトレースを実行して、EFが実行していることを確認します。そのクエリをSPまたはビューとして再作成することができます。しかし、これはそれほど頻繁には起こりません。
• SQL Serverで外部キーが定義されていないテーブル間の関連付けを作成しようとすると、いくつかの問題が発生しました。通常1:0-1、EFが使用したい関係を作成しようとしているためです1:0-*

私はEFの専門家ではないので、おそらくいくつかのことを逃しました。これらは、インラインSQLからEntity Frameworkに切り替えるときに私が過去に遭遇したことを知っているアイテムです。切り替えを行って良かったのですが、その癖のためにEFを本当に嫌っていたことがあります。

Entity Frameworkは生産性ツールです。正当な理由がない場合（たとえば、SQL 2000を使用している場合、またはテクノロジを習得する時間がない場合）は、最適なツールを自由に使用してください。

そうは言っても、エンティティの概念はMVCパターンのモデルに非常にうまく変換できると思います。モデルやテーブルと1対1の関係を持つことは悪い習慣ですが、エンティティの観点から考えると、きれいなデザインでコードが読みやすくなります（特にLINQの場合）。

Entity FrameworkはMicrosoftによって積極的にサポートされています。「サポートはX年間続く」と言う魔法の水晶玉を持っている人はいません。エンティティが今後5年間で死ぬと信じる理由はありません。

別の潜在的な解決策は、VSで提供されるものではない代替のEntity Framework Libraryを使用することです。Webにはいくつかあります。

Entity / 3層フレームワークの概念はしばらくの間存在しており、Microsoftが独自の「公式」フレームワークをリリースする前に、他の多くの開発者と同様にいくつかのカスタムライブラリと連携していました。

長所

Microsoftの定数ライブラリ/フレームワークの変更に縛られることなく、エンティティ（DAL）フレームワークの利点を活用できます。

いくつかのdtabaseブランドを使用するなど、既存の公式ライブラリでは利用できない可能性のある機能をライブラリに追加します。

短所

ライブラリまたはツールをサポートする必要があります。エンティティジェネレータコードツールを使用してエンティティを生成することは非常に一般的です。

問題と既存のソリューションに基づいて、アーキテクチャを決定する必要があります。他の技術と同様に、長所と短所があります。

私は通常、新しい開発にはエンティティフレームワークを使用しますが、既存のコードを書き直すことはしません。そうすれば、将来の開発のスピードが得られますが、コードの変換に多くの時間を費やす必要はありません。このアプローチの欠点は、一貫性が低下することです。

あなたの状況では、私は間違いなくEntity Frameworkを使用するだろう、私はそれがMVCでうまく動作することがわかった。
ここにいくつかの本当の理由とポインタがあります。

• Linqは使いやすく、遅延実行も非常に便利です。
• あなたはそのアプローチの利用取るかどうかは、MVCで使用している場合しかし、私はあなたがデータモデルと一緒にビューモデルを使用recommentたい（あなたのモデルを生成することができ、これは、検証とモデルがたくさん容易に結合可能automapperを戻ってあなたへの変更をマップしますデータ・モデル）。

ただし、ORMの使用について学習する必要がある多くのことがあります。

• コンテキストが何をするか（エンティティトラッキング）
• コンテキストを作業単位として使用する必要があること
• 同時実行性について覚えておいてください、EFはオブジェクトが古くなったときに通知できますが、リクエスト間で同時実行性を適切に処理したい場合は注意が必要です（タイムスタンプなどを保持する必要があるため）。

考慮事項

• トリガーとORMは連動しません。代わりにORMイベントを使用してください。
• すべてのテーブルにpromaryキーがあることを確認してください。

また、既存のデータベースがある場合でも、コードファーストアプローチを強くお勧めします。

• 規則により、データベースを変更するときにマッピングまたはクラスを再生成する必要はありません。
• モデルに検証やその他のロジックを配置する方が簡単です。
• 巨大な既存のデータベースがある場合は、コードジェネレーターを使用してそれらを作成できます。