[翻译] Aggregator Provider模式——白皮书
[翻译] Aggregator Provider模式——白皮书
原文地址：http://code.msdn.microsoft.com/Project/Download/FileDownload.aspx?ProjectName=agpp&DownloadId=5402
译文地址：http://www.cnblogs.com/AndersLiu/archive/2009/04/11/aggregator-provider-pattern-white-paper.html
翻译：Anders Liu
摘要：Aggregator Provider Pattern是Provider Pattern的一种扩展，用于创建和利用多个具有相同提供器接口的类的实例。该模式有一个Aggregator类实现了提供器接口，并包含了一系列实现了相同提供器接口的类的实例集合。
Definition
定义
Aggregator Provider Pattern is an extension of Provider Pattern, which enables us to create and utilize multiple instance of the class having the same provider interface. In this pattern, there is an Aggregator class which implements the provider interface and contains a collection of instances of classes having the same provider interface.
Aggregator Provider Pattern是Provider Pattern的一种扩展，用于创建和利用多个具有相同提供器接口的类的实例。该模式有一个Aggregator类实现了提供器接口，并包含了一系列实现了相同提供器接口的类的实例集合。
The underlying caller class of this aggregator is simply unaware of how many provider instances do the caller Provider Aggregator contains, but all of the provider instances will be utilized with a single invocation from the caller class.
这个聚合器的潜在调用方类并不知道Provider Aggregator中包含多少个提供器实例，但在调用方类发起的一次调用中，所有的提供器实例都会被调用到。
Comparison with Provider Pattern
与Provider Pattern的比较
Provider Aggregator Pattern is fully compatible with the existing Provider Pattern and the power of provider pattern can be easily extended to use multiple providers concurrently without any modification on the caller classes that were using a provider.
Provider Aggregator Pattern与现有的Provider Pattern完全兼容，而且Provider Pattern的功能可以很方便地扩展到同时使用多个提供器，而无需对使用提供器的调用方进行任何修改。
In short Provider Pattern is concerned with the utilization of one of the available providers; whereas Aggregator Provider Pattern is concerned with the utilization of all of the available providers at the same time.
简单来说，Provider Pattern考虑的是如何调用可用的提供器中的某一个，而Aggregator Provider Pattern考虑的是如何同时调用所有可用的提供器。
Example Demonstration
示例演示
Aggregator Provider Pattern is useful when we need a configurable framework to add/remove multiple services used by one caller/user. For instance we can have Logger Provider framework, where we need log info to be saved at text files, save to database and sent to email addresses and so on. Having an easy configurable framework along with Aggregator Provider Pattern will enable us to add or remove more services without requiring the code modification in the code that uses this provider.
当我们需要一个可配置的框架，用于为调用方/用户添加/移除多种服务时，就可以使用Aggregator Provider Pattern。例如我们有一个Logger Provider框架，我们需要将日志信息保存到文本文件、保存到数据库并向指定的地址发送email。具有一个一个应用了Aggregator Provider的简单可配置框架，我们可以添加或移除更多的服务，而无需修改使用该提供器的代码。
Regarding the example case that just been described can utilize the Aggregator Provider Pattern, by creating the classes as illustrated above. The code snippet below shows a basic usage of this pattern, where the last line will perform the log operation based in list of log providers loaded in the aggregator class dynamically.
上面通过创建类图的方式描绘了一个案例。下面给出的代码片段给出了该模式的基本使用方式，最后一行代码基于在聚合器类中动态加载的一系列提供器执行了log操作。
（完）
后记
我在最近的一个项目中使用了Provider模式，恰好也是日志相关的，我遇到了同样的问题——需要将日志同时放入文本文件、数据库和系统的EventLog中。这时，传统的Provider模式的确难以满足需求，不过我的解决方案很简单——从配置文件中加载所有的Provider，放在一个集合里，然后每次需要记录日志时，遍历集合中的所有Provider，完成调用。
后来我想到了Façade模式，仿照Façade的思想，写了一个方法来协助我遍历这个集合。然后代码就这样固定下来了。
现在想想，那个辅助方法的签名，不是喝Provider接口中的方法签名一样么？如果能多走一步，不就得到了这里所说的Aggregator Provider模式了么？
不过，就算这样做了又如何？我能认为我发现了一种新模式么？
就算我认为发现了一种新模式又如何？会有人认同么？因为这实在是太简单了，当大家遇到类似问题时，多想一下一定会发现这种模式的。如果这样一篇文章直接出现在博客园的首页，恐怕负面评论要多过正面的。
中国人是聪明、勤劳的，模仿能力和举一反三的能力都很强，但却缺乏创新。为什么会缺乏创新呢？我认为是缺乏被认可。
所以借这个机会，我想呼吁博客园的各位专家牛人和粪青达人，从我做起，做到“认可”先。希望不管首页出现多么“新手”、“小白”、“不自知之明”的文章，我们都应首先做到鼓励。要知道这也许是一个新人创新的开始，一个“建议发到新手区”或者“这样的文章也上首页”，也许就浇灭了一朵创新的火种。
（完，这次是真的完）
