8

私は告白します、私は完全にうんざりしていません*休止状態。

DapperのようなマイクロORMは、ほとんどのデータアクセスのニーズに対応するために使用できるため、nHibernateのような大きな銃を必要とするシナリオは何ですか？nHibernateが輝く状況の例をいくつか挙げてください。明確にするために、私は「コードを変更せずにデータベースを切り替える機能」をあまり利点とは考えていません。プログラミングの8年間、私は実際にそれを行う必要はありませんでした。そもそもアイデアを無駄にするようです。

私はどんな思慮深い応答にもオープンですが、ここに私が持っている質問のいくつかの例があります：

  1. Dapperのようなものと比較して、クエリAPIは、マッピングに追加の作業を行う価値があるのはいつですか？
  2. 開発の労力を制限し、正しく機能するように、遅延読み込みをどのように活用できますか？
  3. ステートメントをバッチ処理する方法を理解するのに時間の価値があるのはいつですか？
  4. たとえば、ページ出力キャッシュよりもキャッシュシステムの方が優れているシナリオはどれですか。それは非分散環境でのみ当てはまりますか？
  5. 分散環境でnHibernateがどのように機能するかを理解するために、私のような単なる人間はどのように期待されますか？キャッシング、バッチ処理、ステートレスセッションを組み合わせて、負荷分散されたWebサーバーがこれらすべてをどのように処理するかを検討してください。
4

2 に答える 2

8

うわー、大きな質問。単なる人間がそれに答えることができるかどうかはわかりません。しかし、あなたは「データベースを切り替える機能」を却下するには速すぎると思います。商用とオープンソースの両方のソフトウェアパッケージがたくさんあり、バッキングストアとしてさまざまなRDBMSと連携する機能を提供します。2つ以上のデータベースプラットフォームに展開するためにSQLを管理することは、絶対的な悪夢になる可能性があるため、（少なくとも手書きで作成する場合と比較して）予測可能な方法でSQLを構築することは大きな利点です。悪魔の擁護者を演じるだけで、一部のデータベースプラットフォームでは、トランザクションスループットが向上し、データベースの選択を維持するのに非常に費用がかかることがわかりました。ほとんどのORM '

簡単に言えば、アプリケーションに対するデータベースのニーズがある程度の複雑さに達すると、要件を満たすことなく要件を満たすためのコストは、nhibernateの学習曲線に伴うコストよりも低くなるということです。私は完全な答えを提供することはできませんが、あなたのリスト項目について私の考えを述べようとします。

  1. CRUD以上のことをしているとき。複数のデータベースプラットフォームでの複雑なクエリの必要性は、おそらく良い例です。このタイプのアプリでは、ほぼ2つの別々のコードベースを維持することになり（ストアドプロシージャルートを使用すると、実際に分離されます）、すべてのコードを.netに保持することに価値があります（ユニット化できるのは素晴らしいことです）。たとえば、コードの残りの部分でこれらのクエリをテストします）。
  2. 中程度の信頼環境で見られる問題は別として、遅延読み込みが「正しく機能」しないのはどうでしょうか。私の目には遅延読み込みの唯一の問題は、大量のデータをフェッチするときに発生する可能性のある問題のいくつか、主にN+1選択の問題を回避するために注意する必要があることです。
  3. ステートメントをバッチ処理する方法を理解する必要はありません。構成値を設定して、それを忘れるだけです。これは、NHibernateが最小限の労力で実行する非常に大きな最適化です。コードが操作とトランザクション制御に直接関係している場合にのみ、コードをよりクリーンにすることができます。
  4. 返されたデータをキャッシュすることは、ユーザーごとにページを異なる方法でレンダリングする場合や、ドメインレイヤーで重要な処理を行う場合に役立ちます。基本的なシナリオでも、ページ出力キャッシュを使用すると、編集ページや詳細ページなどがキャッシュに保存される可能性がありますが、データをソースの近くにキャッシュすると、エンティティを1回キャッシュするだけで済みます。ソースに近づくと、古いデータを提供することからの保護も強化されます。データ指向のキャッシュは、サービスを介して、またはnHibernateをmemcachedやredisなどのアウトプロセスストアにポイントすることで、複数のアプリケーション間で共有することもできます。これは、一部の環境では非常に価値があります。
  5. それがどのように機能するかを理解する必要があるかどうかはわかりません（多くの場合、この種の実装の詳細を理解する必要から身を守るためにオープンソースライブラリを使用しています）。しかし、簡単に言えば、分散シナリオでは、キャッシング（および第2レベルのキャッシングのみ）を除いて、これらのいずれも異なる動作をしないということです。分散キャッシュプロバイダーを使用している（またはすべてのサーバーを同じアウトプロセスキャッシュプロバイダーにポイントしている）限り、その面でも優れているはずです。

私はnHibernateについて話しているだけですが、Hibernateの話はほとんど同じだと思います。大規模で複雑なアプリケーションの場合、多くのメリットがありますが、このメリットを享受するために必要な追加の複雑さがたくさんあります。それでも、すべての問題に対して独自のソリューションを展開するよりも複雑ではありません。 *Hibernateはあなたのために解決します。

