I. Presentation Overview
This sample demonstrates how to implement a custom catalog class that filters exported parts by using the extension mechanism of the catalog provided by MEF (Catalog). It is accomplished by inheriting Composablepartcatalog base class and implementing interface Inotifycomposablepartcatalogchanged.
Related downloads (screen video): Http://yunpan.cn/cVkvuUNfuDtTX access Password 567d
Warm tip: If the screen video and code can not be downloaded normally, you can leave a message, or send an email to 524130780@QQ.COM
Welcome to be interested in studying. NET related technology netizen add QQ Group: 18507443
Second, custom Parts Catalog class catalog
In MEF, you can define a directory class yourself, in addition to the directory classes that you can use to inject aggregatecatalog, Assemblycatalog, and directorycatalog that you provide.
Custom directory classes need to inherit from the Composablepartcatalog class and implement Interface inotifycomposablepartcatalogchanged. As shown in the following code:
public class Filteredcatalog:composablepartcatalog, inotifycomposablepartcatalogchanged {#region Private Fields
Private ReadOnly Composablepartcatalog M_composablepartcatalog;
Private ReadOnly inotifycomposablepartcatalogchanged m_notifycomposablepartcatalogchanged;
Private ReadOnly iqueryable<composablepartdefinition> M_parts;
#endregion #region Constructors///<summary>///default constructor. </summary>///<param name= "Composablepartcatalog" > contains the directory catalog for all exported parts. </param>///<param name= "expression" > Filter criteria expression. </param> public Filteredcatalog (Composablepartcatalog Composablepartcatalog, expression<func<
Composablepartdefinition, bool>> expression) {M_composablepartcatalog = Composablepartcatalog;
m_notifycomposablepartcatalogchanged = Composablepartcatalog as inotifycomposablepartcatalogchanged;
M_parts = composablePartCatalog.Parts.Where (expression); #endregion #region inotifycomposablepartcatalogchanged///<summary>///Part directory catalog has been changed to trigger
of events.
</summary> public Event eventhandler<composablepartcatalogchangeeventargs> Changed {add {if (m_notifycomposablepartcatalogchanged!= null) {M_notifycomposablepar
Tcatalogchanged.changed + = value;
} remove {if (m_notifycomposablepartcatalogchanged!= null) {
m_notifycomposablepartcatalogchanged.changed = value;
}}///<summary>///part directory catalog events that are triggered when a change is occurring.
</summary> public event eventhandler<composablepartcatalogchangeeventargs> changing {add {if (m_notifycomposablepartcatalogchanged!= null) {M_notifycomposablepa
Rtcatalogchanged.changing + = value;
}Remove {if (m_notifycomposablepartcatalogchanged!= null) {M_n
otifycomposablepartcatalogchanged.changing = value; #endregion #region composablepartcatalog///<summary>///Gets the part definition contained in the directory.
After filtering through the expression in the constructor, it is already part of the exported directory catalog object. </summary> public override iqueryable<composablepartdefinition> Parts {get {return M_par Ts }} #endregion}
The above code generally contains the following elements:
1, the constructor passed the basic Directory catalog object, this directory object may contain a lot of export parts, we want to implement the Directory filtering class Filteredcatalog is based on this directory to filter, it is a complete, and Filteredcatalog is a subset of it. Another parameter is the filter expression, the filter condition is written by the caller, and the internal filtering method is actually the where () approach provided by LINQ.
2, the implementation of interface inotifycomposablepartcatalogchanged is actually associated with the event of the underlying directory catalog object, that is, when the underlying directory object changes, The directory filtering class Filteredcatalog will also receive notification accordingly.
3. Overrides the Parts collection property of the base class Composablepartcatalog, which returns the directory that contains the part definition, which is returned through the collection for any part definitions that need to be exposed in the directory. Therefore, the filtered part definition is returned through this property in the preceding code.
The filter class is defined, and the next step is how to use it.
iii. Use custom directory class catalog
As shown in the following code:
Get the part that you want.
Directorycatalog Catalog = new Directorycatalog ("controls");
Compositioncontainer container = new Compositioncontainer (catalog);
Filter the catalog, and generate the child composition container.
Filteredcatalog filteredcatalog = new filteredcatalog (catalog,
o=>o.metadata.containskey ("UC") & & o.metadata["UC"]. ToString () = = "BB");
Compositioncontainer Filteredcontainer = new Compositioncontainer (Filteredcatalog, container);
UserControl UserControl = filteredcontainer.getexportedvalue<usercontrol> ();
This. Maincontentcontrol.content = UserControl;
First, the Directorycatalog class gets all the part definitions in the Controls subfolder of the application root and generates the top-level Combo container container (type Compositioncontainer).
The custom directory filtering class is then used to filter the part definitions in the Directorycatalog directory and to generate a Filteredcatalog container Filteredcontainer (type Compositioncontainer).
Finally, the export part of the specified protocol type is obtained through the getexportedvalue<t> () method of the combined container. It is necessary to note that an exception is thrown if there is no export part of the corresponding protocol type in the composite container.
Complete sample code and screen video files can be obtained from the following address.
Iv. Related Resources
1, MSDN Official information: http://msdn.microsoft.com/zh-cn/library/dd460648 (v=vs.110). aspx
2, referring to the Microsoft MVP Bēniaǒ article "MEF Programming Guide VII: Using the directory (Catalog) dynamic load xap and directory filtering (filtered Catalog)", Access to address: http://www.cnblogs.com/beniao/ Archive/2010/07/26/1782622.html