0

ASP.NETクライアント、ASP.NET Webサービス中間層、およびOracleバックエンドである既存のシステムにオブジェクトリレーショナルマッパーを使用することに興味があります。すべてのデータベースアクセスはストアドプロシージャを使用して行われ、WebサービスでSQLは許可されていません。私はNHibernate、TelerikのOpenAccess ORM、およびEntityFrameworkを調査してきました。データベースはDBAによってかなり厳密に制御されているため、これを「分離」と名付けました。また、データベースの設計を制御し、（オブジェクトモデルの）適切な正規化のためにデータベースを作り直すことはほとんど問題外です。また、ツールが任意のSQLを作成できるようにすることも問題外です。

私の質問は次のとおりです。これらの制約を考えると、これらのツールのどれがこの種の環境に最適な統合を可能にするでしょうか？

4

3 に答える 3

3

ストアド プロシージャを使用してデータ アクセスを完全に実装しても、ORM を使用しても価値が得られないというわけではありません。それは、おそらくその利点の一部を使用しないことを意味します.

あなたが評価した ORM に関しては、おそらくすでに次のことに気付いているでしょう:

  • それらはすべて、データベースがすでに定義された後にモデルを作成できるデータベースファーストアプローチをサポートしているため、資格情報を要求する以外にDBAの作業に干渉する必要はありません
  • Entity Framework と OpenAccess はすぐに使用できるモデルの視覚的表現を提供しますが、NHibernate は提供しません。
  • OpenAccess と NHibernate は Oracle をサポートしていますが、Entity Framework で Oracle を使用することはそれほど簡単ではありません。
  • Entity Framework と OpenAccess でのストアド プロシージャのサポートは、NHibernate よりもはるかに洗練されています。OpenAccess では、ストアド プロシージャを複数の結果セットにマップすることもできます。

それが役立つことを願っています。

于 2012-03-27T08:13:02.353 に答える
3

まったくありません。

すべてをストアド プロシージャで行うことによって、ORM の機能の 99% を使用することはできません。

おそらく、ServiceStack.OrmLite や Massive などの Micro ORM を使用することをお勧めします...

しかし、NH、LightSpeed、EF などの本格的な ORM を見ると、完全にやり過ぎであり、0 ゲインのために複雑さが増すだけです。

于 2012-03-26T02:12:55.900 に答える
1

これを正しくしましょう。制約は次のとおりです。

  • ORMを使用する必要があります
  • データベースを変更することはできません。
  • ストアドプロシージャのみを使用できます。

@Phillに同意すると思います。本格的なORMは、その機能を使用できない場合はやり過ぎです。

ところで、私はかつて、DBAがねぐらを支配し、データにアクセスするための手順のみを義務付けたこのようなシステムに取り組んでいました。悪夢。

于 2012-03-26T02:16:05.733 に答える