[Composite UI] [ob builderstrategy extension (1)] Cab builderstrategy Overview

 

**************************************** ****************************
*Copyright Notice
*
* This document uses the Creative Commons release. Please strictly abide by this authorization protocol.
* This article was first published onBlogThis statement is an integral part of this article.
* Author's network name: prodigal son
* Author email: Dayichen (AT) 163.com
* Author's blog: Http: // www. cnblogs. com/walkingboy
*
**************************************** ****************************

[Cab] [ob builderstrategy extension (I)] overview of cab builderstrategy

-Written by prodigal son @ cnblogs.com (06-09-21)

Abstract:

Those who have read the cab must be amazed at the flexible application of the attribute in the cab. It allows developers to obtain the desired XX from the cab simply by attaching the relevant atrribute. And so convenient development method, behind the IOC/di idea for guidance, relying on OB (OB related knowledge, refer to: http://www.cnblogs.com/walkingboy/category/56479.html) to achieve. This seriesArticleTry to get a deeper understanding of how cab generates this flexible development mechanism from the perspective of how cab applies ob.

Which builderstrategy is extended by cab and which builderstrategy is applied?

 
Public Abstract ClassCabapplication <tworkitem> where tworkitem: workitem,New()
 

 
You can see how many policies are applied to the cab and how they work together.
 

PrivateBuilder createbuilder ()
{
Builder =NewBuilder ();

builder. strategies. addnew (builderstage. initialization);
builder. strategies. addnew (builderstage. initialization);
builder. strategies. add ( New rootworkiteminitializationstrategy ( This . onrootworkiteminitialized), builderstage. initialization);
builder. strategies. addnew (builderstage. postinitialization);

Builder. Policies. setdefault <isingletonpolicy> (NewSingletonpolicy (True));
Builder. Policies. setdefault <ibuildertracepolicy> (NewBuildertracesourcepolicy (NewTracesource ("Microsoft. Practices. objectbuilder")));
Builder. Policies. setdefault <objectbuiltnotificationpolicy> (NewObjectbuiltnotificationpolicy ());

ReturnBuilder;
}

It can be seen that cab has not made any extension to the precreation. The key lies in the initialization and postinitialization stages after the object is created.

Extended in Initialization

• Eventbrokerstrategy: used to process event publishing and subscription
• Commandstrategy: used to process the association between commands and events
• Rootworkiteminitializationstrategy: used to process other initialization tasks of rootworkitem

Extended in postinitialization

• Objectbuiltnotifstrategstrategy: Object creation Notification Service

Although there are four extension policies, cab only enables singletonpolicy, buildertracesourcepolicy, and objectbuiltnotificationpolicy by default. Where are these policies enabled? Search the entire source code and find that only the workitem contains the policy setting.

 Protected   Internal   Void Buildup (){ // We use guid. newguid () to generate a dummy ID, so that the workitem buildup sequence can // Run (the workitem is already located with the null ID, which marks it as a service, so  // The singletonstrategy wocould short circuit and not do the build-up ). Type type = GetType (); String Temporaryid = guid. newguid (). tostring (); propertysetterpolicy proppolicy = New Propertysetterpolicy (); proppolicy. properties. Add (" Parent ", New Propertysetterinfo (" Parent ", New Valueparameter ( Typeof (Workitem ),Null ); Policylist policies = New Policylist (); policies. Set <isingletonpolicy> ( New Singletonpolicy ( False ), Type, temporaryid); policies. Set <ipropertysetterpolicy> (proppolicy, type, temporaryid); builder. buildup (locator, type, temporaryid, This , Policies );}

Are you confused? In fact, I went into a misunderstanding. In my ob-related articles, I wrote a conclusion that how the builderstrategy of OB works is determined by the relevant builderpolicy. Builderstrategy in cab does not use builderpolicy to restrict builderstrategy applications.

So does cab only have builderstrategy?

Of course, these policies are not enough. These are just the core builderstrategy, or "unrelated UI builderstrategy ".

On the contrary, there are some UI-related builderstrategy in cab. Let's take a look at the winform application.ProgramCabapplication

 
Public Abstract ClassCabapplication <tworkitem> where tworkitem: workitem,New()
 

 
In
 

 
/// <Summary>/// May be overridden in a derived class to add strategies to the <see CREF = "Builder"/>./// </Summary>Protected Virtual VoidAddbuilderstrategies (Builder ){}
 

 
This method is a way to add custom builderstrategy to the subclass.
 

 
For example, in the subclass windowsformsapplication
 

/// <Summary>/// Adds Windows Forms specific strategies to the builder./// </Summary>Protected Override VoidAddbuilderstrategies (Builder) {builder. strategies. addnew <winformservicestrategy> (builderstage. initialization); builder. strategies. addnew <controlactivationstrategy> (builderstage. initialization); builder. strategies. addnew <controlsmartpartstrategy> (builderstage. initialization );}

It can be seen that the subclass inherited from cabapplication still has the possibility of expanding the OB creation policy. In windowsformsapplication, three creation policies for winform are extended.

Assuming that we have implemented a new webformsapplication, we may need to create builderstrategy, which is closely related to the web UI.

Summary:

It can be seen that builderstrategy in cab can be divided into two categories: irrelevant UI and UI-related.

In the future, I will analyze each internal mechanism of builderstrategy and Its Role in cab one by one based on my own study steps.

Note:

-------------------------------------------------

• Cab: Composite UI Application Block for short, site: Patterns & Practices-composite UI Application Block
• Ob: objectbuilder for short, site: Patterns & Practices-object Builder