Repository patterns are used to remove specific databases and object-relational mapping technologies (like EF) from the code. So if I wish to go from Entity framework to Linq to SQL in the future, it will be simple for me to do so.
However, when I use EF, my entity classes are produced from the model, or from that visual diagram. The visual entity model will be deleted, which implies that the classes will also be deleted, if I use these created entity classes in my repository and later decide to replace EF with something else.
My repository will be reliant on Entity Framework, or data access layer, since it will employ classes produced by EF, which is the issue I'm trying to solve.
How can I get rid of this dependency?
Also keep in mind that the main reason I choose EF is because it can create a database with all the necessary foreign keys and such from a visual model that I build. I really appreciate it and don't want to even consider SQL instructions.
Data access technology is never independent of a repository. Repositories are used to split data access dependence into a different layer, which is why people use them. You will need to build new repositories with the same interfaces as old ones if you decide to switch data access technologies (which, in my opinion, is unlikely to happen).
Repositories will introduce a new level of complexity. Repositories offer advantages and disadvantages. Introducing them for no other purpose than "In the future, you may adjust your data access strategy" is unacceptable. Don't plan your application based on potential outcomes. The only approach to remain competitive in the market is to design the application based on current actual needs (in an agile manner) and rewrite your code if a change is required. Your software's features rather than its adaptable design are what sell it (ok, there are exceptions but in such cases that open architecture is a top level requirement).
When using EF, you may construct entities in a number of ways:
Use the second or third POCOs approaches if you anticipate future changes in data access technology. You may easily duplicate created POCOs for T4 templates or change a project file to ensure that you keep them after removing the EDMX file.
If you're unsure whether the second or third technique is best for you, consider my responses to the following queries:
You should also check Ayende's website since I kind of agree with @Patko's response. He has produced several articles regarding excessive repository use and excessive application architecture. Although he is writing about NHibernate, EF may be be used to make similar decisions. The sole difference is that NHibernate provides greater abstraction, making it easier to test code that directly uses NHibernate.
Although having the option to change persistence technologies is wonderful, do you really need it?
Let's start by defining a repository. It gives access to domain objects that is similar to an in-memory collection. However, every contemporary ORM product already does that function, thus adding another level of abstraction just increases complexity.
Second, implementing a different repository is seldom as complicated as moving from one persistence system to another. How, for example, do you plan to manage transactions? Transactions are often handled outside of repositories and rely on context. Of course, using a unit of work implementation is an option, but doing so would require developing new units of work for each persistence technology.
Not that you shouldn't utilize repositories; just maybe give it some more thinking.