2

しばらく前に、1:n、n:m、または n:1 の関係を介して相互に強く関連する約 25 ～ 30 の異なるクラス/タイプ/モデルを内部に持つ新しいプロジェクトの開発を開始しました。

当時は、基本的にネイティブの .net oodbms システムを使用していました。これにより、オブジェクト モデルを使用して、いくつかの永続化関連のメソッド (-calls) をあちこちに追加するだけで、準備が整いました。しかし、時間が経つにつれて、私たちはますます多くの警告に出くわし、非常に悪い、修正不可能な (合理的な時間枠内での) 制限に遭遇し、遅い回避策を実装することを余儀なくされ、地平線上で平凡なパフォーマンスとスケーラビリティの問題が発生し、ライセンス料はほぼ 1 倍に増加しました。私たちにとっては5倍で、変更はありません（ビッグインクに買収されました）。

そのため、現在、スケーラビリティ/パフォーマンスとメンテナンスの観点から、長期的なソリューションを探し始めています。私たちは他の「本物の」odbmを見て、常に主要なブレーカーに出くわしました. SQLとの論争の。

したがって、基本的にここに私の質問があります。MicrosoftのEntity Frameworkまたはその他の.NET ORMで、構成を可能な限り保守可能に保ち、密接/重く関連するエンティティで適切に機能する実世界の経験がある人はいますか? 私たちが保存するデータの量は、驚くべきものでも膨大なものでもありません (今後 3 年以内にすべてのエンティティで合計 10 万インスタンスになると予想しています)。

ORM に関するアイデアや提案、および/または oodbms から rdbms への移行の経験がある人はいますか?

4

2 に答える 2

1

既存のオブジェクトモデルがあり、ORMソリューションへの移行を検討している場合は、NHibernateが確かに良い選択だと思います。理由は次のとおりです。

  1. 永続性をサポートするために、ドメインモデルクラスに（m）追加/変更を加える必要はありません。NHibernateは、ドメインモデルで永続性の無知をサポートするのに大いに役立ちますが、たとえば、他の方法よりも多くのメソッド/プロパティを仮想としてマークするなど、いくつかの小さな変更を加える必要がある場合があります。
  2. 既存のオブジェクトモデルをマッピングした後、データベースのスキーマを生成できます。これは、ドメイン駆動型（または単にオブジェクトモデルファースト）の開発にとって大幅な時間の節約になります。この機能は、FluentConfiguration.ExposeConfiguration（）メソッドを使用してFluent NHibernateを使用するか、hbm2ddlツールを使用して標準のNHibernateマッピングファイルを使用してサポートされます。もちろん、これは保守性にも役立ちます。オブジェクトモデルへの変更は、データベーススキーマにすばやく反映できます。
  3. マッピングに流暢なNHibernateを使用すると、オートコンプリートと簡略化されたマッピングモデルを取得するため、初期マッピングを非常に高速にするのに役立ちます。これは、探している保守性を提供するのにも役立ちます。マッピングは、流暢なNHibernateを使用したコードで宣言されるため、リファクタリングツールはそれに応じてマッピングを変更します。また、Fluent NHibernate自動マッピングを使用して、ほとんどの場合、オブジェクトモデルを手動でマッピングすることを回避できる場合もあります。

これにEntityFrameworkを使用することは、より困難になります。エンティティフレームワークは多くの点で有能なORMですが、NHibernateほど成熟しておらず、この場合、特にそれがおそらく最良の選択ではないと思う理由がいくつかあります。

  1. Entity Frameworkをサポートするには、既存のオブジェクトモデルに多くの変更を加える必要があります。現在提供されているエンティティフレームワーク用のツールを使用する場合は、EntityObjectエンティティフレームワークの基本クラスを継承する生成された部分クラスにコードを移行する必要があります。この継承要件は、既存のオブジェクトモデルによっては、問題になる場合と問題にならない場合があります。コードでいくつかのインターフェイスをサポートすることでこれを回避できますが、これは重要であり、マッピングを管理するための組み込みのツールサポートの多くが失われると思います。
  2. ほぼ確実に、データベーススキーマを手動で作成する必要があります。適切なサイズのオブジェクトモデルでは、これは通常、重要でないタスクではありません。
  3. エンティティフレームワークは、すぐに使用できる透過的な遅延読み込みをサポートしていません。透過的な遅延読み込みはOODBMSで慣れているものであり、他のほとんどのORM（もちろん、NHibernateを含む）でサポートされていると思いますが、エンティティフレームワークでは、明示的に.Load（）関連のオブジェクトが必要であることがわかります。 （親と子の両方の関係）コードでそれらを参照する前に。これには回避策がありますが（これなど）、組み込みの機能ではありません。

全体として、私の意見では、オブジェクトファーストの開発、または既存のオブジェクトモデルを活用しようとしている場合は、NHIbernateの方が適しています。データ中心の開発では、Entity Framework（またはlinq to sql、さらには亜音速）がより実行可能な選択肢になります。

Lightspeedなどの商用ORM製品を評価することもできます-私はこの特定のツールの経験がほとんどありません（顧客は一般に、無料の代替手段がある場合にORMの支払いに反対します）が、高く評価されています。

于 2009-04-15T10:44:01.820 に答える