I'm developing web application using ASP.NET Core. When I use project template Web Application with Authentification:
ApplicationDbContext class generated:
public class ApplicationDbContext : IdentityDbContext<ApplicationUser> { public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options) : base(options) { } } I can use it for my modeles, but maybe it's better to create my own DbContext and don't mix my modeles with user's authentification?
As always, it depends.
Is this a self contained application that your clients are going to deploy on their own servers? If so, then adding the business dtos to the ApplicationDbContext might make sense.
On the other hand, if you're building an enterprisey application, you may want to reuse the authentication across many of your web apps. In that case, you probably would want to separate both the authentication and business models into their own class libraries.
I always look at the ApplicationDbContext the same way as the SqlMembershipProvider, I have never added my data access code to it.
ApplicationDbContext is something related to asp.net identity and not to my application or business logic, so I always separate the contexts, have my own user entity and link the other IUser to this entity.
This works fine with me in case if i need to change the whole security framework with something else
ApplicationDbContext should only contain models relating to authentication, it would be named something like IdentityDbContext or AuthenticationDbContext. Since it is named **Application**DbContext, I think it is OK to insert other application related models there as long as it makes good design sense.