[解決済み] NHibernateとLINQ to SQLの比較

質問

実際のプロジェクトでどちらの技術も使ったことがない者として、この 2 つがどのようにお互いを補完し、どの程度機能が重複しているかを知っている人がいたら教えてください。

どのように解決するのですか?

LINQ to SQL では、テーブル パークラス パターンを使用することを強制されます。 このパターンを使用する利点は、すばやく簡単に実装でき、既存のデータベース構造に基づいてドメインを実行するのに非常に労力がかからないということです。 単純なアプリケーションであれば、これはまったく問題ありませんが (場合によっては望ましいことさえあります)、 より複雑なアプリケーションの場合、開発者はしばしば ドメイン駆動設計 パターンを使用することをお勧めします (これは NHibernate が促進するものです)。

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

• 住所（StreetAddress
• 市町村
• 州
• 郵便番号

さて、顧客の郵送先住所のカラムも追加したいので、Customersテーブルに次のカラムを追加するとします。

• 郵送先住所（MailingStreetAddress
• 郵送先住所
• 郵送先住所
• 郵送先郵便番号

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

これは単純な例ですが、テーブル・パー・クラス・パターンがいかに胡散臭いドメインになり得るかを示しています。 結局のところ、あなた次第なのです。 繰り返しになりますが、基本的な CRUD (作成、読み取り、更新、削除) 機能が必要なだけの単純なアプリの場合、シンプルであるため LINQ to SQL が理想的です。 しかし、個人的には、NHibernateを使用するのが好きです。なぜなら、よりクリーンなドメインが容易になるからです。

編集 lomaxx - はい、私が使用した例は単純で、LINQ to SQL でうまく動作するように最適化することができました。 私は、ポイントを強調するために、できるだけ基本的なものを維持したかったのです。 しかし、データベース構造がドメイン構造を決定することが悪い考えである、あるいは少なくとも最適でない OO デザインにつながるようなシナリオがいくつかあるという点は変わりません。