NHibernateでリポジトリパターンが必要なのはなぜですか？

私はあなたの最初のNHibernateベースの公式アプリケーションを読んでいます。

チュートリアルはわかりやすくてわかりやすいですが、Repositoryパターンを使用する理由を知りたいと思います。

様々でAdd、Update、RemoveのメソッドProductRepositoryの実装は、コードはほとんど同じである-彼らはすべてのトランザクションを使用している、との違いは、「肉」、すなわちコールであるsession.Saveint型Add、メソッドsession.Deleteにremove方法。（ページはHTMLのアンカーを欠いていますが、のような関連するコードのページを検索することができpublic void Remove、public void Add）

そのコードは「間違っていると感じる」だけです。

作者がリポジトリパターンを使用しているのはなぜですか-NHibernateを使用するためのデモンストレーションのためだけなのか、それとも必要なのか、またはその他の理由がありますか？

追伸 私のバックグラウンドはActiveRecordを使用したRuby on Railsからのものですので、NHibernateがどのように機能するか、またはどのように使用されるかを理解しようとしています。

リポジトリパターンは必要ありません。他のすべてのパターンと同様に、ビジネスニーズに対して行う必要がある「アーキテクチャ」の決定です。一般に、リポジトリパターンは「エンティティ永続性インゴランス」を実装するために使用されます。つまり、エンティティは、保存デバイス（データベース、XML、テキストファイルなど）で永続化する方法について何も知りません。たとえば、エンティティAddressがある場合、永続ロジックは含まれません（address.Saveやaddress.Updateなどは見つかりません）が、エンティティを永続化を担当するリポジトリメソッドに渡します。変更

リポジトリパターンを使用する利点は、データアクセスレイヤーをモックすることです。これにより、DALコードを呼び出さずにビジネスレイヤーコードをテストできます。他にも大きな利点がありますが、これは私にとって非常に重要なようです。