私は新しいアプリケーションの設計を始めていますが、Linq2SQL または Linq2Entities に関する人々の意見と、迅速な開発のためのより優れたテクノロジであると彼らが感じていることを知りたいと思っています。
また、ADO.net データ サービスに関する調査も行っています。
bleevo
質問する
2315 次
11 に答える
13
はい、Slaceに同意しました。
選択するフレームワークに注意して、すべてのニーズを満たすようにしてください。
たとえば、私は最近、主に次の理由により、私のニーズを促進しなかったため、過去2週間にわたってかなりしっかりと作業した後、作業プロジェクトからEntityFrameworkを削除しました。
- Linq to Entitiesで実行できないこと（.net列挙型（grr）へのマッピングや、関数を呼び出してlinqクエリステートメントを使いこなそうとすると、ほぼすべてのターンで「NotSupportedException」を受け取ることの悪化など）またはメソッド呼び出し（リンクを参照））。
- ネイティブの遅延読み込みの欠如（これを容易にするEF Lazy LoadGenなどのツールがあることは理解していますが、組み込みたいものではありませんでした）。
それ以外は、コマンドとフレームワークは単純明快に見えました。EFを使用した理由は次のとおりです。
- EFは企業開発の対象であり、L2Sは愛好家向けであり、限られたフレームワークであると私は信じていました。しかし、さらに理解を深め、個人的には、EFではL2Sではできなかったことが何も必要ないので、L2Sには満足しています。特にスタックオーバーフローに適している場合は、スケーラビリティと効率がカバーされます。
- 複数のDBMSのオプション'（ただし、これが実際に動作するのはまだわかりません）
- MicrosoftがLinqへのサポートと投資をSQLに落としていると噂されていました。
- 既存のスキーマモデル（Linq to SQLで強制的に実行する）を削除せずに、EF.edmx内でテーブルとDBの変更を更新できるという事実が気に入っています。ただし、L2Sスキーマ（.dbml）のプロパティをカスタマイズしていない限り、それほど煩わしいことではありません。
さらに読む（別のSO投稿）：
LINQ to SQLはデッドオアアライブですか？
EFを選びたいのですが、L2SとEFのデバークルをどうすればよいかわかりません。また、L2Sが本当に死んだアヒルの場合は、肩をすくめてください。確かにEFでの私の主な不満は、NotSupportedExceptionです-これを取得せずにlinqでメソッド呼び出しを実行できれば、遅延読み込みを回避できます...
于 2008-12-14T05:01:56.693 に答える
8
次の設計要件を満たしている場合、私は LINQ to SQL の大ファンです。
- DB エンジンとしての MS SQL Server
- RAD開発
- 必要なのは 1 - 1 クラス マッピングだけです
私はEntity Frameworkで多くの作業を行ったわけではありませんが、私が知っていることと行ったことから、LINQ to SQLが使用するのと同じデータベースから生成された場合、パフォーマンスが良くないということです。
パフォーマンスが低いのは Entity Framework の性質によるもので、使用しているデータベース サーバーに特定のプロバイダーではなく ADO を使用します。
于 2008-12-13T03:18:09.950 に答える
3
ADO.NET Data Services（おっしゃるとおり）で使用する場合、EntityFrameworkはそのままで機能します。（ADO.NET Data Servicesを介して）LINQ-to-SQLを使用してデータを更新する場合は、を実装するためにいくつかの作業を行う必要がありますIUpdatable。幸いなことに、私は今週そのことについてブログを書いています。
両者の間の私の全体的な考えはここでカバーされていますが、それ以来私は少し和らぎました、ここを見てください。
基本的に、現時点ではLINQ-to-SQLを好みますが、次のバージョンではEFがより使いやすくなると期待しています。したがって、なぜ私はLINQ-to-SQLをADO.NETDataServicesで動作させるために取り組んでいます。
于 2008-12-13T09:34:09.580 に答える
3
シンプルから適度なデータベース スキーマの場合、Linq2SQL は非常にうまく機能し、セットアップと使用がより簡単です。これは、検証と承認/監査をサポートするために、部分クラスを介していくつかの小さな調整を加えて ORM に使用するものです。DBML デザイナーを使用して、テーブル/リレーションを追加します。DataContext を変更して抽象化し、監査と承認のためのフックを提供するテーブル値関数/ストアド プロシージャ (メソッドとしてデータ コンテキストにマップされる) の実装を提供できる具体的な実装を構築します。OnValidate と OnLoad のエンティティ クラスに部分メソッドを実装して、テーブル レベルで検証と承認の両方を行います。私が必要としているのはこれでほぼすべてだと思います。最近、私は
于 2008-12-13T03:16:39.547 に答える
2
Linq 2 Sql は優れた選択肢だと思います。いくつかのポイント:
- とても高速です。L2S ベータ版の期間にRico Mariani の Performance Tidbitsでブログ投稿を読んだことを覚えています。彼は、以前の単純な ADO.Net とほぼ同じ速度であると測定しましたが、それはベータ版でした。
- 必要に応じて、linq クエリを実行するだけでなく、ストアド プロシージャと古き良き sql を使用して、データからオブジェクトへのマッピングを実行することもできます。
- Stackoverflow が L2S を使用しているという事実は、大規模な Web サイトで動作できることを証明しています。
- Entity Framework よりもはるかに軽量であり、必要なものに応じて良くも悪くもなります。一般に、ニーズがそれほど高度でない場合は、通常、問題をすぐに回避できます。
于 2008-12-13T12:16:34.010 に答える
1
私の投票は Linq-to-SQL に行きます。これは、迅速な開発シナリオに適合します。始めやすく、使いやすい。さらに、Linq 式から適切で効率的な SQL クエリを生成します。
Linq-to-Entities は不格好です。L2S とは別に設定することになっている「高度な」機能を使用しようとすると、XML エディターを使用して EDMX モデル ファイルの編集を開始する必要があります (すぐに実行します)。 Microsoft が推奨する唯一の回避策/解決策は、XML エディターを使用して EDMX を手動でクランクすることです)。その上、非常に質の悪い/非効率的な SQL クエリを生成する傾向があります。
Microsoft は、Entity Framework の次のバージョンはより良くなり、L2S のすべての利点をサポートすると述べています。ただし、次のバージョンはすぐにはリリースされないため、それまでは L2S が最善の策です。
于 2008-12-13T03:27:13.067 に答える
0
これはかなり古い質問ですが、上位投票の回答のLinqToSqlチアリーダーが私に関係しています。LinqToSqlには重大な欠点があります。
Visual Studio 2008 LinqToSql O /RDesignerを使用しないでください
とはいえ、EntityFrameworkにも重大な欠点があります。
利用できるはるかに優れたオプションがあります（NHibernateは現在すべての周りの最良のオプションです）。
于 2009-08-29T11:57:56.847 に答える
0
あなたのほうが良いと断言できる人は誰もいません。
どちらの技術にも問題があります (NHibernate にも問題があります)。
私はLinq-to-SQLを使用していますが、それにとても満足しています。私の意見では、Linq-to-SQL の問題は EF よりも少ないです ^_^。
于 2008-12-13T07:54:12.357 に答える
0
アップデートを試みるまで、L2S は素晴らしいと思っていました。それからそれは哀れでした。私が他のことをしている間、私の同僚はこの仕事のほとんどをしていました。彼は EF について、また過剰な構成可能性によって使用が面倒になった方法について話しました。
私たちは MSSQL をターゲットにしており、それは変わらないので、彼はデータベース プロバイダーの抽象化に関するすべてをハッキングできるのではないかと提案しました。しばらくして、彼はそれは良い提案だと私に言いました。
この回答が反対票を投じられた根拠について興味があります。実際の経験を説明し、代替戦略とそのアプローチの相対的な成功について説明します。反対票を投じるのは、誤解を招く、事実に反する、または単純なトローリングの回答です。
たまたま、私は EF と L2S の全体について自分の立場を変えましたが、自分とは異なる意見を表明しているという理由だけで何かに反対票を投じることは幼稚であり、StackOverflow の精神に完全に反するという事実は変わりません。
于 2009-02-03T14:57:25.587 に答える
0
ORM については、Microsoft 以外のソリューションを検討することをお勧めします。nHibernate は、これら両方のフレームワークの優れた機能に加えて、さらに優れたソリューションを備えた優れたソリューションです。はい、より急な学習曲線ですが、流暢な nHibernate がそれを助けます。努力する価値は十分にあります。
于 2008-12-13T06:11:06.777 に答える
-1
Linq to SQL は、Microsoft がもう更新しないため、最近行き止まりになっています。自分のプロジェクトで少しの間使用しましたが、実際の SQL に比べて性能が劣っていることに気付きました。もちろん、短期的には実行する方が簡単に思えるかもしれませんが、アプリケーションの開発サイクルの過程で、SQL のパワーをより楽しんでいることがわかるでしょう。
LINQ TO SQL は、フレームワークの抽象化レイヤーに大きく依存していて、SQL を追求する時間/エネルギー/欲求がない人にのみ採用されるべきだと思います。
もう 1 つ覚えておくべきことは、SQL とアプリケーションの間の追加レイヤーには独自のコストがかかるということです。速度の違いは、簡単に気付くものではありませんが、そこにあります。
個人的には、始めたばかりの人はすぐに SQL に移行し、LINQ to SQL に失敗することをお勧めします。
于 2008-12-13T05:01:17.633 に答える