私の場合、現在の答えは次のとおりです。いいえ、データベースモデルとオブジェクトモデルが同期していない場合、NHibernateは苦痛であるため、iBatisを使用します。データベースを完全に制御できないと、多くの作業が必要になります。
なぜ私は尋ねるのですか？
まず第一に、私はNHibernateを使用したことはありません。私はそれを表面から知っています。レガシーデータベースに対するiBatisの利点について読みました。
2番目：最近、Hibernateで作業している人と話し合いました（jep、Hibernateの前に「N」を付けないでください）。彼は、ORMフレームワークは現在かなり高度であり、Hibernateを提唱していると私に言いました。私はNHibernateに興味がなかったので、最近の開発を追跡していませんでした。
多分私は私の答えを再考する時が来たのか、そうでないのか？
iBatisは確かにオブジェクトをレガシーデータベースシステムにマッピングするのは簡単です。
最近では、NHibernate 1.2および2.0に、iBatisを再考させる可能性のある機能セットがあります。
NHibernateは、古いデータベースで頻繁に発生する可能性のある複合キーを処理します。これらのキーは、常に快適に動作するとは限りませんが、サポートはあります。
NHibernateは、エンティティ、およびデータベースビューでのCRUD操作にストアドプロシージャを利用できます。
コレクションは、カスタムストアドプロシージャまたはSQLクエリにすることができます。外部キー関係が反対側の主キーに直接マップされていない場合、コレクションはproperty-ref属性を使用できます。
これらの機能の一部は、nhibernateのパフォーマンス/パワーを損なう可能性があります。つまり、property-refを使用した遅延読み込みは機能しません（まったく機能しませんか？）が、ほとんどの場合、これには理由があります。
その他のポイント:(これは実際にはレガシーデータベースとは関係ありませんが、テクノロジーの選択を決定するのに役立ちます）
Nhibernateコミュニティは、iBatisよりもはるかに豊富に見えます。私は両方のリストに載っていて、NHibernateのサポート量はiBatisグループと比較してかなり大きいです。したがって、サポートはより簡単になるはずです。
また、NHibernate用のcontrib/3サードパーティツールの数も増えています。いくつか例を挙げると、NHibernate Profiler、Nhibernate Query Analyzer、NHibernate Contrib、FluentNHibernateなどがあります。
おそらく、iBatisが現在持っていると信じている利点を拡張することができます。NHibernateは確かに最近非常に活発であり、多くの新機能を獲得しました。それらの多くは、レガシー/変更が難しいスキーマを支援します。
そして、質問に答えるために、はい、ひどい関係、複合キー、壊れた関係を持つレガシーデータベースでNHibernateを使用します。iBatisに基づく少量のコードもまだあります。ただし、これ以上iBatisコードを作成することはありません。
はい、NHibernate を検討してください。それは理由でゴールドスタンダードです。iBATIS はクレイジーなマッピングの可能性をサポートしていると聞いたことがありますが、NHibernate の IUserType を使用すると、本当に奇妙な列でさえ、何でもマッピングできます。
@Ahmad、ORMの全体的なポイントは、オブジェクトとスキーマの間の密結合を防ぐことです。この問題がある場合は、間違っています。
また、NHibernate には、カスタム クエリ、式のプロパティ、およびストアド プロシージャのオプションが多数用意されています。HQL は非常に強力で、Criteria は柔軟です。
少なくともNHibernateをスパイクしないと、クライアントに不利益をもたらすと思います。
既存のアプリケーションで nHibernate を使用しています。私はすべての新しい開発に使用しています。既存のものを移植するつもりはありません。説得力のある理由はありませんが、プロジェクトの新しいものにはうまく機能します。
コードを移植する場合は、ドメイン モデルにより適合するようにデータベースを変更できるはずです。大きな影響はありません (データベースのリークの程度、つまりデータベースにアクセスするユーザーによって異なります)。ただし、ドメイン モデルを変更すると、アプリケーションに影響が及びます。