存储库模式标准化方法 [英] Repository Pattern Standardization of methods
问题描述
我正在尝试找出存储库模式的正确定义。
All I am trying to find out the correct definition of the repository pattern.
我最初的理解是（非常愚蠢）
My original understanding was this (extremely dumbed down)
- 将业务对象与数据对象分开
- 在数据访问层中标准化访问方法。
我确实看到了两种不同的实现方式，并且在线上没有正式的示例，我见过的示例被藏在书中。
I have really seen 2 different implementation, and there are no formal examples online, the ones i have seen are tucked away in books.
实现1：
public Interface IRepository<T>{
List<T> GetAll();
void Create(T p);
void Update(T p);
}
public interface IProductRepository: IRepository<Product> {
//Extension methods if needed
List<Product> GetProductsByCustomerID();
}
实施2 ：
public interface IProductRepository {
List<Product> GetAllProducts();
void CreateProduct(Product p);
void UpdateProduct(Product p);
List<Product> GetProductsByCustomerID();
}
注意，第一个是通用的Get / Update / GetAll，等等，第二个是我将定义 DAO之类的更多内容。
Notice the first is generic Get/Update/GetAll, etc, the second is more of what I would define "DAO" like.
两者共享从数据实体中提取的内容。我喜欢，但是我可以用一个简单的DAO来做同样的事情。但是，第二篇文章标准化了我认为有价值的访问操作，如果您实施此企业范围的操作，人们将很容易知道存储库的访问方法集。
Both share an extraction from your data entities. Which I like, but i can do the same with a simple DAO. However the second piece standardize access operations I see value in, if you implement this enterprise wide people would easily know the set of access methods for your repository.
我误以为标准化的数据访问方式是这种模式不可或缺的一部分吗？如果两者都正确，那么为什么要选择执行实施2？
Am I wrong to assume that the standardization of access to data is an integral piece of this pattern ? If both are correct why would one choose to do implementation 2?
Rhino 关于实现1的文章不错，当然，MS的定义，实现2的示例为
Rhino has a good article on implementation 1, and of course MS has a vague definition and an example of implementation 2 is here.
推荐答案
我第二次引用Fowler的语录被oded引用。我想指出的是，他说的是 collection- like 界面。如何实现像接口这样的集合肯定取决于您，但是您也不能也不应该试图隐藏它代表远程数据源的事实。因此，它与内存中的集合有很大的不同，后者不需要将更改刷新到远程数据存储中。您的ORM或您自己的惯用解决方案的变更跟踪机制决定了这种变更对调用方的透明性。通常，删除操作需要明确标记，插入内容是可发现的（通过可达性持久性），更新有时也需要明确标记。将其与聚合根的复杂依赖性相结合，您会发现它并不是非常像集合。
I second the Fowler quote cited by oded. I want to point out that he said "collection-like" interface. How you implement the collection like interface is certainly up to you, but neither can nor should you try to hide the fact it represents a remote datasource. It therefore differs significantly from an in-memory collection, which does not need to flush changes to a remote data store. The change tracking mechanism of your ORM or your roll-your-own solution determines how transparent this can be made to the caller. Deletes usually need to be marked explicitly, inserts are discoverable (persistence by reachability) and updates sometimes need to be marked explicitly too. Combine this with the complicated dependencies of your aggregate roots and you'll see that's not very collection like.
没有规范的存储库实现之类的东西。
There is no such thing as "the cannonical repository implementation".
通用存储库基类的提倡者与喜欢自己实现每个存储库的提倡者之间一直在进行不停的战斗。尽管通用实现在简单的场景中很有吸引力，但是您经常会发现它是一个非常漏水的抽象。例如，您的某些聚合可能仅被软删除（可通过虚拟方法重写将其删除），而其他聚合可能根本不支持删除操作。
There is a constant battle going on between the advocators of a generic repository base class and those who prefer implementing each repository on its own. While the generic implementation is appealing in simple scenarios, you will very often find it to be a very leaky abstraction. For example some of your aggregates may only be soft-deleted (cistomizable via virtual method overrides) while others may not support a delete operation at all.
请确保您了解每种方法的含义，然后再决定采用哪种方法。格雷格·杨（Greg Young）对于通用存储库的优点有很好的介绍。
Make sure you understand the implications of each approach before deciding which route to take. Greg Young has a good post on the merits of generic repositories.
http://codebetter.com/blogs/gregyoung/archive/2009/01/16/ddd-the-generic-repository.aspx
这篇关于存储库模式标准化方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
