代わりにファクトリを注入します。このようにして、懸念の分離と疎結合を実現しますが、ステートメントの使用に関する問題に直面することはありません。
private IUnitOfWorkFactory factory;
public MyController(IUnitOfWorkFactory factory)
{
this.factory = factory;
}
public ActionResult MyAction()
{
using (var uow = factory.CreateUnitOfWork())
{
// ...
}
}
編集:
このようなアプローチの自然な利点は、その構成可能性です。さまざまなコントローラーにサービスを提供する任意のファクトリを登録し、コンポジション ルートに接続できます。
// Note: this isn't unity syntax, but I hope my point is clear
container.Register<ISessionFactory, ReusableSessionFactory>("Reusable");
container.Register<ISessionFactory, FreshSessionFactory>("Fresh");
container.Register<IController, LoginController>().With("Fresh");
container.Register<IController, HomeController>().With("Reusable");
今、
LoginController
要求ごとに内部で新しいセッションを提供するファクトリを使用します
HomeController
一方、同じセッションをその存続期間全体にわたって再利用します
コントローラーの観点からは、どのファクトリがセッションを提供するかは単なる実装の詳細であるため、無関係であることに注意してください。そのため、セッション ファクトリの依存関係を抽象化 (この例ではインターフェイス) の背後に隠し、アプリケーションのルートですべてのオブジェクトから依存関係へのバインディングを実行します。