Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
In my ASP.NET MVC 3 application I have decided to go with EF code-first as an ORM framework. EF Code-First relies on DbContext class that exposes access to a collections of stored entities.
Would it be a good practice to separate a web “site access related” (custom membership and role providers) collections in one DbContext (a separate database as well), and have another database and DbContext to store a business logic entities?
If you leverage the built-in ASP.NET Membership classes, with an SqlMembershipProvider, you don’t even need to have an Entity Framework context for that aspect of things.
But even if you are doing your own Membership logic, it is wise to separate your database tables into logical groupings for your EF contexts, and avoid letting your contexts get too large. Overly-large contexts become difficult to work with and take longer to bootstrap when the system is initialized.