9

私は、設計中の新しい Web ベースのプロジェクトにどのデータ レイヤーを使用するかを調査しており、LINQ to SQL の組み込みに非常に関心があります。その明白な単純さ、柔軟性、およびデザイナーのサポートは本当に魅力的であり、SQL Server への暗黙の結び付きは問題ありません。

ただし、LINQ to SQL は ADO.NET チームに渡されたため、Entity Framework の後ろに座ることになることが最近発表されました ( http://blogs.msdn.com/adonet/archive/2008/10 /29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx )。もちろん、将来サポートされる予定ですが、さらに多くの開発作業が行われる可能性は低いです。

これを念頭に置いて、私のプロジェクトにこのテクノロジを使用することをお勧めしますか?それとも、代替の ORM (nHibernate?) を選択するか、汎用 DAL を手動でコーディングする価値がありますか?

プロジェクト自体は ASP.NET および SQL Server 2005/2008 ベースで、まだベータ版ですが、MVC を使用する可能性があります。これは個人的なプロジェクトであり、データベースはそれほど複雑ではなく、主に .NET の将来の技術を見るためのプロトタイプとして使用されます。ただし、今後のプロジェクトは、このプロジェクトから学んだことをベースにしているので、私が行う選択は、今後のより大きなソリューションに影響を与えます。

はい、いずれにせよ、Microsoft はおそらくまったく新しいデータ アクセス テクノロジを明日発表するでしょう! ;)

4

11 に答える 11

7

NHibernate を選択します。概念または実際の ORM として、しばらくの間存続します。したがって、両方を学ぶことは有益です。

于 2008-12-24T14:16:56.580 に答える
4

さて、それはすでにここでの回答（いくつかの興味深い観点も）でほとんどカバーされていますが、とにかくもう一度言います。

LINQ to SQL（L2S）は非常に用途が広いですが、私の観点からは少し基本的すぎると感じます。ほとんどの場合、それは単純なことをするのに良い仕事をします、しかしあなたがそれをもう少し尋ねるとすぐにそれは高価になります。これは決して悪いことではありません。実際、LINQtoSQLはEntityFrameworkをうまく補完していると思います。

たとえば、LinqDataSourceを使用した自動ページングを取り上げます。Order By / Group Byを指定しない場合は、非常に経済的です。順序付けまたはグループ化をミックスに入れると、パフォーマンスが急上昇し始めます（非常におしゃべりになります）。次に、独自のページング実装を作成する必要があります（これはそれほど難しくはありませんが、認めます）。

生成されたT-SQLの品質（L2SはSQL Serverのクエリ用に特別に構築されているため）および概念的および対称的に、LINQの多くの点で、L2SがEntityFrameworkよりも優れていることを最初に認めます。 SQLはEFに似ていますが、壁にぶつかるのは、ニーズの拡大と、より複雑な実装要件への配慮です。

ゼロから始めて、個人的な開発時間を費やすことを選択した場合は、EntityFrameworkを選択します。興味深いことに、私は現在L2Sを使用するプロジェクトに取り組んでおり、それは重い負荷を処理するためにスケーリングするように設計されていますが、より「創造的な」要件のいくつかに達すると、SQLMetalを拡張することを余儀なくされることがよくあります（例えば、多対多の関係）。

だから..要するに..私はそれにアプローチします：

a）LINQ to SQLを（MicrosoftのORMパターンとテクノロジの）イントロとして学びます。これにより、Entity Frameworkと共有される基本のほとんどと、LINQスタイルクエリのテイスト（持っている場合は習得したテイスト）に慣れることができます。 T-SQLの背景）

b）LINQ to SQLを理解したら、Entity Frameworkにジャンプして、追加の利点（eSQLなど）を学ぶことをお勧めします。

c）両方に概念実証プロジェクトを実装し、結果を比較します。

于 2009-01-06T07:01:01.340 に答える
4

IMO、この全体は本当にバランスが取れていませんでした。

Microsoft は、LINQ to SQL がなくなるとは言っていません。彼らは、それが Entity Framework にマージされることをさらに示しました。

LINQ to SQL の多くが Entity Framework に組み込まれることがわかっているので、ソリューションとして Entity Framework を使用することに集中します。

とはいえ、今のところそれほど違いはありません。最大の不満は、Entity Framework が軽量でないことです。ティア間の分離が良好である限り、それは本当に重要ですか?

于 2008-12-24T15:00:16.833 に答える
2

このサイトはLINQtoSQLを使用して構築されていることに注意してください。ジェフは、StackOverflowポッドキャストでそれを使用することについて話しました。

于 2008-12-24T15:38:59.457 に答える
2

L2S は素晴らしいテクノロジであり、古い ADO に戻ることはありません。

しかし、おっしゃる通り、L2E には後れを取っています。L2S は非常に優れた機能を備えており、私はこれを使って数多くのアプリケーションを作成してきましたが、非常に満足しています。しかし、これ以上進まないと聞いて、わき腹にナイフを突き立てた。そこで私は L2E を調べに行きましたが、SQL の相互作用に関してはほぼ同じであり、多くの点でより簡単であり、関係処理がより効率的であることは言うまでもありません。このような類似性により、L2E を選択するのは理にかなっているように思えます。

