Repository pattern with Entity framework
Repository pattern is used to abstract from particular database and object-relation-mapping technology(like EF) used. So I can easily replace (for example) my Entity framework mappings with Linq to SQL in the future if I decide to do so.
But when I use EF I have my entity classes from the model - that is they are generated from that visual diagram. If I use this generated entity classes in my repository and then decide to replace EF by something else then I will delete that visual entity diagram and that means also to delete classes right ?
The point I'm addressing is that my repository will be dependent on Entity framework, that is on data access layer because it will use classes generated by EF.
How do I remove this dependency ?
Also note that I use EF primarily because of its ability to generate everything from that visual diagram - I just design the diagram and let it generate database for me with all the foreign keys etc. I like that very much and don't want to even think about SQL commands.
Answer
A repository is always dependent on data access technology. It is the reason why people are using repositories - to wrap data access dependency to separate layer. If you decide to change data access technology (imho it is like 1% chance that you do it) you will have to create new repositories implementing the same interfaces as former ones.
Introducing repositoris will add a new layer of complexity. Repositories have their pros and cons. Introducing them just because "you can change data access approach in the future" is a bad reason. Do not design your application because of something can happen. Design the application based on current real requirements (an agile way) and refactor your code if a change is needed - that is the only way how to be competitive in the market. Features are selling your SW not its open architecture for any type of change (ok, there are exceptions but in such cases that open architecture is a top level requirement).
When using EF you have several choices how to create entities:
- Use cutom tool to generate Entity objects. This is default approach which creates "code behind" file for EDMX. It is the only available solution in EFv1 (.NET 3.5 SP1).
- Use T4 templates to generate Entity objects, POCOs, STEs or any custom entity types (you can modify generation logic). This is often used with EFv4.
- Write POCOs by yourselves. This can be used with EFv4 and it is always used with code first approach in EF 4.1.
If you expect that data access technolgy can change in the future use either the second or the third approach with POCOs. In the case of T4 templates you can simply copy generated POCOs or modify a project file so you will not lose them after deleting EDMX file.
If you are not sure if either second or third approach suits you check my answers to these questions:
- ADO.NET DbContext Generator vs. ADO.NET POCO Entity Generator
- EF POCO code only VS EF POCO with Entity Data Model
Because I somehow agree with @Patko's answer you should also check Ayende's blog. He has written several posts about over using repository and over architecting applications. He is writting about NHibernate but similar decissions can be made with EF. The only difference is that NHibernate offers better abstraction so the code using directly NHibernate is better testable.