新しいインターネット Web アプリに EF (.NET 4.5 の標準) を採用しました。
このアプリには、db アクティビティに対するかなりの操作が含まれ、約 30 以上のテーブルが含まれます。
私が言いたいのは、これは単純な学校のプロジェクトではなく、通常、EF がほとんどのニーズに適しているということです。
このアプリをさらに開発するにつれて、適切な/優れたデータベース設計に対してEFが非常に制限されているか禁止されていることがわかりました（特にパフォーマンスに対する用語）
1) 含める
クエリ部分でインクルード機能に遭遇しました。多くのデータが欠落しているのは、インクルード設定が欠落しているためです。
このことを入れれば入れるほど、単純なデータ検索が特定の機能で必要以上のものを取得するのではないかと心配になります。
2) 検証
データ コード自体にコードを直接変更する必要がないビジター パターンを好むため、このニーズに対応するために Fluent Validation を採用しています。
しかし、サブクラス化するにつれてより多くの課題が発生するため、OOP の単純なものを尊重できる検証を行う必要があります。私はそれを管理しましたが、その実装ではより複雑で、特定のことが本当に嫌いでした。このサブクラスの検証の問題は、DataAnnotation でも発生したと思います。
3) 取引
ここで、適切な db トランザクション制御を組み込む必要があります。これが EF に欠けていることがわかりました。間違っている場合は修正してください。
私はエンタープライズ コンポーネント (.NET の COM+、ずっと前) を使用していましたが、EF で適切な (またはその欠如) トランザクションの実装を見つけることができません。
私はまだこれに取り組んでいます...
結論）
コーディングで EF が唯一役に立ったのは、他の多くのツール/フレームワークに共通の機能であるデータ/エンティティ コードの生成であることに気付きました。
この EF を破棄し、EF 以前の時代のアプローチに戻し、ストアド プロシージャを採用し、まだコード生成されたテーブル クラスを採用することを考えています (ただし、EF や DBML は使用しません)。
過去にパフォーマンスの問題で多くの課題があったため、SQL LINQ なしで行うことができます。
現実的にはほとんど機能していないこのORMは別として、私の単純な心が理解できる理由が何であれ、私はEFにとどまって固執するべきだというあなたの意見が好きです。