Prism Research (for WPF & Silverlight) 7. View injection and view discovery

Everything starts from here. The prism document is a bit harsh on the two concepts, or even self-defeating. I 'd better not read them.

We know that in each module, the module class that implements the imodule interface must implement the initialize method of this interface. On the one hand, we must register some custom interfaces and classes that implement this interface, prepare for the subsequent dependency injection. On the other hand, load the view for Region and display it (initialize the view ).

View loading methods include view injection and view discovery.

1. View injection refers to regionmanager, which is a collection class regioncollection and implements internal indexes based on regionname. Therefore, we can write the code as follows:

View-first:

This. regionmanager. Regions ["mainregion"]. Add (New helloworldview ());

Presenter-first:

This. regionmanager. Regions ["mainregion"]. Add (this. Container. Resolve

For the concepts of view-first and presenter-first, we will introduce them in the next section.

View injection:

Note: View injection is only applicable to regionmanager and not to regionviewregistry. Why? refer to my analysis below.

2. View discovery refers to the regionviewregistry's registerviewwithregion method. There are two reloads:

Public void registerviewwithregion (string regionname, type viewtype)

{

This. registerviewwithregion (regionname, () => This. createinstance (viewtype ));

}

 

Public void registerviewwithregion (string regionname, func <Object> getcontentdelegate)

{

This. registeredcontent. Add (regionname, getcontentdelegate );

This. oncontentregistered (New viewregisteredeventargs (regionname, getcontentdelegate ));

}

 

We can see that the 1st methods are based on the 2nd methods, that is, regionname and a delegate (an instance used to create a view) are registered to the listdictionary dictionary at the same time. <string, func <Object> and weakdelegatesmanager.

So we can write the code like this:

View-first:

This. regionviewregistry. registerviewwithregion ("mainregion", typeof (views. helloworldview ));

Presenter-first:

This. regionviewregistry. registerviewwithregion ("mainregion ",

() => This. Container. Resolve <ihelloworldpresenter> (). View );

 

For the concepts of view-first and presenter-first, we will introduce them in the next section.

View discovery View:

P18 In the prism document said that view discovery applies to v-first, while view injection applies to both V-first and p-first. This is inappropriate. After reading the analysis and code above, we will find that view discovery is also implemented in the p-first mode and is also very common.

View injection and view discovery are two different classes-different implementation methods of regionmanager and regionviewregistry, with different storage structures. The former is a set and the latter is a dictionary. Relatively speaking, the implementation of the former is more direct (to greet one), and the latter is relatively round (to sit on the opposite account first, and then to whom to greet ).

The different storage structures make the two significantly different in performance. Regionmanager's regions attribute is a set, so you can manually add or remove views in Region (using the add or remove methods of the Set), especially the remove function, which can release memory that is no longer in use.

Regionviewregistry uses a dictionary to store the view internally. Its registerviewwithregion method adds the view to the dictionary. However, since the dictionary is private, it is not exposed to the outside world, therefore, we cannot use its remove method to remove the view. This is because the views stored in the dictionary are weak references. Let's review them again:

This. regionviewregistry. registerviewwithregion ("mainregion", typeof (views. helloworldview ));

Typeof (views. helloworldview) is a weak reference. We know that ,. net automatically recycles memory that is no longer in use. Therefore, when the view is no longer used, the memory occupied by the view is automatically recycled. However, when does automatic recovery occur? No one knows. Therefore, the system is getting slower and slower because of the regionviewregistry method.

Since it is not easy to use, why should we design regionviewregistry?

It takes a long time to speak. This should start with prism version 1st. At that time, Prism had only the view injection mechanism, that is, only the regionmanager class. Later, we found that the regionmanager class is also bad, that is, when embedding region, each level of region should write the regions ["regionname"]. does the add method have to care about the relationship between layers? In addition, Prism often reports that regionname cannot be found and throws an exception (for more information, see my other article ). To facilitate development, the P & P team provided the regionviewregistry class and its registerviewwithregion method in Prism 2nd, so we can use this method anywhere, you do not need to write the corresponding code in the respective view. However, the cost is simple, that is, performance, which has been analyzed above.

At the same time, the prism framework adds registerviewwithregion to the regionmanager class as an extension method. In fact, it still calls the registerviewwithregion method of the regionviewregistry class. Therefore, a composite relationship is formed.

The original design idea is pretty good. It can block the regionviewregistry class. for the client, only the regionmanager class has the registerviewwithregion method and regions ["regionname"] attribute at the same time (the former is a weak reference method, the latter is strongly referenced ).

However, I do not know that it is the DPE brain of Microsoft P & P. In the prism document and example, I used the regionviewregistry's registerviewwithregion method at the same time. This violates the original design intention. As a result, we are confused and don't know when to use the method of the class, or even start to doubt life.