私は、自動生成されたデータベースにビジネス オブジェクトをシームレスにマップする方法を提供することで、開発時間を短縮することを提案する .NET 用のさまざまな製品を調べてきました。データ アクセス レイヤーの作成で問題が発生したことは一度もありませんが、このタイプの製品が主張する時間を本当に節約できるかどうか疑問に思っています。また、データベースを制御しすぎて、データ レベルの問題を追跡するのが難しくなるのではないかと心配しています。これらのタイプの製品は、データベースとビジネス オブジェクトの構造を変更しなければならないというすでに困難な状況で、良くなったり悪くなったりするのでしょうか?
例: Dev Express からのオブジェクト関係マッピング
本質的に、それは価値がありますか？「それ」の多くの時間、労力、および将来のバグを節約できますか?
SubSonic と EntitySpaces を使用しました。コツをつかめば、時間を節約できると思いますが、アプリが複雑になり、データ量が増えるにつれて、これらのツールでは対応できなくなる可能性があります。パフォーマンスの問題のようなものが ORM に関連しているのか、それともコードに関連しているのかを突き止めようとして時間を無駄にし始めます。ですから、あなたの質問に答えるには、場合によると思います。私はこれについて Eric に同意する傾向があります。大量のエンタープライズ アプリは汎用 ORM に適した場所ではありませんが、標準的な小規模な CRUD タイプのアプリでは、時間を節約できる可能性があります。
私は、Apache グループのiBatisがこの問題に対する優れた解決策であることを発見しました。私のチームは現在 iBatis を使用して、Java からのすべての呼び出しを MySQL バックエンドにマッピングしています。すべての SQL クエリとプロシージャがコードではなく XML ファイルにあるため、すべてを簡単に管理できるため、大きなメリットがありました。言語に関係なく、コードから SQL を分離することは大きな助けになります。
さらに、iBatis を使用すると、独自のデータ マッパーを記述して、オブジェクトとの間でデータを DB にマップできます。すべてを代行してくれる Hibernate タイプのソリューションとは対照的に、この柔軟性が必要でしたが、(IMO) 複雑なクエリを実行する能力が制限されます。
iBatis の .NET バージョンもあります。
最近、Castle Project のActiveRecordをアプリ用にセットアップしました。行くのはかなり簡単でした。それを使用して新しいアプリを作成した後、MyGeneration を使用して、ActiveRecord がかなり短時間で使用できるレガシー アプリのクラス ファイルをスクリプト化しました。NHibernate を使用してデータベースと対話しますが、NHibernate に付属するすべての xml マッピングを取り除きます。ただし、必要に応じてプロジェクトにすでに NHibernate が含まれているため、特殊なケースがある場合はその機能をフルに活用できます。見てみることをお勧めします。
ORM には多くの選択肢があります。Linq から SQL、nHibernate へ。純粋なオブジェクト データベースには db4o があります。
アプリケーションにもよりますが、大規模なエンタープライズ アプリケーションの場合、私はこのルートには行きません。データをより細かく制御する必要があります。
週末に友人とこれについて話し合っていましたが、アプリケーションの外部でデータベースにクエリを実行できるようにする必要がある場合、ストレージの使いやすさで得た利益が失われるようです。私の理解では、これらのデータベースは、オブジェクト データを非正規化された方法で保存することによって機能します。これにより、オブジェクトのセット全体をすばやく取得できますが、オブジェクト モデルに一致しない観点からデータを選択する必要がある場合、ODBMS は必要な特定のデータを取得するのに苦労する可能性があります。