需要提供者模式的替代方案
我正在维护一个 Web 应用程序，该应用程序利用如下所述的提供程序模式来进行配置。
http://msdn.microsoft.com/en-us/library/ms972319。 .aspx
http://msdn.microsoft.com/en-us/library/ms972370。 aspx
一切都工作正常，但是当我们向应用程序添加功能时，我们发现我们的提供程序已成为多个不属于在一起的不同功能的混搭。 我们正在考虑拆分配置提供程序，以便将类似的功能与其他类似的功能组织起来。 我们这样做是因为我们原来的提供程序现在有一些不需要由某些模块实现的功能。 在实现提供者时，我们不想只是在无关函数上抛出 NotImplementedException，而是根本不包含它们。
我们意识到我们可以使用上述 MSDN 方法创建多个提供程序，但多个提供程序只会在 web.config 中创建更多条目。 最好尽量减少 web.config 中的条目，因为它开始变大。
有没有人找到另一种方法来实现提供者模型？
I'm maintaining a web application that utilizes the provider pattern as described below, for configuration purposes.
http://msdn.microsoft.com/en-us/library/ms972319.aspx
http://msdn.microsoft.com/en-us/library/ms972370.aspx
Everything has been working fine, but as we add functionality to our application, we are finding that our provider has become a mash up of several different functions that do not belong together. We are contemplating splitting up the configuration provider so that like functions are organized with other like functions. We're doing this because our original provider now has a handful of functions that do not need to be implemented by some modules. Instead of just throwing NotImplementedException on the extraneous functions when implementing the provider, we would like to just not include them at all.
We realize that we could create multiple providers using the above MSDN method, but multiple providers would just create more entries in the web.config. It would be nice to minimize entries in the web.config, since that is starting to get big.
Has anyone found another way to implement the provider model?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以考虑使用控制反转 (IoC) 容器（Google“Castle Windsor”、StructureMap、AutoFac、NInject 或 Microsoft Unity）。 使用 IoC，您可以在配置文件中或在应用程序的开头配置“提供者”。
通常，您会为您拥有的每种类型的提供者创建接口。 使用接口，您可以轻松地分解您的提供商，但是这对您来说有意义。
一旦您拥有了接口，您就可以在需要时简单地向容器请求该接口的实现，容器将负责为您实例化提供程序。
You could look at using an inversion of control (IoC) container (Google "Castle Windsor", or StructureMap, or AutoFac, or NInject, or Microsoft Unity). Using an IoC you can either configure the "providers" in a configuration file or at the beginning of your application.
Typically you would create interfaces for each type of provider that you have. Using interfaces you could easily break up your providers however it made sense to you.
Once you have the interfaces in place you could simply ask the container for an implementation of that interface when you need it and the container will take care of instantiating a provider for you.
我相信您基本上可以使用任何允许配置的 IOC（其中大多数）来完成此操作。
我要做的方法是在代码中配置 AutoFac 以使用“已知”实现，但允许可选的“配置覆盖”。 因此，如果我们“转售”一个应用程序并且有人需要不同的实现，他们只需配置它即可。
在我的博客文章中阅读更多内容 - 希望该博客也能得到一些好的评论：http://healthedev.blogspot.com/2011/12/making-custom-built-applications.html
I believe you can essentially do it with any IOC that allows configuration (which is most of them).
The way I am going to do it is to configure AutoFac in code to use the "known" implementations, but allow an optional "configuration override". So if we ever "on-sell" an application and someone needs a different implementation, they could just configure it.
Read more on my blog post - hopefully the blog will get some good comments about it too: http://healthedev.blogspot.com/2011/12/making-custom-built-applications.html