Hibernate と LINQ to SQL の比較

https://stackoverflow.com/questions/26971

09-06-2019
|

質問

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

解決

LINQ to SQL では、クラスごとのテーブルパターンの使用が強制されます。このパターンを使用する利点は、実装が迅速かつ簡単で、既存のデータベース構造に基づいてドメインを実行するのにほとんど労力がかからないことです。単純なアプリケーションの場合、これは完全に許容できます (そして多くの場合、むしろ望ましい) が、より複雑なアプリケーションの場合、開発者は多くの場合、ドメイン駆動設計代わりにパターンを使用します (これは NHibernate が容易にするものです)。

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

住所
市
州
ジップ

ここで、顧客のメールアドレスの列も追加したいと考えて、Customers テーブルに次の列を追加するとします。

郵送先住所
郵送都市
郵送状態
郵便郵便

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

これは単純な例ですが、クラスごとのテーブルパターンがどのようにしてやや臭いドメインにつながる可能性があるかを示しています。結局のところ、それはあなた次第です。繰り返しになりますが、基本的な CRUD (作成、読み取り、更新、削除) 機能だけを必要とする単純なアプリの場合、シンプルさの点で LINQ to SQL が最適です。しかし、個人的には NHibernate を使用するのが好きです。NHibernate を使用するとドメインがよりクリーンになるためです。

編集：@lomaxx - はい、私が使用した例は単純であり、LINQ to SQL で適切に動作するように最適化できたはずです。要点を理解するために、できるだけ基本的な内容に留めておきたいと思いました。ただし、データベース構造によってドメイン構造を決定するのは悪い考えであるか、少なくとも次善の OO 設計につながるシナリオがいくつかあるという点は変わりません。

他のヒント

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

LINQからSQLは、SQLServer以外のOracleまたはデータベースでは機能しません。ただし、サードパーティは Oracle に対してより優れたサポートを提供しています。 devArt の dotConnect, DbLinq, MindscapeのLightSpeed そして Aリンク. 。(私にはこれらに関する個人的な経験はありません)
Hibernate へのリンク nhiberateでlinqを使用してもらうことができるので、使用しない理由を削除する可能性があります。

また新しい Nhibernate への流暢なインターフェース Nhibernate のマッピングの設定が楽になるようです。(Nhibernate の問題点の 1 つを取り除く)

アップデート

Linq to Nhiberate は、現在リリースされている Nhiberate v3 の方が優れています。アルファ. 。Nhiberate v3 は今年末に出荷される可能性があるようです。

のエンティティフレームワーク .net 4 の時点では、現実的なオプションのように見え始めています。

@ケビン:あなたが提示している例の問題は、不適切なデータベース設計を使用していることだと思います。顧客テーブルと住所テーブルを作成し、それらのテーブルを正規化すると思います。そうすれば、提案しているシナリオに間違いなく Linq To SQL を使用できます。スコット・ガスリーは、 Linq To SQL の使用に関する素晴らしい投稿シリーズぜひチェックしてみてください。

Linq と NHibernate が相互に補完しているとは言えないと思います。それは、一緒に使用できることを意味するからです。それは可能ですが、どちらかを選択して使い続ける方がずっと良いでしょう。

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

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

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

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

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

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

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

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

L2S で欠けているのは主に、エンティティの両端で関係を最新の状態に保つコード生成です。しかし、それを行うための NHibernate 用のツールもいくつかあると思います...

「LINQ」が何を意味するのか説明していただけますか?

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

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

LINQ とは、LINQ to SQL のことを指しているのだと思います。LINQ 自体には、関連付けられたデータベースが「実行中」ではないからです。これは、SQL っぽく見せるために大量の構文糖を搭載した単なるクエリ言語です。

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

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

Linq-to SQL の利点は、データベーススキーマからクラスを迅速に生成して、アクティブレコードオブジェクトとして使用できることです (アクティブレコードの設計パターン定義を参照)。

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

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

データベースの命名が適切で複雑さが低いグリーンフィールドプロジェクトでは、Linq-to-SQL が適切な選択肢になる可能性があります。

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

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

または、Castle ActiveRecords プロジェクトを使用することもできます。私はこれを、レガシープロジェクトの新しいコードを強化するために短期間使用してきました。これは NHibernate を使用し、アクティブレコードパターンで動作します (私が知っているその名前を考えると驚きです)。私は試していませんが、一度使ってしまえば、NHibernate サポートに直接移行する必要があると感じた場合、プロジェクトの一部または全体に対してそうするのはそれほど難しくないと思います。

「どちらかを使用していない人のために」と書いたように、linqからSQLを使用するのは簡単であるため、誰でも簡単に使用できる手順もサポートできます。複数のテーブルからデータを取得し、手順を作成してデザイナーにその手順をドラッグすると、すべてを作成します。

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

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

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow