15

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.

Dariusz
  • 15,573
  • 9
  • 52
  • 68
  • 1
    **WHY** do you want to exclude the proper solution up front - of putting all of this stuff into a separate assembly?? It's the best and cleanest approach - **use it!** – marc_s Jan 17 '11 at 05:24

4 Answers4

19

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.

George Stocker
  • 57,289
  • 29
  • 176
  • 237
8

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.

RPM1984
  • 72,246
  • 58
  • 225
  • 350
1

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.

Marc
  • 4,715
  • 3
  • 27
  • 34
0

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
Kristóf Tóth
  • 791
  • 4
  • 19
  • Are two separate projects really necessary? Why not add domain classes and data access classes in one project. If you will have many different backend data stores possibly some non-relational then separate projects for domain classes and data access makes sense. – Tich -- Lil3p Jan 05 '18 at 03:33