Repository pattern with Entity framework

Question

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 framewo

Answer 1

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.