Repository Pattern vs DAL

Question

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 G

Answer 1

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

Answer 2

In the external world (i.e. client code) repository is same as DAL, except:

(1) it's insert/update/delete methods is restricted to have the data container object as the parameter.

(2) for read operation it may take simple specification like a DAL (for instance GetByPK) or advanced specification.

Internally it works with a Data Mapper Layer (for instance entity framework context etc) to perform the actual CRUD operation.

What Repository pattern doesn't mean:-

Also, I've seen people often get confused to have a separate Save method as the repository pattern sample implementation besides the Insert/Update/Delete methods which commits all the in-memory changes performed by insert/update/delete methods to database. We can have a Save method definitely in a repository, but that is not the responsibility of repository to isolate in-memory CUD (Create, Update, Delete) and persistence methods (that performs the actual write/change operation in database), but the responsibility of Unit Of Work pattern.

Hope this helps!

Answer 3

Repository is a pattern, this is a way to implement the things in standardized way to reuse the code as we can.

Answer 4

A repository is a pattern that can be applied in many different ways, while the data access layer has a very clear responsibility: the DAL must know how to connect to your data storage to perform CRUD operations.

A repository can be a DAL, but it can also sit in front of the DAL and act as a bridge between the business object layer and the data layer. Which implementation is used is going to vary from project to project.

Answer 5

It's all about interpretation and context. They can be very similar or indeed very different, but as long as the solution does the job, what is in a name!

Answer 6

I was looking for an answer to a similar question and agree with the two highest-ranked answers. Trying to clarify this for myself, I found that if Specifications, which go hand-in-hand with the Repository pattern, are implemented as first-class members of the domain model, then I can

• reuse Specification definitions with different parameters,
• manipulate existing Specification instances' parameters (e.g. to specialize),
• combine them,
• perform business logic on them without ever having to do any database access,
• and, of course, unit-test them independent of actual Repository implementations.

I may even go so far and state that unless the Repository pattern is used together with the Specification pattern, it's not really "Repository," but a DAL. A contrived example in pseudo-code:

specification100 = new AccountHasMoreOrdersThan(100)
specification200 = new AccountHasMoreOrdersThan(200)

assert that specification200.isSpecialCaseOf(specification100)

specificationAge = new AccountIsOlderThan('2000-01-01')

combinedSpec = new CompositeSpecification(
    SpecificationOperator.And, specification200, specificationAge)

for each account in Repository<Account>.GetAllSatisfying(combinedSpec)
    assert that account.Created < '2000-01-01'
    assert that account.Orders.Count > 200

See Fowler's Specification Essay for details (that's what I based the above on).

A DAL would have specialized methods like

IoCManager.InstanceFor<IAccountDAO>()
    .GetAccountsWithAtLeastOrdersAndCreatedBefore(200, '2000-01-01')

You can see how this can quickly become cumbersome, especially since you have to define each of the DAL/DAO interfaces with this approach and implement the DAL query method.

In .NET, LINQ queries can be one way to implement specifications, but combining Specification (expressions) may not be as smooth as with a home-grown solution. Some ideas for that are described in this SO Question.