У меня есть довольно стандартное приложение MVC 5, состоящее из уровня репозитория, уровня обслуживания и уровня контроллера. Чтобы каждый слой был развязан и проверен, я использую Ninject для инъекции зависимостей.
Чтобы освежить новый навык, я решил использовать новые новые действия контроллера задачи с async/await для операций с привязкой IO для методов обслуживания и контроллера.
Обычно я просто использую привязку InRequestScope, например,
kernel.Bind<IDbContext>().To<BlogContext>().InRequestScope();
В целом, сейчас это нормально работает, однако, если я решил отлаживать приложение или объединить несколько объектов структуры отслеживаемых сущностей вместе и сохранить, я обнаружил, что контекст был удален или у меня возникают проблемы с отслеживанием. Я понимаю, почему это происходит, это совершенно логично, потому что операция больше не происходит в потоке IIS, так как Ninject знает, что он должен использовать тот же контекст.
Чтобы обойти это, я могу передать свой контекст в каждый вызов репозитория с моего уровня обслуживания или даже с уровня контроллера, если это необходимо. Однако я чувствую, что это выглядит беспорядочно, и я предпочел бы, чтобы Ninject управлял контекстом этого объекта, если это было возможно.
Каковы наилучшие стратегии для этого в элегантной/минималистской манере, сохраняя мой код похожим на приведенные ниже примеры?
Вот пример одного из моих методов контроллера
public virtual async Task<ActionResult> Edit(int id)
{
var editViewModel = await BuildDefaultCreateEditViewModel();
var post = await postService.GetNonDeletedPost(id);
...
...
return View(MVC.Admin.Post.Views.CreateEdit, editViewModel);
}
Сервисный метод
public async Task<PostDTO> GetNonDeletedPost(int postId)
{
return (await PostRepostiory.GetPost(postId)).ConvertToDTO();
}
Метод репозитория
public Task<Post> GetPost(int postId)
{
return QueryableExtensions.SingleOrDefaultAsync(
DbSet.Where(post => post.PostId == postId)
.Include(post => post.PostVersions)
.Include(post => post.Categories)
.Include(post => post.Files));
}