私はEFが何を処理できるのかを確認するためにEFと遊んでいます。 EFを使用できるさまざまなシナリオについても、多くの記事や投稿で説明されていますが、「欠点」を見逃した場合はどういうわけか。私の質問は、
どのようなシナリオでEntity Frameworkから遠ざかるべきかということです 。
この分野での経験がある場合は、どのシナリオがEFとうまくいかないかを教えてください。あなたが別の技術を選択したであろうと願ったところであなたが経験したいくつかの欠点について教えてください。
私はまさに「遊び回り」の段階にあります、そして私は内蔵の持続性不可知論主義の欠如について心配していました、しかし私は「回避策」があるであろうと確信していました。
実際、n層アーキテクチャでの回避策すらありません。
WCF + EF
この記事を正しく読んでいれば、（WCFを使用して）ワイヤを介してエンティティをシリアル化する際に問題は見られず、永続性の無知も問題にはなりません。
これは私が主に単体テストにPIを使用するからです。
単体テスト が可能です。 （おもう）
このシステムでは、（たとえば、ファクトリから生成される可能性がある別のインタフェースベースのクラスでサービスへの呼び出しをまとめて）モックサービスを使用することができます。これは私たちの発表者コードをテストするでしょう（EF / DALを単体テストする必要はありません - それはマイクロソフトの仕事です！）もちろん、統合テストはまだ完全な信頼を得るために必要とされるでしょう。
別のデータベースに書き込みたい場合は、DALレイヤで行います。これは設定ファイルを使って簡単に実現できます。
私のタペンスワース
私の意見 - EFについてのあなた自身の決心をしてください、そしてそれがラウンドをやっているということに関してすべての運命と暗闇によって延期されないでください。私はそれがしばらくの間発生しそうであり、MSが来年かそこらで欠陥を解決すると思います。 Dan Simmonsによると、PIは間違いなく登場しています。
編集 ：私はちょうど私が銃に飛び乗ったことを実感しました、そして、良い政治家が実際に尋ねられた質問に答えなかったように。おっとっと。しかし、他の誰かが便利だと思ったときのためにこれを残します。
自信のない投票では、ORM / Datamapperフレームワークに適した機能や実装がわかっていると考える人の目に、いくつかの手順の誤りや欠けている機能の一覧を示します。
これらの問題のどれもあなたにとって大したことではない場合、私はあなたがそれを使用すべきでない理由はわかりません。私はそれが左右に爆破するのはバグの多い混乱であることをまだ聞いていません。それに対するすべての注意は哲学的です。私は自信がないという投票に同意することがありますが、それはあなたがすべきであるという意味ではありません。あなたがEFのしくみを好きになったのなら、それを試してください。同時に、少なくとも自信のない投票を読み、十分な情報に基づいた決定を下すために各問題についての基本的な理解を得るようにしてください。
その問題の外で、そしてあなたの質問の中心に - あなたはパフォーマンスの問題が生産に入る前にあなたが微調整をすることができるように生成されているSqlに注目し続ける必要があります。バックエンドでprocを使用している場合でも、データベースに何度もアクセスし過ぎる可能性があるシナリオを探し、それに応じてマッピングを修正したりシナリオをフェッチしたりします。