MVC3 and Entity Framework

Solution 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 ;-)

Solution 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)

Solution 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.