hereで説明されているように、Unit of Work/Repository パターンを実装しましたが、autofac とコンストラクター インジェクションも使用しているため、UnitOfWork と DbContext (PsyProfContext) クラスを次のように登録しました。
builder.Register(context => new PsyProfContext()).InstancePerHttpRequest();
builder.RegisterType<UnitOfWork>().As<IUnitOfWork>().InstancePerHttpRequest();
そして、すべてがうまく機能します!
1 つを除いて、エンタープライズ ライブラリの logging blockも使用しており、Entity Framework を使用してログ エントリをデータベースに書き込む CustomTraceListener を実装しました。
私のコントローラーは次のようになります(現時点では、すべてのもの(IoC、ロギング、エンティティフレームワーク)が機能しているかどうかを確認しようとしたため、空です):
public class HomeController : Controller
{
private readonly UnitOfWork unitOfWork;
public HomeController(IUnitOfWork unitOfWork)
{
this.unitOfWork = (UnitOfWork) unitOfWork;
}
//
// GET: /Home/
public ActionResult Index()
{
throw new HttpException();
return View();
}
protected override void Dispose(bool disposing)
{
unitOfWork.Dispose();
base.Dispose(disposing);
}
}
また、CustomTraceListener クラスの Write メソッドで、UnitOfWork を解決しようとしました。
DependencyResolver.Current.GetService<IUnitOfWork>() as UnitOfWork;
しかし、すでに破棄されているインスタンスを取得します! だから私はいくつかのブレークポイントを置き、コントローラーの Dispose メソッドが CustomTraceListener クラスの Write メソッドの前に呼び出されることを発見したので、最終的に DbContext (PsyProfContext) を直接使用する以外の解決策は見つかりませんでした:
public override void Write(object o)
{
using (var conext = new PsyProfContext())
{
var customLogEntry = o as CustomLogEntry;
if (customLogEntry != null)
{
var logEntry = new LogEntry
{
//a bunch of properties
};
conext.Exceptions.Add(logEntry);
conext.SaveChanges();
}
}
}
しかし、私はこの解決策が好きではありません! DbContext オブジェクトに直接アクセスする場合、 UnitOfWork および Repository パターンを使用するポイントは何ですか。または、場合によっては登録済みオブジェクトを手動で作成する場合、プロジェクトで DI を使用する意味は何ですか。
このような状況にどのように対処するかについて、あなたの意見を聞きたかったのですか? 私の現在の実装は問題ありませんか、それとも間違いであり、別の実装を検討する必要があります。
どんな助けでも大歓迎です。どんなアイデアでも大歓迎です!