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 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 1

One of the new features in Entity Framework version 4 is "Code First" development. This will allow you to use regular C# (POCO) classes with entity framework. Once your classes are written this way, you could write a different implementation of the repository that persists those classes using a different mechanism.

ScottGu has a blog post containing more information.

Answer 2

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.

Answer 3

The entity classes created by EF's designer are there in your project, inside your "Model.Designer.cs". You can copy the code so that your entities remain on your project even if you remove your model or the references from EF. However, they are tightly coupled to EF, so you should strive for decoupling EF from your entity classes.

Until now, you had T4 templates that could help you with the decoupling, but they still would require some changes to the chosen T4:

• ADO.NET EntityObject Generator
• ADO.NET POCO Entity Generator
• ADO.NET Self-Tracking Entity Generator

EF4.1 brings a simplified API, DbContext, that improves your experience with EF when you want to decouple entity classes. With EF4.1 you get 3 approaches:

• Code First
  • you create the classes and EF creates the DB as it should be
  • classes won't go away when you remove references to EF
  • you won't have any designer
• Database First
  • if you already have a database, a model will be created for you on the designer
  • you can create your entity classes with the new T4 template DbContext Generator
• Model First
  • as you already do right now, you create your model in the designer
  • you can create entity classes with DbContext Generator

Now, answering your question:

How do I remove this dependency ?

1. Install EF4.1
2. Create your model (using Model-first approach)
3. Generate your database from your model
4. Generate your entity classes with DbContext Generator

See how you can do all this here: EF 4.1 Model & Database First Walkthrough.
You should read the series in ADO.NET Team Blog Using DbContext in EF Feature CTP5 Part 1: Introduction and Model (EF4.1 was formerly known as EF Feature CTP5).
You can get more details in my question: EF POCO code only VS EF POCO with Entity Data Model.

Answer 4

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.