Updated 2009-12-30 – Adjusted the title to be a general post about the Repository pattern, added links to other posts, forum entries and information, slightly re-organized.
I’ve been looking at the general problem of developing an API and the issues that result, and this is in the context of the repository pattern particularly. Though I don’t think the issues are any different when not using the repository pattern. You still need to be able to load the data you need and avoid issues like: If I Eager load I’ll have way to much data, if I load it when i need it I’ll be opening connections all over the place. With the repository pattern you break the practice of separation of concerns if you inject a reference to any required repositories or services etc. If you actually just provide somewhere on an entity to put it’s sub-entity or a collection and only load it when you need it… well that just doesn’t feel right at all…
Definition of the Repository Pattern
The lazy Loading Approach
- The story of the Lazy-Loading Lunchbox
- Is a Crisp a Value Object?
- Lazy Loads and persistence ignorance (part 1)
- Lazy Loads and persistence ignorance (part 2)
The Non Lazy Loading Approach
Use the Repository Pattern
- Repository is Dead: Long Live Repository – Discusses Versioning of Repositories issue regarding named query methods: The Open Closed Principle
Don’t Use the Repository Pattern
Examples and others