存储库模式与 Asp.net 提供程序模型相同吗？
从Asp.net 2.0开始，就有了Provider模型。 在实现细节上，提供程序是从 ProviderBase 派生的类，它是一个抽象类而不是接口，但无论如何提供程序模型都在那里，因此我们只需编辑 web.config 就可以有不同的实现来换入换出。 例如，如果您创建一个博客应用程序，您可能有一个 BlogProvider ：ProviderBase，那么您可以拥有 BlogProvider 的实现，例如：SqlBlogProvider、OracleBlogProvider 甚至 MockBlogProvider 来进行测试。
现在，Repository Pattern越来越流行，我觉得它也是为了满足同样的需求，虽然在实现细节上，你通常使用接口，所以IBlogProvider，并且你会通过构造函数而不是属性注入不同的实现，但本质上我不这样做看不出这两种模式给我们带来的差异。
就我个人而言，我觉得 Provider Model 在实现上对我来说更自然。 那么，它们之间是否有区别，或者它们只是同一事物，只是不同社区赋予的不同名称？
如果对此有任何评论，我将不胜感激 谢谢， 射线。
Since Asp.net 2.0, there is the Provider Model. On the implementation detail, a provider is class derived from ProviderBase which is an abstract class rather than an interface, but anyway the Provider Model is there so that we can have different implementation to swap in the out by just editing the web.config. For example if you create a blog app, you may have a BlogProvider : ProviderBase, then you can have implementations of BlogProvider like: SqlBlogProvider, OracleBlogProvider and even MockBlogProvider for testing.
Now, Repository Pattern is getting popular, and I feel it is to satisfy the same need, though in the implementation detail, you normally use interfaces, so IBlogProvider, and you'd inject different implementations through constructors rather than properties, but essentially I don't see the difference in what these 2 patterns gave us.
Personally, I feel Provider Model is more natural for me in the implementation. So, is there a difference between them or they are just the same thing with different names given by different communities?
I'd appreciate any comments on this,
Thanks,
Ray.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
存储库和提供者模式重叠，但它们没有正式描述相同的事物。 我几乎会说存储库是提供者的子集。 在实践中，我认为存储库模式是出于特定需求（抽象存储库）而诞生的，并在社区中演变为更通用的抽象模式。 在这方面，它们已成为描述同一概念的不同术语。 然而，从最初的定义来看，它们的范围不同：
存储库模式的目的是从应用程序中抽象出数据存储库的细节。
Provider 模型的目的是从应用程序中抽象出任何事物的细节。 这可能是一个数据存储库，但它通常也是某种逻辑。
例如，在我们的应用程序中，我们有一个 ContextFactoryProvider，其中包含用于确定要使用哪个 ContextFactory 的不同类型的逻辑。 在这种情况下没有数据存储库； 纯粹是应用逻辑，需要任意改变； Provider 模型允许我们使用单一职责原则将每种逻辑隔离到自己的类中并轻松地替换该逻辑。
The Repository and Provider patterns overlap, but they don't formally describe the same thing. I would almost say the Repository is a subset of Provider. In practice, I think the Repository pattern was borne out of a specific need - abstracting repositories - and evolved in the community into a more generic abstraction pattern. In that respect, they have come to be different terms that describe the same concept. However, from the original definitions, they are different in scope:
The purpose of the Repository pattern is to abstract the specifics of a repository of data away from the application.
The purpose of the Provider model is to abstract the specifics of anything away from the application. This may be a data repository, but it is just as often some kind of logic.
For example, in our application we have a ContextFactoryProvider, which contains different kinds of logic for determining which ContextFactory to use. There is no repository of data in this case; it's purely application logic that needs to change arbitrarily; the Provider model allows us to use the Single Responsibility Principle to isolate each kind of logic into its own class and swap out that logic easily.
我不能同意 Rex M 的观点。提供者模式的目的是通过抽象接口提供对定制的支持，而存储库模式的目的是提供对抽象数据库细节的支持。
i can't agree with Rex M. The purpose of provider pattern is to provide support for customization via an abstract interface, where as the purpose of repository pattern is to provide a support to abstract the details of undelying database.