In domain driven design there is a concept called repository. It specifically applies to applications that are somehow tied to a data layer. In fact, the repository is an intermediary link between your application and the data layer (e.g. a RDBMS).
A repository includes a local data collection open for direct modifcations. Unlike a regular collection, a repository has the ability to validate passed items. For this article, I am going to follow the example described here - there is a sample Vehicle class that represents a completely arbitrary unit. You can easily adapt the examples described here to any situation.
A repository is basically an abstraction on top of existing collections that should generally have three basic methods (or access points):
- Find by ID
The basic structure might differ and you might even decide to follow what was known as CRUD - have methods for Create, Read, Update, Delete. I usually add a GetAll method to retrieve the entire list of objects as a generic collection.
NOTE: Some ORMs provide the basic repository structures for you so you won't have to work on those. A good example would be NHibernate.
At this point, it doesn't really matter what the ID is, as long as there is a unique identifier for a specific unit.
So here is a basic repository structure for vehicles.
public class VehicleRepository
internal Table<Vehicle> vehicles;
public VehicleRepository(string connectionString)
var context = new DataContext (connectionString);
vehicles = context.GetTable<Vehicle>();
public void AddVehicle(Vehicle vehicle)
public void RemoveVehicle(Vehicle vehicle)
public Vehicle GetByVIN(string VIN)
return (vehicles.FirstOrDefault(vehicle => vehicle.VIN == VIN));
This is the most basic repository to hold a collection of vehicles. By using built-in LINQ-to-SQL elements I am retrieving the table that fits the generic structure passed to GetTable. That way, I am actually retrieving a collection of objects I can run queries against.
But as you can see here, every addition or removal will be executed against a local collection without any effect on the database. To fix this, you need to submit changes and to do this you can implement a simple method:
public void SubmitChanges()
Given that you have this method in the repository, unless you submit the changes, the database will not be affected - this gives you the benefit of validating data that is passed to the repository before you can actually commit new entries. So I can create (or edit) a custom collection locally and make sure that everything is like it's supposed to be. I would like to mention, though, that for large collections of objects the preferred method would be working with the DB directly instead of keeping a large unused set of data objects in memory.
A great benefit I see in repositories is the fact that I am not directly linking the collection to the database. If I ever decide to switch data engines, I can do so in the data connectivity layer without ever touching the collections (other than passing a custom connextion string).
Repositories let the developer work in terms of objects rather than scalar values (although that is also possible). Therefore, you organize the plumbing inside the repository methods so that later on in your application you won't have to build entities manually from raw bits of data.
NOTE: To make the above model decoupled in the full meaning of the word, you can implement an IRepository<T> interface so that whenever you pass repositories around in your application, you won't directly require a specific implementation. This is generally good for complex applications and doesn't necessarily apply for projects where only a very limited object set is used.