asp.net-mvc 存储库模式与 DAL

Repository Pattern vs DAL

提问by Mike

Are they the same thing? Just finished to watch Rob Connery's Storefront tutorialand 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.

它们是一样的吗？刚刚看完Rob Connery 的 Storefront 教程，它们似乎是相似的技术。我的意思是，当我实现一个 DAL 对象时，我有 GetStuff、Add/Delete 等方法，我总是先编写接口，以便以后可以切换数据库。

Am I confusing things?

我在混淆事情吗？

回答by Kim Major

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.

如果你想要一个严格的 DDD 观点，那会让你走上一条路。如果您将存储库视为一种模式，它帮助我们标准化了分隔服务和数据库的层的接口，那么它会让您失望。

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.

有些人会在存储库上放置更多的 DDD 约束，而另一些人会将存储库用作数据库和服务层之间的便捷中介。像 DAL 这样的存储库将服务层与数据访问细节隔离开来。

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:

一个似乎使它们不同的实现问题是，通常使用采用规范的方法创建存储库。存储库将返回满足该规范的数据。我见过的大多数传统 DAL 都会有一组更大的方法，其中该方法将采用任意数量的参数。虽然这听起来像是一个小差异，但当您进入 Linq 和 Expressions 领域时，这是一个大问题。我们的默认存储库界面如下所示：

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.

这是 DAL 还是存储库？在这种情况下，我猜两者都是。

Kim

金

回答by Jeromy Irvine

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.

存储库是一种可以以多种不同方式应用的模式，而数据访问层有一个非常明确的职责：DAL 必须知道如何连接到您的数据存储以执行 CRUD 操作。

A repository canbe 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.

存储库可以是 DAL，但它也可以位于 DAL 之前，充当业务对象层和数据层之间的桥梁。使用哪种实现将因项目而异。

回答by pondermatic

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.

一个很大的区别是，DAO 是处理域中任何实体的持久性的通用方法。另一方面，存储库仅处理聚合根。

回答by Thomas Jung

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 ifSpecifications, which go hand-in-hand with the Repository pattern, are implemented as first-class members of the domain model, then I can

我正在寻找类似问题的答案，并同意排名最高的两个答案。试图为自己澄清这一点，我发现如果与存储库模式密切相关的规范被实现为域模型的一等成员，那么我可以

• reuseSpecification definitions with different parameters,
• manipulateexisting Specification instances' parameters (e.g. to specialize),
• combinethem,
• perform business logicon them without ever having to do any database access,
• and, of course, unit-testthem independent of actual Repository implementations.

• 重用具有不同参数的规范定义，
• 操作现有规范实例的参数（例如专门化），
• 结合它们，
• 对它们执行业务逻辑，而无需进行任何数据库访问，
• 当然，独立于实际的 Repository 实现对它们进行单元测试。

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

我什至可以说，除非Repository 模式与 Specification 模式一起使用，否则它不是真正的“Repository”，而是 DAL。伪代码中的一个人为示例：

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 Essayfor details (that's what I based the above on).

有关详细信息，请参阅Fowler 的规范论文（这是我上述内容的基础）。

A DAL would have specialized methods like

DAL 将具有专门的方法，例如

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 andimplement the DAL query method.

您可以看到这会很快变得麻烦，特别是因为您必须使用这种方法定义每个 DAL/DAO 接口并实现 DAL 查询方法。

In .NET, LINQ queries canbe 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.

在 .NET 中，LINQ 查询可以是实现规范的一种方式，但结合规范（表达式）可能不像使用本土解决方案那么顺利。在这个 SO Question中描述了一些想法。

回答by eglasius

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.

我个人的观点是，这都是关于映射的，请参阅：http: //www.martinfowler.com/eaaCatalog/repository.html。因此，存储库的输出/输入是域对象，在 DAL 上可以是任何对象。对我来说，这是一个重要的补充/限制，因为您可以为具有不同布局的数据库/服务/任何内容添加存储库实现，并且您有一个明确的地方可以专注于进行映射。如果您不使用该限制并在其他地方使用映射，那么使用不同的方式来表示数据可能会影响不应更改的代码。

回答by c00ke

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!

这完全是关于解释和上下文。它们可以非常相似，也可以非常不同，但只要解决方案可以完成工作，名称有什么意义！

回答by Xulfee

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

存储库是一种模式，这是一种以标准化的方式实现事物的方法，以尽可能重用代码。

回答by Shailesh

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.

使用存储库模式的优点是模拟你的数据访问层，这样你就可以在不调用 DAL 代码的情况下测试你的业务层代码。还有其他很大的优势，但这对我来说似乎非常重要。

回答by Jonathan Allen

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.

有人可能会争辩说，“存储库”是一个特定的类，而“DAL”是由存储库、DTO、实用程序类和任何其他所需的东西组成的整个层。

回答by Ashraf Alam

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

在外部世界（即客户端代码）存储库与 DAL 相同，除了：

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

(1) 它的插入/更新/删除方法被限制为以数据容器对象作为参数。

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

(2) 对于读取操作，它可能需要简单的规范，如 DAL（例如 GetByPK）或高级规范。

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

在内部，它与数据映射器层（例如实体框架上下文等）一起执行实际的 CRUD 操作。

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.

此外，我看到人们经常感到困惑，除了将插入/更新/删除方法执行的所有内存更改提交到数据库的 Insert/Update/Delete 方法之外，还有一个单独的 Save 方法作为存储库模式示例实现。我们可以在存储库中肯定有一个 Save 方法，但这不是存储库的职责来隔离内存中的 CUD（创建、更新、删除）和持久化方法（在数据库中执行实际的写入/更改操作），但是工作单元模式的职责。

Hope this helps!

希望这可以帮助！