118

実際のプロジェクトでどちらのテクノロジも使用したことがない人として、これら 2 つのテクノロジがどのように相互に補完し合い、機能がどの程度重複しているかを知っている人はいるでしょうか?

4

9 に答える 9

113

LINQ to SQL では、table-per-class パターンを使用する必要があります。このパターンを使用する利点は、迅速かつ簡単に実装できることと、既存のデータベース構造に基づいてドメインを実行するのにほとんど労力がかからないことです。単純なアプリケーションの場合、これは完全に受け入れられます (多くの場合、好ましいこともあります) が、より複雑なアプリケーションの場合、開発者は代わりにドメイン駆動の設計パターンを使用することを提案することがよくあります (これは NHibernate が容易にするものです)。

クラスごとのテーブル パターンの問題は、データベース構造がドメイン設計に直接影響することです。たとえば、顧客の主要な住所情報を保持する次の列を持つ Customers テーブルがあるとします。

  • 住所
  • 街
  • 州
  • ジップ

ここで、顧客の郵送先住所の列も追加する必要があるとします。そのため、次の列を Customers テーブルに追加します。

  • 郵送先住所
  • メーリングシティ
  • メーリング状態
  • 郵便番号

LINQ to SQL を使用すると、ドメイン内の Customer オブジェクトは、これらの 8 つの列のそれぞれにプロパティを持つようになります。しかし、ドメイン駆動型のデザイン パターンに従っている場合は、おそらく Address クラスを作成し、Customer クラスに 2 つの Address プロパティ (郵送先住所用と現在の住所用) を保持させることになります。

これは単純な例ですが、table-per-class パターンがどのようにやや臭いドメインにつながるかを示しています。最後に、それはあなた次第です。繰り返しますが、基本的な CRUD (作成、読み取り、更新、削除) 機能のみが必要な単純なアプリの場合、LINQ to SQL は単純であるため理想的です。しかし、個人的には NHibernate を使用するのが好きです。

編集: @lomaxx - はい、私が使用した例は単純化されており、LINQ to SQL でうまく機能するように最適化できたはずです。ポイントを家に持ち帰るために、できるだけ基本的なものにしたかったのです。ただし、データベース構造によってドメイン構造を決定することが悪い考えである、または少なくとも次善の OO 設計につながるシナリオがいくつかあるという点は変わりません。

于 2008-08-25T21:51:07.790 に答える
26

これまで見逃していた2つのポイント：

  • LINQ to SQL は、Oracle または SqlServer 以外のデータベースでは機能しません。 ただし、 devArt の dotConnect、DbLinq、Mindscape の LightSpeedおよびALinqなど、サード パーティは Oracle に対してより優れたサポートを提供しています。（私はこれらについて個人的な経験はありません）

  • Linq to NHibernateを使用すると、Nhiberate で Linq を使用できるため、使用しない理由がなくなる可能性があります。

また、Nhibernate への新しい流暢なインターフェースにより、 Nhibernate のマッピングを構成する手間が軽減されているようです。(Nhibernate の問題点の 1 つを取り除く)

アップデート

Linq to Nhiberate は、現在アルファ版の Nhiberate v3 で優れています。Nhiberate v3 は今年の終わり頃に出荷されるようです。

.net 4 の時点でのEntity Frame Workも、現実的なオプションのように見え始めています。

于 2009-01-21T15:56:43.167 に答える
23

@ケビン：あなたが提示している例の問題は、あなたが貧弱なデータベース設計を使用していることだと思います. 顧客テーブルと住所テーブルを作成し、テーブルを正規化すると思っていたでしょう。それを行うと、提案しているシナリオにLinq To SQLを間違いなく使用できます。Scott Guthrie は、Linq To SQL の使用に関する優れた一連の投稿を行っています。ぜひチェックすることを強くお勧めします。

Linq と NHibernate が互いに補完し合っているとは言えません。それは、それらが一緒に使用できることを意味するためです。これは可能ですが、どちらかを選択してそれに固執する方がはるかに優れています。

NHibernate を使用すると、非常に柔軟な方法でデータベース テーブルをドメイン オブジェクトにマップできます。また、HBL を使用してデータベースを照会することもできます。

Linq to SQL では、ドメイン オブジェクトをデータベースにマップすることもできますが、Linq クエリ構文を使用してデータベースにクエリを実行します。

ここでの主な違いは、Linq クエリ構文がコンパイラによってコンパイル時にチェックされ、クエリが有効であることを確認することです。

linq で注意すべき点は、.net 3.x でのみ使用可能であり、VS2008 でのみサポートされていることです。NHibernate は 2.0 と 3.x、および VS2005 で利用できます。

NHibernate で注意すべき点は、NHibernate はドメイン オブジェクトを生成せず、マッピング ファイルも生成しないということです。これは手動で行う必要があります。Linq
はこれを自動的に行うことができます。

于 2008-08-26T00:20:58.163 に答える
7

Fluent NHibernate は、単純な規則に基づいてマッピング ファイルを生成できます。XML 書き込みはなく、厳密に型指定されています。

