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?
相关问题
- Carriage Return (ASCII chr 13) is missing from tex
- Generic Generics in Managed C++
- How to store image outside of the website's ro
- How to Debug/Register a Permanent WMI Event Which
- 'System.Threading.ThreadAbortException' in
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 ;-)
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.
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)