In search of Wild Repository. Today I'm going to hack deep into the open source jungle to search for examples of wild repository. We'll be able to see the way that this species mutated into many divergent forms, and maybe learn some lessons about growing our own domestic repository on the way. There's a lot of discussion about what a repository should be. I'm just going to be looking at generic repositories in this post, but it's worth noting that many people have the opinion that such a thing should not be blessed with the name repository; saying that it is merely a generic DAO. I'll leave these semantic arguments for another day. As I was finishing this post, I came upon DDD Repositories in the wild: Colin Jack by Tobin Harris.
It just goes to show that I don't have a single original idea :P Rhino Commons I first heard tell of the generic repository in this excellent article by Ayende (AKA Oren Eini) on Inversion of Control containers. Wow, it's huge! Sharp Architecture The collection type of choice here is List<T>. New Repository<T>().DoMagic() - Karl Seguin. The purpose behind the repository pattern is to provide a layer of abstraction between your domain and data layer. For smaller projects, this typically isn’t needed. However, larger projects can really benefit from a broker that specifically handles the back and forth between the two layers.
With repositories your domain objects aren’t burdened with infrastructure details and can therefore better focus on domain-specific behavior. Without A Repository To build this up to our grand finale (a generic repository), let’s look at how you might do things in a small project without a repository. Public class User { private int _id; … public void Delete() { Factory.Get<IDataStore>().DeleteUser(_id); } } Of course, our User class will likely need a Save and various Find methods.
Public void Delete() { _isActive = false; Factory.Get<IDataStore>().Update(this); } With non-generic Repositories Generic Repository First thing first, we start with some basic stuff: public interface IEntity { int Id{ get; } } The Mostly Clean Coder - NHibernate. The Repository Pattern – I’m Sold! Lately, I've been playing with NHibernate and the Repository pattern - and struggling with it a bit.
I understand the concept, but it's the implementation that's been bothering me. I was questioning whether to use one repository, or to have many - essentially one per entity. You can see me questioning it a bit in the Entities And Repositories Discussion I posted a while ago, where I asked Nate Kohari whether he used one repository or many. Here's the relevant part of that conversation. I've filtered it quite a bit to capture our back and forth. RossCode: nkohari: do you have one repository or multiple repositories?
I didn't have a very good understanding of NHibernate at the time, and I certainly didn't get what he meant by query objects. Fast forward to this past week. So I went back to the tribe, and asked for some advice. So what exactly did I do? I also added some code. Let's start with the Repository class: 1: public class Repository<T> : IRepository<T> 7: Session = session; Code Insanity: Implementing Repository and Specification pattern.