I am about to start work on a ASP.Net MVC 4 web application using Entity Framework Code First. Because the database already exists I am using Code First’s ability to perform Reverse Engineering in order to generate my domain classes.
I wish then to place these domain classes into a separate project of their own within my solution in order to keep them persistence ignorant. However, when I run the tool to reverse engineer my database (using Entity Framework Power Tools), I find that the domain classes are created, but also created is a folder called Mapping containing a mapping class for each domain class which then uses Fluent APIs to map the table properties. This is all good.
But, what I have also found, is that the mapping classes rely on a reference to the Entity Framework and I was just wondering is this thought to be poor practice? Usually when I create POCO classes, they are completely persistence ignorant, ie, there has been no reference to Entity Framework in that project at all.
Your thoughts?
Thanks.
You can keep your POCO classes in one project, while mapping stays in another project. Just add a reference to the project where POCO classes are located. Another approach is to create a data access layer and move mappings over there. That way you have three projects. Your main MVC project, your model project and data access layer that contains mappings and a reference to EntityFramework.
For example, your solution could be something like this:
All four projects have access to the fifth project, Domain Model (Models from EF Reverse Engineering). Your 1 communicates with 2, 2 communicates with 3 and 3 communicates with 4. All four of these have a reference to Domain Model so you don’t have to perform any type of domain model conversion between the layers.
By the way, I ignored service layer, but if you have web services or REST, you could fit it in another project, but let’s not get into too many details.