当 .NET 2.0 出现时，我对当时推出的几种服务所使用的提供者工厂模式印象深刻......并开始在所有地方使用它。
但后来我遇到了真正的麻烦:
- 在 CE 上，没有配置系统，所以它不能轻易地移植到那个环境(因此导致代码中的严重 fork ，否则这些代码本来可以在两个框架上很好地工作，只需要一些修改)<
- 对于如何确保静态管理器包装了提供者的所有方法，我从来没有找到好的答案:providerBase 可以实现一个接口(interface)，但接口(interface)(AFAIK)不能用于静态方法。因此，包装提供程序和静态管理器之间总是存在分歧的机会。
- 样板代码的数量猛增，而我的工作效率反而下降了。我的意思是，不仅仅是调用 instance.Method();
我正在调用它，但是通过静态 Manager.DoWork() 调用它的实例的 DoWork()，它通常最终成为 ProviderBase 类中的通用代码，它检查参数，做一些工作，最后称为抽象 InternalDoWork()，它在 CustomProvider 类中实现...
换句话说......一种调用方法的非常曲折的方式(3 到 4 个方法，到处检查参数，不清楚在哪里尝试/捕获/登录 - 在管理器或 ProviderBase 中？ - 等等。
所以，我的问题是:是否有另一种模式可供我查看以提供配置文件配置功能，从而允许服务提供商的动态更改——好吧，至少在重新启动时？
PS:我最近听说 IoC/DOI 是一个可能更快的解决方案……虽然没有在生产中使用它。看起来很有趣...但是我的第一印象是DOI似乎可以交换服务，可以在配置文件中配置，但不能从配置文件中设置参数？
谢谢!
最佳答案
如果您想探索依赖注入(inject)，我推荐 Ninject或 StructureMap图书馆。有很多 StackOverflow 问题 about .NET IoC containers though ，所以只需搜索，您就会找到更多信息。
至于您的实际问题，趋势似乎是 Composition-based模型，而不是 Subtyping Provider 模型使用的一种。这似乎更接近于来自雷德蒙德的更新内容，例如 ASP.NET MVC .
关注组合意味着设计概述部件之间“具有”关系，而不是"is"关系。他们倾向于专注于定义更少的契约细节，并让特定的实现来处理如何履行契约，而不是强制构建路线(使用抽象方法)，这在基于子类型的设计中很常见，并且经常过度设计解决方案以实现具体实现。这两种方法都有缺点(例如，版本控制通常被认为是使用接口(interface)的基于组合的设计的挑战)，因此它可能取决于您在做什么。
总的来说，我认为依赖注入(inject)更适合应用程序代码，因为与定义严格的继承模型相比，组合您的应用程序通常会使它的耦合度降低，并且通常会使代码更容易进行单元测试。此外，许多通常与组合相关的问题对于应用程序代码的重要性不如它们对于框架的重要性(同样，版本控制)。事实可能介于两者之间，如在 MVC 中所见，组件之间的依赖关系使用简单的接口(interface)(组合)，但实现通用功能的基类也可用于仅继承和覆盖必要的部分。
这就是为什么 IoC 容器倾向于在这里提供帮助的原因，因为它们为系统提供了松散耦合的方式来请求组件，而无需了解任何关于实现的信息。例如，DependencyResolver.GetInstanceOf<IUserRepository>() .
关于c# - 有没有比使用 Provider Factory 模式更简洁的解决方案？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1174746/