Where to put Entity Framework Data Model in MVC application?

Lets consider default ASP.NET MVC application folder structure, so it's looks like this:

-App_data
-Content
-Controllers
    HomeController.cs
-Models
    AccountModels.cs
-Scripts
-Views

开发者_高级运维

My question is: Where is the best place to put Entity Framework Data Model (EDMX) file? Is it Models folder? Yes - we know that good solution is to introduce new Project and reference it to MVC application, but lets forget about this now.

---

For a small project, it should be part of the Model. For a larger product, the repository and the associated model could be in a separate assembly.

---

Well this is debatable, but i'd vote +1 for the Models folder.

The only other candidate would be App_Data, but this is generally for file-based databases (SQL Server CE .MDF, for example) and files you don't want served by IIS.

As the EDMX is an abstraction of the database, it should go into the Models folder.

If the project gets bigger, you should definetely move your EF Model into another project. To future-proof yourself from this, make your Controllers access the EDMX via Repository/Interfaces, so when you move the DAL over to another project, all you'll have to do is add the reference and add in the using statements.

---

I would put the EF-model (aka physical model) always in its own assembly or in a "core" assembly outside of main MVC application. The same applies for your business-logic / domain-logic / domain-services / etc. Separate the non-web stuff from the MVC-Web-Application.

This will help you re-use the core part of your app. For example when you need to expose it as a service, a command-line tool, migration-tool, etc.

Because storing this in its own assembly is so easy and takes you a few minutes I highly recommend doing this for each and every tiny app too.

---

My opinion is that you should create

1. a separate project for domain objects, datacontracts etc. etc... Like MyProject.Infrastructure including many folders like DataContracts, Model, Exceptions etc.
2. a separate project for DataAccess wich contains the DBContexts and the Repositories, this way you can easily manage migrations later on