0

典型的なアーキテクチャの MVC アプリケーションがあります...

ASP.NET MVC コントローラー -> 個人サービス -> 個人リポジトリ -> Entity Framework DB コンテキスト

私は Castle Windsor を使用していますが、これを ControllerFactory と一緒に使用して、適切な依存関係を持つコントローラーを作成する利点を理解できます。このアプローチを使用すると、コントローラーはサービスを注入します。これにより、適切なリポジトリを構築する方法がわかり、使用する正しい DbContext が認識されます。

ウィンザー構成はこのようなものです...

dicontainer = new WindsorContainer();
dicontainer.Register(Component.For<IPersonService>().ImplementedBy<PersonService>());
dicontainer.Register(
    Component.For<IPersonRepository>().UsingFactoryMethod(
        () => new PersonRepository(new HrContext("connectionString"))));

これは正しい方法ですか？UsingFactoryMethod は好きではありませんが、別の方法は考えられません。

また、リポジトリが、サービス層では必要のない依存関係 (ILogger など) を必要とした場合はどうなるでしょうか? これは、ILogger をサービス層に渡して使用しないようにする必要があるということですか。これはデザインが悪いようです。ここでいくつかの指針をいただければ幸いです。たくさんの記事を読みましたが、これが正しいかどうかを確認するための具体的な例は見つかりませんでした。ありがとう。

4

1 に答える 1

1

私はファクトリメソッドの使用を避けようとしています（あなたが言ったように、これは変なにおいがすると感じました）。これを回避するには、新しい DbContext を作成するデータベース セッション オブジェクトを作成します。次に、リポジトリで IDbSession のインスタンスを取得し、その dbContext プロパティを使用するだけです。次に、IDbSession オブジェクトのスコープを簡単に制御することもできます (シングルトンはスレッド セーフではないため、使用しないでください)。

この点をもっと重要な点にできるようにしたかったのです...コンストラクターがDIコンテナーに登録されているオブジェクトのみを取り込めるようにします(コンストラクターのオプションや構成はありません)。オプションと構成は、それらの値の読み取り/書き込みのみを目的とするクラスで読み取り/書き込みする必要があります。すべてのクラスがこのモデルに従う場合、DI 登録が容易になり、クラスは必要な依存関係をコンストラクターに追加するだけで済みます。

コンストラクターにオプションがあるサード パーティ ライブラリを使用しようとしている場合は、そのクラスを、使いやすいコンストラクターを持つ独自のクラスにラップし、構成クラスを使用してサード パーティ ライブラリに渡す必要がある値を読み取ります。また、この設計では、コードとサード パーティ ライブラリの間に抽象化レイヤーが導入され、必要に応じてサード パーティ ライブラリをより簡単に交換 (またはスタブ) するために使用できます。

于 2012-11-08T00:05:05.697 に答える