切り替えと 2 つのフレームワークの比較に関する記事を書きました: http://naspinski.net/post/Getting-started-with-Linq-To-Entities.aspx

これらのフレームワークのいずれかに満足することはほぼ保証できます。これらは開発にとって天の恵みです。シンプルさとエラー回避は他の追随を許しません。L2S よりも積極的に開発されるため、個人的には L2E に傾倒します。

于 2009-01-06T06:40:29.697 に答える
2

L2S は、私見ですが、このままで完全に問題なく、あなたが言ったように、どこにも行きません。私が勤務している企業では、データ アクセスの標準として、5 ユーザーの小さなニッチ アプリから 1000 ユーザー以上のエンタープライズ アプリまで、あらゆるものに使用して素晴らしい結果を出しています。

于 2008-12-24T14:25:47.810 に答える
2

サブソニックをチェックしてください：

http://subsonicproject.com/

于 2008-12-24T14:28:36.260 に答える
2

私は現在の Web プロジェクトで L2S を多用していますが、最大の問題は、n 層データベース開発を行うための最良の方法に関するドキュメントの矛盾だと思います。

何よりもまず、事前に理解しておく必要があるのは、DataContext オブジェクトは、作業単位である期間だけ持続することを意図していることです。さらに、DataContext はステートレスです。これら 2 つの原則を理解すると、n 層環境での LINQ の使用がうまく機能し始めます。

一方、Linq を使用するための非常に非常に悪い方法を推奨する人が多数いることがわかります。DataContext を静的にしないでください。これは私が早い段階で犯した間違いであり、機能しなくなるまで驚異的に機能しました。その後、異なるセッション間で誤ったデータが交差するなど、まったく恐ろしいものでした。簡単に言えば、これはおそらく最大のものですLinq を使用することの最も巨大な禁止事項であり、すべてのドキュメントで大きな太字で記述する必要があります。また、セッション変数で DataContext を永続化することも同様に悪い考えです。

私が LINQ で遭遇した唯一の大きな問題は、切断された更新を行うときに、呼び出し全体で同じ DataContext を使用する必要があることです。例えば：

    public static void UpdateUser(UserLibrary.User user) {
        using (UserLibraryDataContext dc = new UserLibraryDataContext(_conStr))
        {
            UserLibrary.User newUser = (from user2 in dc.Users where user2.UserID == user.UserID select user2).FirstOrDefault();
            newUser.Email = user.Email;
            newUser.FirstName = user.FirstName;
            newUser.LastName = user.LastName;
            dc.SubmitChanges();
        }

お勧めしませんが、DataContext.ObjectTrackingEnabled = false を設定しない限り、別のデータコンテキストで作成された User を単純に渡して Update が機能することを期待することはできません。代わりに、同じ DataContext 内で既存のオブジェクトを取得し、その値を更新してから、その変更を送信する必要があります。同様のタスクをすべて同じ DataContext 内に保持します。

私は L2S をお勧めしますが、いくつかの問題 (上記のような) を克服すれば、それは優れたテクノロジであり、間違いなく時間の節約になります。ただし、簡単に変更できるように、DAL の周りに薄いラッパーを作成することをお勧めします。(経済的な理由から) コードの一部を OpenAccess ORM -> MySql を使用してデータ アクセスの一部に移植することを検討しています。レイヤーが適切に定義されていれば、この作業は数時間で済みます。

于 2009-05-05T18:30:28.897 に答える
2

EDMの目標は、 LINQ to SQL の目標よりもはるかに大きいと思います。単純な ORM を探しているなら、LINQ to SQL が最適だと思います。リレーショナル構造を持ち、その他の高度なマッピングを行うデータベース テーブルに関連する継承構造を持つクラスを構築する予定がある場合は、EDM を選択することをお勧めします。

于 2008-12-24T14:30:35.897 に答える
1

アプリを適切に設計し、データアクセス層を適切に分離する場合は、L2Sを使用する必要があります。私があなたの投稿から推測したところ、それは大きなプロジェクトではないので、L2Sはあなたの要件をうまく満たすはずですが、単純な古いADO.NETはただのノーノーであり、EntityFrameworkは...ただそれを使用しないでください、 わかった？とにかく、DALをうまく分離すれば、プロジェクトが成長した場合、将来的にL2Sを別のものに交換することができます。そして、L2Sがどこにも行かなくても、どこにも行かない。MSはそれに投資することをやめました、しかしそれは非推奨になるか何かになることはないでしょう、それでそれはまだ安全な投資です。または、シンプルで成熟したNHibernateを評価する必要があります。

于 2009-01-06T06:51:17.020 に答える
1

私はエコーストームに同意します。L2S はあなたのニーズに適しています。そして、それは非常に簡単に操作できます...

于 2008-12-24T15:01:15.443 に答える