0

現在、Unit of Work オブジェクトと Repository オブジェクトを独自のプロジェクトに分割しています。このプロジェクトは、すべての OR/M (nHibernate) コードを含む別のプロジェクトにアクセスします。

これは単に不必要な抽象化であり、OR/M をリポジトリおよび作業単位として使用する必要があるという議論を聞いたことがあります。

これを行うか、これを行わないかの意見と理由は何ですか?

4

1 に答える 1

1

OR/M と作業単位とリポジトリを分割することには、少なくとも 3 つの利点があります。

  • 制御の反転とより単純な構成 —作業単位とリポジトリの抽象化の両方がnHibernateに直接依存するべきではありません。したがって、分離されたコード、SRP に従う明白な方法、およびその他の SOLID 原則の利点が得られます。また、必要のないnHibernateを取り除く可能性。
  • 単体テストの実行速度とシンプルさ —バックグラウンドでnHibernateを実行することなく、 Unit of WorkとRepositoryの両方をモック/スタブできる単体テスト
  • 契約による設計 — nHibernateと混合することなく、作業単位とリポジトリの個別の契約を確立します。

ps: 誤解しないでください。私はnHibernateを .Net で利用できる最高の OR/M の 1 つと考えていますが、多くの場合、コードのあらゆる場所に nHibernate を含める必要はありません。

于 2012-08-27T16:21:15.277 に答える