When working with an ORM such as Entity Framework, I've fallen into a comfortable habit. Make an interface with get/add methods on it, put this on a "Repository" class then add a constructor to each class that accepts the interface. Use the interface's methods in the class.
It seems the most straightforward way to gain an abstraction layer that I can then mock out for unit tests.
However, doing a bit of reading around the subject, there seems to be a lot of confusion over what the best approach is. Some examples include:
Using your ORM with the repository pattern (seems a bad idea, since most ORM's are already their own repository patterns).
Creating a reusable repository using generics and sharing it across projects (seems like overkill unless you're working with a vast amount of different projects).
Having a repository that includes more detailed data logic. I.e. with methods like "GetUsersWhereAdminIsTrue" rather than the more generic "GetUsers" (this would seem to lead to a repository with a massive list of methods).
Using IOC to allow unit testing of code without an external source without the need for an extra wrapper layer (I've seen this mentioned several times, but I don't understand it. Surely even with IOC you still need to inject an interface?)
The answer may be partly circumstantial. But I'd like to understand why people are proposing solutions in spite of the shortcomings that I've bracketed above?