Asp.Net身份用户管理器和工作单元-如何配对？

Question

I am using the Unit Of Work Pattern and have defined a class for it in a separate sub-project called MyProject.Domain.DAL.UnitOfWork.

Unfortunately, the whole ASP.Net Identity infrastructure is in my main project (as in the tutorial), MyProject.

Even more problematic: As I understand it, the ASP.NET identity uses it's own DBContext:

public class ApplicationDbContext : IdentityDbContext<ApplicationUser>
{
    /// <summary>
    /// Initializes a new instance of the <see cref="ApplicationDbContext"/> class, using the EFDB context.
    /// </summary>
    public ApplicationDbContext()
        : base("EFDBContext", throwIfV1Schema: false)
    {
    }

    /// <summary>
    /// Creates this instance.
    /// </summary>
    /// <returns>A database context</returns>
    public static ApplicationDbContext Create()
    {
        return new ApplicationDbContext();
    }
}

I have a class called Project, which should have a user associated with it - but how to do that, without using conflicting db contexts?

Example:

public class Project
{
   public ApplicationUser User {get; set;}
}

Example calling code:

public class IndexController : Controller
{
    // uow and userManager are instantiated through Ninject
    // example code, normally this would be properties of the controller
    public ActionResult Create(IUnitOfWork uow, ApplicationUserManager userManager, int someID )
    {
       Project newProject = new Project(); 
       ApplicationUser user = await UserManager.FindByIdAsync(someID);
       // this should give a conflict, since two different DataContexts are involved
       newProject.User = user;
       uow.Projects.Insert(newProject);
       uow.Save()
       return this.View();
    }
}

}

Answer 1

The template is a bit confusing. You shouldn't create a separate own DbContext but rather extend the existing ApplicationDbContext with the rest of the data model. You can move it to somewhere else in the project, as long as you change the type in IdentityConfig.cs .

There is a tougher problem to solve though when using unit of work and it is that the ASP.NET Identity methods call SaveChanges() internally and when using unit of work you typically only want that once all the work is done. A workaround could be to use a TransactionScope() but it could be messy to get it created before the per-request DbContext that ASP.NET Identity uses.