2

ウィンザーを始めたとき、DIは簡単だと思いました。今、それは私にますます混乱を引き起こしています。

リポジトリは、シングルトンライフサイクルを持つクラスとして私を襲います。アプリケーションの存続期間中にFoosをデータベースにロードして保存するには、FooRepositoryの単一インスタンスが必要です。

ただし、各リポジトリは、ダーティチェックを実行し、データベースなどを操作するUnitOfWorkへの参照を保持します。UnitOfWorkのライフサイクルはPerWebRequestです。シングルトンインスタンスのように、UnitOfWorkがシングルトンであることはまったく意味がありません。 （たとえば）複数のユーザーセッションによって同時に行われた変更をフラッシュします。

したがって、UnitOfWorkへの参照を保持するシングルトンFooRepositoryがあり、セッションの最後に破棄されます。リポジトリの動作にどのような影響があるかはわかりませんが、よく聞こえません。

WebアプリでRepositoryクラスとUnitOfWorkクラスのライフサイクルを管理する適切な方法を、簡単な英語で（おそらくコードを使用して）誰かが説明できますか？

4

2 に答える 2

5

経験則は次のとおりです。コンポーネントは、それよりも長持ちする他のコンポーネントに依存してはなりません。

言い換えると、トランジェントがシングルトンまたはWebリクエストごとのコンポーネントに依存することは問題ありませんが、その逆は問題ありません。

私がリポジトリにアプローチする方法-UoWシナリオは、私のUoWはWebリクエストごとですが、リポジトリはステートレスで一時的なものです。

于 2010-09-23T12:19:48.927 に答える
2

リポジトリとは、Nhibernateセッションを抽象化するリポジトリを意味すると思います。もしそうなら、それは決してシングルトンであってはなりません。シングルトンの場合、複数のリクエストスレッドが互いのセッションを踏みにじります。私は個人的にこれの周りにいくつかの欠陥を見てきました。Castleのデフォルトのライフサイクルはシングルトンであるため、開発者がコンポーネントのライフサイクルを明示的にマークするのを忘れると、悪いことが起こり始めます。

理想的には、要求ごとである必要があります（作業単位の概念に従う）。このアプローチの唯一の利点は、アプリケーションでAsp.net互換モードを有効にしていることです（Asp.netでない場合）。もう1つの方法は、リポジトリを一時的なものとしてマークすることです。ただし、このアプローチの欠点は、コンポーネントが必要とするたびにCastleが新しいリポジトリオブジェクトをインスタンス化することです。

于 2011-10-05T05:44:25.243 に答える