Are they the same thing? Just finished to watch Rob Connery's Storefront tutorial and they seem to be similar techinques. I mean, when I implement a DAL object I have the GetStuff, Add/Delete etc methods and I always write the interface first so that I can switch db later.
Am I confusing things?
DAO would be considered closer to the database, often table-centric. Repository would be considered closer to the Domain, dealing only in Aggregate Roots. Repository could be implemented using DAO 's, but you wouldn't do the opposite. Also, a Repository is generally a narrower interface.
Comparing the Two PatternsDAO is an abstraction of data persistence. However, a repository is an abstraction of a collection of objects. DAO is a lower-level concept, closer to the storage systems. However, Repository is a higher-level concept, closer to the Domain objects.
Repository Pattern Helps Hide SQL Complexity Now when using ORM the complexity of querying the database is hidden behind these kind of frameworks. So unless you're using SQL directly and you want in memory representation of your database objects, using repository doesn't make any sense.
The Repository pattern makes it easier to test your application logic. The Repository pattern allows you to easily test your application with unit tests. Remember that unit tests only test your code, not infrastructure, so the repository abstractions make it easier to achieve that goal.
You're definitely not the one who confuses things. :-)
I think the answer to the question depends on how much of a purist you want to be.
If you want a strict DDD point of view, that will take you down one path. If you look at the repository as a pattern that has helped us standardize the interface of the layer that separates between the services and the database it will take you down another.
The repository from my perspective is just a clearly specified layer of access to data.Or in other words a standardized way to implement your Data Access Layer. There are some differences between different repository implementations, but the concept is the same.
Some people will put more DDD constraints on the repository while others will use the repository as a convenient mediator between the database and the service layer. A repository like a DAL isolates the service layer from data access specifics.
One implementation issue that seems to make them different, is that a repository is often created with methods that take a specification. The repository will return data that satisfies that specification. Most traditional DALs that I have seen, will have a larger set of methods where the method will take any number of parameters. While this may sound like a small difference, it is a big issue when you enter the realms of Linq and Expressions. Our default repository interface looks like this:
public interface IRepository : IDisposable { T[] GetAll<T>(); T[] GetAll<T>(Expression<Func<T, bool>> filter); T GetSingle<T>(Expression<Func<T, bool>> filter); T GetSingle<T>(Expression<Func<T, bool>> filter, List<Expression<Func<T, object>>> subSelectors); void Delete<T>(T entity); void Add<T>(T entity); int SaveChanges(); DbTransaction BeginTransaction(); }
Is this a DAL or a repository? In this case I guess its both.
Kim
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With