特に Alt.Net の人々からは、Linq To Entities に対してかなりの敵意があるように見えることに気付きました。「ドラッグ アンド ドロップ」プログラミングへの抵抗は理解していますが、私の理解では、Linq To Entities はそれを必要としません。
現在、Linq to SQL を使用しており、DBML ドキュメントを使用してそれを定義しています (テーブルが 10 個以上になると、デザイナーはほとんど役に立ちません)。
では、同じアプローチが Linq To Entities で機能しないのはなぜでしょうか?
実際、一度掘り下げてみると、LTE はエンタープライズ レベルのフレームワークにはまったく役に立ちません。(LTS においても) 継承のサポートがほとんどないという事実は、多くの冗長なコードを生み出します。また、ファイルの代わりに属性を介して実際にマッピングを定義できるため、LTS (Linq to SQL) に戻る予定です。LTE は外部ファイルでのみ機能します。
それ自体が嫌いというわけではないと思います。人々がそれの実装を好まないというだけです。
http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/
Linq から Entity への嫌悪感は当然のことです。この製品は、下手なデモ GU がブログで使用するよりも複雑な目的に失敗します。EF はまだ準備万端ではありません。Microsoft は、風が吹くたびにデータ パラダイムを変更しているように見える .BLOAT の世界でデータを正しく取得することができません。FoxPro は、同じ基本的なデータ コアを使用して 20 年間使用されています。SQL Server が VFP データ テクノロジの多くを使用していることを考えると、おそらく MSFT は、機能するものからデータの操作とデータ中心の言語について少し学ぶことができます。
私は、Linq to Entities の原則、および Entity Framework 全般について非常に納得していますが、現在の具体化については懸念があります。ただし、自己教育的で非常に小さな方法以外で使用していないことを率直に認めます. 柔軟性のレベルはまだそこに達していないようですが、私はそれが来ると確信しています. MS テクノロジ エバンジェリストの 1 人 (素晴らしい役職) から、EF は MS の将来の戦略的選択肢であると言われました。これが事実であると仮定すると、私はこの分野で物事が良くなっているのを見ることができます.
「二位」の敵意も少しあるかもしれません。MS はL2E で市場に出るのが非常に遅く、私自身が ORM に興味を持ったのは 3 年ほど前で、現時点では MS は見当たりませんでした。
私たちの多くはすでに別の ORM (NHibernate など) の学習に時間を費やしており、利用可能な特定のレベルとタイプの機能に慣れていますが、これは L2E ではまだ明らかではありません。
この「第 2 位」の敵意は、正直なところ、古いニュースではありません。なぜ MS が、既に導入されているソリューションのサポートにこれ以上時間を費やさないのかわかりません。NAnt -> MSBuild および NUnit -> MsTest でこれをすべて見てきました。 、常に独自のソリューションを作成するのではなく、より優れた成熟したソリューションの1つを受け入れ、それをサポートするよう努めれば、全員の時間と労力を大幅に節約できます.
TPT 継承の LTE 実装は犯罪にほかならないことを付け加えておきます。ここで私の質問を参照してください。
そして、私がそうしている間、出版されている多くの EF 評論家は、少なくとも部分的に共謀していると信じています。基本型のクエリに対して警告する EF に関する公開資料をまだ見つけていません。私が持っているモデルで試してみると、SQL Server は単純に例外をあきらめてしまいます。
SQL ステートメントの一部のネストが深すぎます。クエリを書き直すか、小さなクエリに分割します。
クエリを書き直したいのですが、LTE のおかげでその負担が軽減されました。ありがとうございます(^-^)