Menu
In Visual-Studio 2013, when creating an ASP.NET project, it generates a file IdentityModels.cs that contains a class ApplicationDbContext, that inherits from IdentityDbContext<ApplicationUser>, which eventually inherits from DbContext.
Should I keep this context only for account-related entities, and created a separate context for all the other entities in the application or should I mix it.
Any security issue or reason not to include all the entities of my entire application in one context?
319
To answer to all of these questions we need to understand that IdentityDbContext is just a class inherited from DbContext. Create a DbContext which inherits from IdentityDbContext and have access to the classes.
The ApplicationDbContext links the database server to the data model classes in the Asp.Net application. This only calls dbContext.Table1.Field1 and has the value of a data table.
Microsoft makes no warranties, express or implied, with respect to the information provided here. Base class for the Entity Framework database context used for identity. public class IdentityDbContext : Microsoft.
This class is useful when we need to load the ApplicationContext programmatically. In general, test harnesses and standalone applications are some of the possible use cases for this. For example, let's see how we can create this Spring container and load the beans for our XML-based configuration: 5.5. ClassPathXmlApplicationContext
There is no right answer for this. There is no security issue related to 2 different contexts. It all goes down to your architecture - do you need to create references to users in your domain or not. In separate domains you can't have EF maintaining foreign keys from user tables to domain.
A few times I have started with 2 different dbContexts but got tired of extra maintenance and no gain and merged stuff into one.
And because you are asking about this, chances are that you won't gain anything from 2 separate db-contexts, only add extra code and unwanted maintenance in the future. So I say have only one to start off. You can always separate when you actually need it.
175
I would create a separate context , mainly for the reason you may need to separate your user account db from your application db at some point. Often an organization's security policy will ask for this.You can always point to the same connection string if you don't have this requirement and still maintain two contexts. I prefer splitting contexts , as it keeps the fluent api for entity mapping limited. Keeping it separate also gives you the option to encrypt your authentication dd and maybe not your app data, which gives you a nice balance between security and performance.
35
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
