私は、ビジネスオブジェクトが自動的に生成されたデータベースにシームレスにマップする方法を提供することにより、開発時間を短縮することを提案する.NET用のいくつかの製品を見てきました。私はデータアクセスレイヤーを書くのに問題は一度もありませんでしたが、このタイプの製品が本当に主張する時間を節約できるかどうかは疑問です。私はまた、データベースをあまりにも多くのコントロールをあきらめて、データレベルの問題を追跡するのを難しくしてしまうのではないかと心配しています。これらのタイプの製品は、データベースやビジネスオブジェクトの構造を変えなければならないという厳しい状況の中で、より良くなったり悪くなったりしますか？例えばシンプルなオブジェクトからデータベースへの製品
：本質的には Object Relation Mapping from Dev Express
は、それは価値がありますか？私は「それ」多くの時間、努力、および将来のバグを救いますか？
私はSubSonicとEntitySpacesを使用しました。一度あなたがそれらのハングアップを得ると、私は彼らがあなたの時間を節約することができると信じていますが、あなたのアプリの複雑さとデータ量が増加すると、これらのツールを超える可能性があります。パフォーマンスの問題のようなものがORMまたはコードに関連するかどうかを判断しようとすると、時間が無駄になります。だから、あなたの質問に答えるために、私はそれが依存していると思う。私はこれに関してEricに同意しがちですが、大量のエンタープライズアプリケーションは汎用ORMには適していませんが、標準的な料金のより小さいCRUDタイプのアプリケーションでは、時間が節約されることがあります。
ORMには多くの選択肢があります。 LinqからSQLへ、nHibernateへ。純粋なオブジェクトデータベースにはdb4oがあります。
これはアプリケーションによって異なりますが、大規模なエンタープライズアプリケーションの場合はこのルートにはなりません。データをより詳細に管理する必要があります。
私は週末に友人とこれについて議論していました。アプリケーションの外部でデータベースにクエリを実行できるようにする必要がある場合は、ストレージの使いやすさを向上させることができないようです。私の理解では、これらのデータベースは、正規化されていない方法でオブジェクトデータを格納することによって動作します。これにより、オブジェクトのセット全体を高速に検索できますが、オブジェクトモデルと一致しないパースペクティブからデータを選択する必要がある場合は、必要な特定のデータを取得するのが困難になることがあります。
この問題の優れた解決策として、ApacheグループのiBatisが見つかりました。私のチームは現在、iBatisを使用してJavaからMySQLのバックエンドへのすべての呼び出しをマップしています。すべてのSQLクエリとプロシージャは、コードではなくXMLファイルに格納されているため、すべてのSQLクエリとプロシージャを簡単に管理できるため、大きなメリットがあります。言語とは無関係にSQLからコードを分離することは大きな助けになります。
さらに、iBatisでは、独自のデータマッパーを作成して、オブジェクトとの間でデータをマップすることができます。私たちは、あなたのためにすべてを行うHibernate型のソリューションとは対照的に、この柔軟性を求めていましたが、複雑なクエリを実行する能力も制限されていました（IMO）。
iBatisの.NETバージョンもあります。
私は最近、城プロジェクトからActiveRecordを設定しました。それは行くのはかなり簡単だった。新しいアプリケーションを作成した後、私はMyGenerationを使って、ActiveRecordがかなり短時間で使用できるレガシーアプリケーション用のクラスファイルをスクリプト化しました。 NHibernateを使用してデータベースとやり取りしますが、NHibernateに付属するすべてのxmlマッピングを取り除きます。いいことは、あなたのプロジェクトにNHibernateが必要な場合は、すでにNHibernateを持っていることです。特殊なケースがある場合は、フルパワーを使用できます。私はそれを見てみることをお勧めします。