存储库模式解决了什么具体问题？ [英] What specific issue does the repository pattern solve?
问题描述
（注意：我的问题与询问，但是从来没有回答过。）
我最近开始使用MVC3 +实体框架，我不断阅读，最佳做法是使用存储库模式集中访问DAL。这也伴随着您要保持DAL独立于域，特别是视图层的解释。但是在我看到的例子中，我看到的是（或者似乎是）只是返回DAL实体，即在我的情况下，存储库将返回EF实体。
所以我的问题是，如果只返回DAL实体，存储库有什么好处？这不会增加一层复杂性，不能消除在层之间传递DAL实体的问题？如果存储库模式创建了一个DAL中的单个入口点，那么与上下文对象有何不同呢？如果存储库提供了一种检索和保留DAL对象的机制，那么与上下文对象的不同呢？
另外，我至少读过一个地方，工作模式集中了存储库访问以管理数据上下文对象，但是我不介意为什么这也很重要。
我肯定是98.8％我在这里遗漏了一些东西，但是从我的阅读中我没看到。当然，我可能只是没有阅读正确的来源...：\
实体框架的 DbContext 基本上类似于存储库（和工作单元）。您不一定必须在简单的场景中抽象出来。
存储库的主要优点是您的域可以是无知的，与持久性机制无关。在基于层的架构中，依赖关系从UI层次下降到域（或通常称为业务逻辑层）到数据访问层。这意味着UI取决于BLL，它本身取决于DAL。
在更现代的架构中（由域驱动设计和其他面向对象的方法传播）域应该没有向外的依赖关系。这意味着UI，持久性机制和其他一切都应该取决于域，而不是其他方式。
然后，存储库将通过其界面域，但在域外的具体实现，在持久性模块中。这种方式只取决于抽象接口，而不是具体的实现。
基本上是在体系结构层面上的面向对象程序。 b
$ b
另请参见 端口和适配器 aka 六角架构 。
存储库的另一个优点是可以为各种数据源创建类似的访问机制。不仅适用于数据库，还包括基于云端的商店，外部API，第三方应用程序等。
(Note: My question has very similar concerns as the person who asked this question three months ago, but it was never answered.)
I recently started working with MVC3 + Entity Framework and I keep reading that the best practice is to use the repository pattern to centralize access to the DAL. This is also accompanied with explanations that you want to keep the DAL separate from the domain and especially the view layer. But in the examples I've seen the repository is (or appears to be) simply returning DAL entities, i.e. in my case the repository would return EF entities.
So my question is, what good is the repository if it only returns DAL entities? Doesn't this add a layer of complexity that doesn't eliminate the problem of passing DAL entities around between layers? If the repository pattern creates a "single point of entry into the DAL", how is that different from the context object? If the repository provides a mechanism to retrieve and persist DAL objects, how is that different from the context object?
Also, I read in at least one place that the Unit of Work pattern centralizes repository access in order to manage the data context object(s), but I don't grok why this is important either.
I'm 98.8% sure I'm missing something here, but from my readings I didn't see it. Of course I may just not be reading the right sources... :\
Entity Framework's DbContext basically resembles a Repository (and a Unit of Work as well). You don't necessarily have to abstract it away in simple scenarios.
The main advantage of the repository is that your domain can be ignorant and independent of the persistence mechanism. In a layer based architecture, the dependencies point from the UI layer down through the domain (or usually called business logic layer) to the data access layer. This means the UI depends on the BLL, which itself depends on the DAL.
In a more modern architecture (as propagated by domain-driven design and other object-oriented approaches) the domain should have no outward-pointing dependencies. This means the UI, the persistence mechanism and everything else should depend on the domain, and not the other way around.
A repository will then be represented through its interface inside the domain but have its concrete implementation outside the domain, in the persistence module. This way the domain depends only on the abstract interface, not the concrete implementation.
That basically is object-orientation versus procedural programming on an architectural level.
See also the Ports and Adapters a.k.a. Hexagonal Architecture.
Another advantage of the repository is that you can create similar access mechanisms to various data sources. Not only to databases but to cloud-based stores, external APIs, third-party applications, etc.
这篇关于存储库模式解决了什么具体问题？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
