Generic Repository vs. ObjectSet

Question

There seems to be a common agreement in the blogosphere, that one of the great features of the Entity Framework 4 is the ability to create generic repositories on top of the generic ObjectSets. Example implementations of generic repositories are basically wrappers around an ObjectSet, that simply translate method calls. There is no meaningful logic going on. After some thinking I have come to the point where I was asking myself: What benefits does a generic repository give me, that the ObjectSet itself doesn't already provide? The ObjectSet has all the required functionality (CRUD). Since it implements IEnumerable (and even IQueryable) it offers all the Linq extensions that make it very easy to specify exactly what data you want. What exactly justifies going the detour via some IRepository, as opposed to simply using the IObjectSet directly as my interface for the data access layer?

Thanks and regards,

Peter.

Answer 1

The reason for implementing the repository pattern is to make mocking datasources easier for automated unit testing.

If your model context implements an interface (say IRepository) and your business logic classes allow an IRepository object to be passed in via a constructor (dependency injection), unit tests can create their own IRepository data objects and pass these to unit tests. That means you can unit test without database support which is far simpler and more reliable than testing against an external database.