私は最近、パフォーマンス上の理由から Linq To SQL から NHibernate に変更する必要があるプロジェクトに取り組みました。特に、オブジェクトを具体化する L2S の方法は、NHibernate の同上よりも遅いように見え、変更管理もかなり遅いです。また、必要のない特定のシナリオで変更管理をオフにするのは難しい場合があります。

たとえば、WCF シナリオで、DataContext から切断されたエンティティを使用する場合、変更を更新するためにそれらを DataContext に再度接続するのに多くの問題が発生する可能性があります。私はNHibernateでそれについて何の問題もありませんでした。

私が L2S から見逃しているのは、ほとんどの場合、エンティティの両端で最新の関係を維持するコード生成です。しかし、NHibernateがそれを行うためのツールもいくつかあると思います...

于 2009-04-21T19:57:43.090 に答える
5

「LINQ」の意味を明確にできますか?

LINQ はデータ アクセス テクノロジではなく、ネイティブ コンストラクトとしてクエリをサポートする単なる言語機能です。特定のインターフェイス (IQueryable など) をサポートする任意のオブジェクト モデルを照会できます。

多くの人が LINQ To SQL を LINQ と呼んでいますが、それはまったく正しくありません。Microsoft は .NET 3.5 SP1 で LINQ To Entities をリリースしました。さらに、NHibernate には LINQ インターフェイスがあるため、LINQ と NHibernate を使用してデータを取得できます。

于 2008-08-25T21:45:57.430 に答える
2

LINQ とは、LINQ to SQL を意味していると思います。LINQ 自体には、それに関連付けられた "進行中" のデータベースがないからです。これは単なるクエリ言語であり、SQL 風に見せるためにシンタック シュガーを大量に使用しています。

非常に基本的な例の中では、NHibernate と LINQ to SQL はどちらも同じ問題を解決しているように見えます。パスを取得すると、NHibernate が真にリッチなドメイン モデルを作成できる多くの機能をサポートしていることにすぐに気付くでしょう。LINQ to NHibernate プロジェクトもあり、LINQ to SQL を使用する場合とほぼ同じ方法で、LINQ を使用して NHibernate をクエリできます。

于 2008-08-25T21:49:20.650 に答える
1

まず、2 つの異なることを分けてみましょう。データベース モデリングはデータに関心があり、オブジェクト モデリングはエンティティと関係に関心があります。

Linq-to-SQL の利点は、アクティブ レコード オブジェクトとして使用できるように、データベース スキーマからクラスをすばやく生成できることです (アクティブ レコード デザイン パターンの定義を参照してください)。

Hibernate の利点は、オブジェクト モデリングとデータベース モデリングの間で柔軟性が得られることです。データベースは、たとえばパフォーマンスを考慮して、データを最もよく反映するようにモデル化できます。オブジェクト モデリングは、ドメイン駆動設計などのアプローチを使用して、ビジネス ルールの要素を最もよく反映します。(Kevin Pang のコメントを参照)

モデリングや命名規則が貧弱な従来のデータベースでは、Linq-to-SQL はこの不要な構造と名前をクラスに反映します。ただし、NHibernate はデータ マッパーを使用してこの混乱を隠すことができます。

データベースに適切な名前が付けられ、複雑さが少ない未開発のプロジェクトでは、Linq-to-SQL が適切な選択になる可能性があります。

ただし、規則としてのマッピングを使用して、同じ目的で自動マッピングで Fluent NHibernate を使用できます。この場合、XML や C# を使用したデータ マッパーについて心配する必要はなく、カスタマイズ可能な規則に基づいてエンティティからデータベース スキーマを NHibernate に生成させることができます。

一方、Linq-to-SQL の学習曲線は NHibernate よりも小さくなります。

于 2014-03-06T16:24:58.513 に答える
0

「どちらも使ったことがない人向け」と書かれているように、LINQ to SQL は使いやすいので、誰でも簡単に使用できます。プロシージャもサポートされているため、ほとんどの場合に役立ちます。複数のテーブルからデータを取得し、プロシージャを作成してそのプロシージャをデザイナにドラッグすると、すべてが作成されます。プロシージャ名が「CUSTOMER_ORDER_LINEITEM」で、これら 3 つのテーブルすべてからレコードをフェッチしてから書き込むとします。

MyDataContext db = new MyDataContext();
List<CUSTOMER_ORDER_LINEITEMResult> records = db.CUSTOMER_ORDER_LINEITEM(pram1, param2 ...).ToList<CUSTOMER_ORDER_LINEITEMResult>();

foreach ループでもレコード オブジェクトを使用できますが、これは NHibernate ではサポートされていません。

于 2011-12-20T19:01:52.893 に答える
0

または、Castle ActiveRecords プロジェクトを使用することもできます。私はそれを短期間使用して、レガシープロジェクトの新しいコードを立ち上げました。NHibernate を使用し、アクティブ レコード パターンで動作します (私が知っているその名前を考えると驚くべきことです)。私は試したことはありませんが、いったんそれを使用したら、NHibernate のサポートに直接ドロップする必要があると感じた場合、プロジェクトの一部またはすべてでそうする必要はあまりないと思います。

于 2008-08-25T22:13:14.697 に答える