In my ASP.NET application I want to implement by data acess layer using the Entity framweok so I can use it as an ORM tool. But I dont want the rest of the application to care that I'm using this or be polluted by anything entity frameowrk specific.
I cant seem to find anyone who is using the entity framework exclusively in their Data access layer so I'm keen to see any online examples of this/ experience people have.
http://ayende.com/Blog/archive/2007/06/08/Rhino-Commons-RepositoryltTgt-and-Unit-Of-Work.aspx
Look at the above example, you can implement entity framework in the same fashion using repository pattern
You could abstract the entity framework using something like the repository pattern like ScottGu does with Linq in the NerdDinner series.
this is DDD inspired architecture i've just worked up with EF v4 which uses Unity IoC to inject an EF repository, hope that helps
I have used Entity Framework as the data access on my last two projects. These are large (for me atleast) projects with several hundred tables, 5-15 developers lasting over a year.
In both projects we have a WCF interface into our service layer. We did not want to use the Entity Framework objects in our WCF Contracts. We therefore created Data Transfer Objects, and we map between DTO's and Entity Framework objects.
This breaks up the dependencies and keeps the contracts as stable as possible, but creates some extra work.
Depending on your time horizon I would do it like this or use the POCO objects in the next version, as Kieth mentioned.
The EF or any other ORM (i.e. NHibernate) doesn't replace your Data Access Layer. Rather, the ORM is an abstraction layer from the DAL to the data source.
Don't be fooled to believe that the EF does away with the DAL. The EF is just another data source framework. However, in best practice, you still want to abstract and centralize all access (read/write) in a common DAL.
Here's a perfect example of what I'm talking. Assume that you have to delete a given user in one of your use cases. However, when deleting the user, you may want to delete other records associated to the deleted user to avoid orphan records (To be honest with you, I would use a stored proc for this). Now this use case is stuck in some BO that is very specific to this use case and deleting as user is just one part of the total use case.
At some point in time you have a developer that is asked to incorporate a different use case that happends to involve, deleting a user! The developer may do a few things. 1) He might create a new use case that now involves deleting a user but forgot to delete any associated records to that user. 2) He may have noticed the previous use case but couldn't use it directly without over generalizing it for his use case, so he decided to copy part of that use case that properly deletes a user and its associated records, into his use case. Now we have duplicates parts the code that do practically the same thing - delete a user. Yuk! Now, having put this 'deleting user' in say a DAL.Users helper class, you avoid this bad design practice.
Anyway, the one nice thing about the EF, it reduces the number of Business Entities that I used to create manually and provides a different view of the data from an application level than what is seen in the data store level.