存储库模式与 DAL

From what I understand they can mean basically the same thing - but the naming varies based on context.

For example, you might have a Dal/Dao class that implements an IRepository interface.

Dal/Dao is a data layer term; the higher tiers of your application think in terms of Repositories.

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!

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.

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

So in most of the (simple) cases DAO is an implementation of Repository?

As far as I understand,it seems that DAO deals precisely with db access (CRUD - No selects though?!) while Repository allows you to abstract the whole data access,perhaps being a facade for multiple DAO (maybe different data sources).

Am I on the right path?

One large difference is that a DAO is a generic way to deal with persistence for any entity in your domain. A repository on the other hand only deals with aggregate roots.

My personal opinion is that it is all about mapping, see: http://www.martinfowler.com/eaaCatalog/repository.html. So the output/input from the repository are domain objects, which on the DAL could be anything. For me that is an important addition/restriction, as you can add a repository implementation for a database/service/whatever with a different layout, and you have a clear place to concentrate on doing the mapping. If you were not to use that restriction and have the mapping elsewhere, then having different ways to represent data can impact the code in places it shouldn't be changing.

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.

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!

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

Advantage of using repository pattern is to mock your data access layer, so that you can test your business layer code without calling DAL code. There are other big advantages but this seems to be very vital to me.

One could argue that a "repository" is a specific class and a "DAL" is the entire layer consisting of the repositories, DTOs, utility classes, and anything else that is required.