単純なオブジェクトからデータベース製品へ

Question

私は、自動生成されたデータベースにビジネス オブジェクトをシームレスにマッピングする方法を提供することで、開発時間を短縮することを提案する .NET 用のさまざまな製品をいくつか検討してきました。データ アクセス レイヤーの作成で問題が発生したことはありませんが、このタイプの製品が本当に時間を節約できるかどうか疑問に思っています。また、データベースに対する制御を放棄しすぎて、データ レベルの問題を追跡するのが難しくなるのではないかと心配しています。この種の製品は、データベースとビジネス オブジェクトの構造を変更する必要があるというすでに困難な状況において、状況を改善するのでしょうか、それとも悪化させるのでしょうか?

例えば：Dev Express からのオブジェクト リレーション マッピング

本質的に、それだけの価値はあるのでしょうか？「それだけ」多くの時間、労力、将来のバグを節約できるでしょうか?

Answer 1

私はSubSonicとEntitySpacesを使用しました。一度コツを掴めば時間を節約できると思いますが、アプリが複雑になりデータ量が増えると、これらのツールでは対応しきれなくなる可能性があります。パフォーマンスの問題のような問題が ORM に関連しているのか、それともコードに関連しているのかを判断しようとすると、時間を失い始めます。したがって、あなたの質問に答えると、それは状況によると思います。これについては私も Eric の意見に同意する傾向があり、大容量のエンタープライズ アプリは汎用 ORM には適していませんが、標準的な小規模な CRUD タイプのアプリでは、時間を節約できる可能性があります。

Answer 2

見つけました アイバティス Apache グループからのこの問題に対する優れた解決策です。私のチームは現在 iBatis を使用して、Java からのすべての呼び出しを MySQL バックエンドにマッピングしています。SQL クエリとプロシージャはすべてコード内ではなく XML ファイル内にあるため、すべての SQL クエリとプロシージャを簡単に管理できるため、これは大きな利点です。どのような言語であっても、SQL をコードから分離することは非常に役立ちます。

さらに、iBatis を使用すると、オブジェクトとの間でデータを DB にマッピングするための独自のデータ マッパーを作成できます。私たちは、ユーザーに代わってすべてを行う Hibernate タイプのソリューションとは対照的に、この柔軟性を求めましたが、(IMO) 複雑なクエリを実行する能力も制限されます。

iBatis の .NET バージョンもあります。

Answer 3

最近セットアップしました アクティブレコード Castle Project のアプリから。とても簡単に進めることができました。これを使用して新しいアプリを作成した後、MyGeneration を使用して、ActiveRecord が非常に短時間で使用できるレガシー アプリのクラス ファイルをスクリプト化することもできました。NHibernate を使用してデータベースと対話しますが、NHibernate に付属するすべての XML マッピングが削除されます。ただし、必要に応じてプロジェクトに NHibernate がすでに含まれているため、特別な場合にはその能力を最大限に活用できるのが良い点です。見てみることをお勧めします。

Answer 4

ORM には多くの選択肢があります。Linq to SQL、nHibernate。純粋なオブジェクト データベースには db4o があります。

アプリケーションによって異なりますが、大規模なエンタープライズ アプリケーションの場合は、この方法は選択しません。データをより細かく制御する必要があります。

Answer 5

週末に友人とこの件について話し合っていたのですが、アプリケーションの外部でデータベースにクエリを実行できるようにする必要がある場合、ストレージの容易さによって得られる利点が失われるようです。私の理解では、これらのデータベースはオブジェクト データを非正規化された方法で保存することで機能します。これにより、オブジェクトのセット全体を高速に取得できるようになりますが、オブジェクト モデルに一致しない観点からデータを選択する必要がある場合、ODBMS は必要な特定のデータを取得するのが困難になる可能性があります。