[Translation] Aggregator Provider mode-White Paper

[Translation] Aggregator Provider mode-White Paper

Original address: 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.

Translation: Anders Liu

Abstract: Aggregator Provider Pattern is an extension of Provider Pattern. It is used to create and use instances of classes with the same Provider interface. In this mode, an Aggregator class implements the Provider Interface and contains a series of instances that implement the same provider interface.

Reference

Http://code.msdn.microsoft.com/agpp

Definition
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 is an extension of Provider Pattern. It is used to create and use instances of classes with the same Provider interface. In this mode, an Aggregator class implements the Provider Interface and contains a series of instances that implement the same provider interface.

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.

The potential caller class of this Aggregator does not know how many Provider instances are contained in the Provider Aggregator. However, in a call initiated by the caller class, all the Provider instances are called.

Comparison with Provider Pattern
Comparison with 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 is fully compatible with the existing Provider Pattern, and the Provider Pattern function can be easily expanded to use multiple providers at the same time, you do not need to make any changes to the caller using the provider.

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.

Simply put, Provider Pattern considers how to call one of the available providers, while Aggregator Provider Pattern considers how to call all available providers at the same time.

Example Demonstration
Example

Aggregator Provider Pattern is useful when we need a retriable 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 retriable 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.

You can use Aggregator Provider Pattern when you need a configurable framework to add/remove multiple services to/from callers/users. For example, we have a Logger Provider framework. We need to save the log information to a text file, save it to the database, and send an email to the specified address. With a simple configurable framework that applies Aggregator Provider One by one, we can add or remove more services without modifying the code that uses the Provider.

Regarding the example case that just been described can utilize the Aggregator Provider Pattern, by creating the classes as your strated 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.

The above describes a case by creating a class chart. The following code snippet shows the basic usage of this mode. The last line of code performs log operations based on a series of providers dynamically loaded in the aggregation class.

(End)

Postscript

I used the Provider mode in a recent project, which is also log-related. I encountered the same problem-the log needs to be put into the text file, database, and system EventLog at the same time. At this time, the traditional Provider mode is indeed difficult to meet the needs, but my solution is very simple-load all providers from the configuration file, put them in a collection, and every time you need to record the log, traverses all providers in the set to complete the call.

Later, I thought of the Fa C ade model. I wrote a method to help me traverse this set, following the thought of Fa C ade. Then the code is fixed.

Now let's think about it. Isn't the signature of the auxiliary method the same as that of the method in the Provider interface? If you can take one more step, won't you get the Aggregator Provider mode mentioned here?

But what if I did this? Can I think I have found a new model?

What if I think I find a new model? Will anyone agree? This is too simple. When you encounter similar problems, you may find this pattern when you think about it. If such an article appears directly on the homepage of the blog garden, I am afraid there will be more negative comments than the front.

The Chinese are smart and hardworking. They both have strong imitation capabilities and the opposite capabilities, but lack innovation. Why is there a lack of innovation? I think it is lack of recognition.

So with this opportunity, I would like to call on the experts of the blog Park, the ox and the dung green talents, to start from me and be "recognized" first. We hope that no matter how many "Newbie", "", and "not self-aware" articles appear on the homepage, we should first encourage them. You must know that this may be the beginning of a new employee's innovation. A "recommended Article is sent to the newbie area" or "such an article is also on the homepage" may have ruined an innovative fire.

(End, this is the end)