また、キャッシングに関して多くの質問がありました。このリンクを読んで、第1レベルと第2レベルのキャッシュがどのように機能するかを理解することをお勧めします。私はここで説明しようとはしません。なぜなら、あなたは私がこのすでに長い返事に収まるよりも深い理解を求めているように思われるからです:)

于 2012-08-02T00:02:34.633 に答える
5

NHibernateは大きくて強力ですが、NHibernateを使用して成功するために、NHibernateについてすべてを知る必要はありません。あなたの質問に答えるには：

  1. すべての.NETmicro-ORMSには、私が知っているLINQサポートがなく、代わりにコードにSQL文字列を混在させることに依存しています。LINQを使用してクエリを構築すると、型の安全性、コンパイル時のチェック、および優れたリファクタリングが可能になります。すべてのクエリがSQL文字列を使用している場合は、何千ものクエリを含むコードベースをリファクタリングしてみてください...そうです！また、リファクタリングとは、新しい列や新しいテーブルなどを追加するだけの単純なことを意味します。これは、エンタープライズ環境で常に発生することです。文字列のリファクタリングは可能です。ストアドプロシージャに依存している人々はまだそうしなければなりませんが、型の安全性を自由に使えるのであれば、そうすることを選択しないでしょう。

  2. 遅延読み込みでは、覚えておく必要があるのはSELECT N+1シナリオを作成することだけです。ドメインオブジェクト/エンティティに対してforeachループを実行するコードがある場合は常に、オブジェクトに入力されたクエリが.Fetch（）メソッドを使用していることを確認してください。このメソッドは、SQLでJOINを作成し、子オブジェクトに入力します。そうしないと、オブジェクトをforeachして子オブジェクトにドットを付けるときに、ORMは別のSELECTステートメントを実行してデータを「フェッチ」する必要があります。基本的に、NHibernateの用語では、熱心なフェッチはあなたの友達です。

  3. バッチ処理は、NHibernateを使用したパイと同じくらい簡単です。NHibernate構成で、バッチ処理をオンにすると、それだけです。その後、必要に応じて、特定のクエリの実行時にバッチサイズを調整できます。

  4. 私は自分で第2レベルのキャッシングを利用したことがありません。私は大規模なエンタープライズ環境で作業しており、アプリはキャッシュを必要とせずに非常に高速に実行されます。NHibernateの第1レベルのキャッシュは、構成が不要であり、単に変更の追跡と考えることができます。基本的に、NHibernateは内部的に、データベースからすでに取得したオブジェクトと、データベースでの保存/更新が保留されているオブジェクトのディクショナリを保持します。最初のレベルのキャッシュは、私が実際に考えたことのないものですが、基本的なレベルでそれがどのように機能するかを知っておくのは良いことだと思います。

  5. 繰り返しになりますが、私は現在エンタープライズ環境で働いており、NHibernateを使用するあらゆる種類のアプリケーションがあります。かなり基本的なものもあれば、NHibernateが提供するすべての強力な機能を使用するものもあります。しかし、私の経験で私が通常見たのは、チームのすべてのメンバーがNHibernateの専門家である必要はないということです。通常、1〜3人の開発者は非常に知識が豊富で、他のすべての人はそれについて心配することなく、エンティティとマッピングを作成し、プログラミングを続行します。インフラストラクチャが整って、組織が使用したいパターンを整理したら、通常、すべてが簡単になります。

追加の考え：

NHibernateが本当に輝いている場所の1つは、あらゆる種類のクレイジーなデータベース設計をマッピングできることです。今では、ストアドプロシージャと別のテーブルを結合する必要がある、90年代初頭にまとめられたクレイジーなデータベース設計を簡単にマッピングできると言っているわけではありませんが、それは可能です。私は私の日にいくつかのクレイジーなマッピングを行いました。データベースが私たちが望んでいたことを実行するように設計されていないために不可能だと思った人もいましたが、毎回、永続性を持って、良いデータベース設計と悪いデータベース設計の両方をマッピングするNHibernateの信じられないほどの柔軟性でそれをうまくやってのけることができます。

Micro-ORMSを使用すると、通常、コードの横に大量のSQL文字列が埋め込まれることになります。それはどのようにクリーンで効率的であると考えられていますか。現在、すべての人がストアドプロシージャを配置するために使用しているものをコードに配置しているようです。私は実際にいくつかのプロジェクトでMicro-ORMを使用していますが、それは理にかなっていますが、通常は、複雑なWHERE句ではなく、1つのテーブルで単純なデータのみをクエリする場合です。

公平を期すために、私はNHibernateの詳細を学ぶためにかなりの時間を費やしてきましたが、仕事が必要だったからではなく、ただやりたかったからです。私は、NHibernateを毎日使用していて、十分に理解していない多くの人々と仕事をしています。しかし、繰り返しますが、彼らはそうする必要はありません。あなたはいくつかの基本的なことを知る必要があります、そしてあなたは行ってもいいです。

お役に立てれば。

于 2012-08-03T08:44:48.893 に答える