ORMに関してとその欠点については多くのトピックが書かれている。異論のほとんどは2つのカテゴリに分類できる: 関心の分離とオブジェクト指向デザインである。Entity Frameworkに関しては私たちはひとつのよいニュースを持っている。
関心の分離
ストアドプロシージャは、データベースに非常識な量のビジネスロジックを詰め込むだけのものではない。アプリケーションレイヤに詰め込まれたばかげた量のストレージロジックを維持するための方法でもある。これはDBAの思想を考えなくてもよいデータの理想的な表現をアプリケーションに公開することができる。ステージングテーブル、正規化されていないレポーティングテーブル、ビュー、テーブル関数の集約は、データベースの公開APIから呼ばれた単純なストアドプロシージャにすべて隠されている。データベースに依存する多くのアプリケーションを再配置することなく、ちょっとしたパフォーマンスチューニングから、完全なリファクタリングまでを終わらせることができる。
次の2つのバージョンでEntity Frameworkは、ストアドプロシージャをはるかに簡単に利用できるようにしている。まもなくリリースされるバージョン5では、多くのテーブル値関数とモデルに対してストアドプロシージャのバッチインポート機能を見ることができる。
テーブル値関数(TVF)は、ORMに特にマッチする。TVFは、通常のストアドプロシージャやビューよりもはるかに柔軟だが、動的なSQL生成なしにはそれらの完全に活用することはできない。そして実際に、SQL生成は見せかけのデータマッパーからORMを分離する主要な機能である。
残念ながら、これはモデリングツールを使う開発者だけが使用可能だ。Entity FrameworkのCode First技術を使っている場合、様々な種類のストアドプロシージャがサポートされるEntity Framework 6まで待つ必要がある。
オブジェクト指向設計
OOP設計のトピックは難しい。とても自然にORMは、デフォルトコンストラクタとパブリックプロパティを持ち、レイヤの遅延読み込みでき、変更管理など単純化したDTOスタイルオブジェクトを望んでいる。しかしオブジェクト指向設計を好む開発者は、複雑なコンストラクタと制限されたパブリックインターフェイスを持つリッチなオブジェクトを好む傾向にある。CreatedByやCreatedDateのようなカラムは読み取り専用項目にして、誤った値を変更することができないようにするべきである。
残念ながら私たちは、これをすぐに見ることはできない。いくつかをプライベートセッターにして、いくつかを行うことができるが、汎用エンティティはまだ本当のビジネスオブジェクトというよりもDTOに見えてしまう。長期的にはカスタムCode First規約が助けになるだろう。この有望な機能は、EF 4.1の一部としてサポートされるはずだったが、設計の複雑さとまだ準備ができていないという一般的な感覚によりカットされた。Sergey Barskiy氏の提供されるはずだったものを紹介した記事が存在している。