2009-05-23 16 views
3

私は、nHibernateと手書きADO.NET /ストアドプロシージャの使用の間を行き来しています。手書きADO/SprocsとnHibernateの比較

私はデータベースのテーブルをマッピングする単純なクラスを吐き出し、自分のデータレイヤ用のストアドプロシージャと、データレイヤを呼び出してオブジェクトを返すシンビジネスロジックレイヤをラップするテンプレートを使ってcodesmithを使用しています(1つのオブジェクトまたはコレクション)。

このアプリケーションは、オンラインコミュニティ(基本的にはフォーラム)で使用されるWebアプリケーションです。

現在、夏のnhibernateの動画を見ています。

nHibernateを使用すると、私の人生は楽になりますか?データベーススキーマの更新は簡単になりますか?パフォーマンスにはどのような影響がありますか?

nhibernateを設定して、それが最適な頭痛を発揮していることを確認していますか?

私は複雑で深いオブジェクトモデルを望んでいません。テーブルをマップするクラスと、外部キーを持つ他のテーブルからデータをフェッチする方法が必要です。私は非常に複雑なOOPモデルを望んでいません。

答えて

2

NHibernateは、特にシンプルなモデルの場合、非常にうまく動作します。それはあなたの人生をはるかに容易にし、学ぶのが難しくありません。 XMLマッピングを使うのではなく、 "Fluent NHibernate"を見てみると、はるかに簡単です。

+0

同意すると、オブジェクト属性のマッピングはXMLマッピングよりもはるかに簡単です。 XMLマッピングが必要な唯一の時間は、データオブジェクトが制限されていないか、コンパイルされているかどうかです。 – Soviut

+0

Errr ...流行NHIbernateは属性マッピングではありません。 wiki.fluentnhibernate.org – jfar

4

NHibernateはあなたの人生を確実に楽にすることができます。 ORMを使用する場合、ビジネスモデルの変更に合わせてデータベーススキーマのリファクタリングを妨げるストアドプロシージャのAPIを使用しないため、データベーススキーマの更新は確実に簡単になります。

ORマッパーは、提供するLOTがあり、開発者コミュニティのかなりの部分、およびほぼすべてのDBAコミュニティによって誤解されています。

一般に、ストアドプロシージャは、出力を変更しない限り、ストアドプロシージャを自由に書き換えることができるため、DBAにパフォーマンスをチューニングするためのオプションを提供します。しかし、私の経験では、結果として生じる可能性のある他の問題のためにストアドプロシージャが書き直されることはほとんどありません(つまり、新しいバージョンのソフトウェアのデプロイメントが実行されると、変更されたバージョンの既存のprocsは、 DBAによって利益が無効になり、保守や予期しないパフォーマンスの問題が発生する)。

もう1つの重大な誤解(これは主にSQL Serverのキャンプからのものです...)ストアドプロシージャだけがコンパイル可能であり、実行プランがキャッシュされることです。 SQL Serverに関する限り、パラメータ化されたクエリはコンパイルでき、おそらくキャッシュされます。

ORマッパーのメリットは、ストアドプロシージャで適応性があるということです。ストアドプロシージャでは、クエリが実行されるときにコンテキストのニュアンスに関係なく使用される単一のステートメントを記述します。 LINQ to SQLは、これまでに見た中で最も効率的なクエリを生成する驚くべき能力を備えており、しばしば深刻なループのためにDBAをスローします。私はL2Sによって生成されたDBAのクエリを示していますが、これはサブクエリとすぐに嘲笑された異例のものでいっぱいです。しかし、課題を考えると、おそらく優れていると思われるDBAによって作成されたクエリのパフォーマンス(つまり物理的な読み込み)は著しく劣っていました(L2Sの場合は30物理読み取り、DBAの場合は400物理読み取り)。)

ORAの動的SQLを生成するため、これらのクエリを最適化する方法がないため、DBAに関しては別の嫌悪者です。これとは逆に(これはSQL Serverに限定されています)、SQL Serverは多数の最適化パス(水平および垂直のテーブル分割、任意のテーブルまたはビューのディスク全体にわたる物理ファイルの分散、インデックスなど)を提供しますクエリを変更する必要が生じる前に取られることが必要です。クエリを変更する必要がある場合でも、SQL Server 2005以降では、プランガイドと呼ばれるものが用意されています。これにより、クエリ(ストアドプロシージャ、ストリッジSQLなど)を適切にチューニングできます。クエリをチューニングするだけでは不十分な場合は、特定のクエリを完全な置換クエリに一致させることができ、DBAは必要に応じてクエリをチューニングできます(最後の手段として)。

ORマッパーを使用することによって得られる多くの利点があります.Hibernateは最高の無料のものの1つです(LLBLGenもとてもいいですが無料です)。LINQ to SqlとEntity Frameworkは、間もなくL2Sは.NET 4.0フレームワークからEF 4.0に置き換えられる予定です... ORMを採用する上で最大のハードルはORM製品自体ではなく、パフォーマンス。 ORAがDBAの最適化パスのコストをかけずに効率を高め、メンテナンスコストを削減できることは、最大のハードルは、通常、あなたのDBAを納得させることです。

関連する問題