ASP.NET MVC using the Repository Pattern

Question

Currently im using EF and using its datacontext directly in all of my actions, but since i started reading about loose coupling and testability im thinking that thats not the be

Answer 1

Firstly, I'm not aware of a requirement for each entity to have it's own repository so I'd junk that restriction.

For Scott H's implementation, I assume you are referring to the Nerd Dinner app, which by his own admission isn't really the repository pattern.

The objective of the repository pattern is, as you surmise, to isolate the data store from the layers above it. It's not purely for testing reasons, it also allows you to change the backing store without affecting your UI/Business Logic.

In purist terms you would create POCOs that you would return from the Repository to your BL, by using an interface to define the Repository contract you could then pass and use the interface rather than a concrete implementation. This would allow you to pass in any object that implemented the Repository interface, whether your live repository or a mocked repository.

In reality I use a repository with MVC with Linq to SQL as my backing store which allows me a degree of flexibility over the actual backing store so I use hand crafted L2S objects in my BL, these have additional fields and functionality that isn't persisted to the backing store. This way I get some great functionality from the L2S aspects, change tracking, object hierarchy, etc, while also allowing me to substitute a mocked repository for TDD.