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.
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:
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:
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.
Having the ability to switch from one persistence techonology to another is nice and all, but do you really need it?
First of all, what is a repository? By Fowler's definition it provides an in-memory collection-like access to domain objects. But every modern ORM tool already does that, so another level of abstraction just adds a bit more complexity.
Second, switching from one persistence technology to another is usually more complex than just providing another repository implementation. For instance, how do you intend to handle transactions? Transactions usually depend on context and are handled outside repositories. You could of course use some kind of unit of work implementation, but then you would have to implement new unit of work for every persistence technology.
I do not mean to say that you should not use repositories, just maybe give it another thought.