MVC3 and Entity Framework

Question

My question is pretty simple: is it a good practice to place the .edmx file in the model folder in a Web application of an MVC3 project?

Housel

Answer 1

my answer is pretty simple, do not mess up presentation layer (Whole MVC application) with data access logic and data modeling.

Have at minimum 4 projects in your Visual Studio Solution, from bottom to the top:

1 - ProjectName.Interfaces (Class library, entities's interfaces);

2 - ProjectName.DAL (Class library, the only one allowed to even know the EF is used, the POCO entities implement the interfaces of project 1 using another file where you redeclare same objects using partial classes...);

3 - ProjectName.BL (Class library, Business logic, references the two projects above 1 and 2);

4 - ProjectName.Web (ASP.NET MVC application, Presentation Layer, references two projects 1 and 3 but NOT 2);

this to simplify things of course, based on my experience this is a solid design, a bit overkilling for very small projects but pays off in the long term.

in my view, the M of MVC, Model, is NOT the data model, is not the EF, is not there to do ORM bound to the specific database engine.

this answer is subjective of course and is based on my personal experience ;-)

Mineralogist

The further your point about the M in MVC... it's the Presentation Model. It's the model representing the knowledge and information needed to display the screen to the end user. After all, ASP.NET MVC is a UI framework, nothing more, nothing less. – Leakey

Yep and i see so many projects where that M is forced to be and is understood as the data model. :-( – Mineralogist

do you have a tutorial of this architecture, so I can see this in a work example? – Housel

@Housel #7510896 – Weed

I'm glad it help, it's always with this little things that we start to code in the correct way... I was once in your shoes. – Weed

folks let's don't forget that in some cases (or most of the Real World scenarios with big codebase) it's a good practice to split layers into different solutions and not all projects in the same Visual Studio Solution file. This for better team sharing and concurrent work and also in my opinion for cleanliness, of course then you would need to set up a build script or use any build agent or msbuild, but it pays off... – Mineralogist

Great answer Davide. Can I add that I usually add a project for unit tests. So I would usually use ProjectName.Interface, ProjectName.Data, ProjectName.BL, ProjectName.Web and ProjectName.Test. Within the test project I would create a folder per project. Naturally the test project would have to reference all projects. – Excruciating

@Davide, "ProjectName.Web (ASP.NET MVC application, Presentation Layer, references two projects 1 and 3 but NOT 2);". What if you do an IOC ? In that case it will refer 1 and 3 and 2 also for injection by Container – Yusem

DavidePiras & @Scott Mitchell: if i'm getting you guys right then in a wpf-MVVM application the "Model-M" in "MVVM" is not the domain-model of the application? and, since domain-model isn't supposed to sit in Presentation layer, i need to introduce a model for presentation purpose only? – Vocative

I know is quite old, but is not clear to me how @Cilla implements the BL .. could you provide a short example? I don't know how do you implements the models (and where). If I don't understand bad, Models should be in Business Layer but you talk about implement the POCO entities in the DAL .. I thought to use just the interfaces in DAL, but probabably I'm missinig something – Cilla

It needs to be stressed more in introductory MVC guides that the Model in MVC models the View, not the Domain. +1. – Graaf

Hi Davide Piras! I have some questions about this answer, could you please shed your light on this? https://mcmap.net/q/357777/-ef-n-tier-architecture-closed – Augustina

Answer 2

I agree with Davide here completely I just want to add that you should also consider using the POCO templates to generate poco objects and not return entity framework objects to another layer because it then puts a dependency on the entity framework.

At some inevitable point if you don't pluck this out into a separate project, your direct data access code ends up thrown into your web code. I see it all the time (and we've all been guilty of it at some time)

Homerus

Answer 3

I don't think this matters much.

I use CodeFirst, so my DbContext class goes to the Model folder.

Really, the EDMX is there just for the code generation, beyond that it does not do much, its not deployed/published to your server, etc. So where it stays isn't important. You could create another folder for it EDMX if you want, or put it in Model as you asked.

Ablepsia

it matters a bunch though. you have a dependency in your web project tightly coupling it to the entity framework and a particular implementation of a data access technology that could quite likely change at some future point to either a different version, different technology, no entity framework, etc. it helps sprinkle data access code all over the place, a plague of web applications. – Homerus

But that has nothing to do with the EDMX file, which is just the model specification... on compile it generates other files which get deployed. But the location of the EDMX is irrelevant. – Ablepsia

It has a lot to do with it. They will be generated in the project the edmx file is in why you would try to do it any other way would be messy. – Homerus

Okay I think we're interpreting the question differently. Yes, davide's answer is a great way to structure the projects in an application and I gave him a vote as well. However, IF we were talking about a single project ( a single project only as the question implies) then the location of the edmx within that project is irrelevant. And that's what I was answering. – Ablepsia

some of us get picky on here and try to teach a 'more correct' approach - but point taken : ) – Homerus