this post will focus on the basics of MEF metadata capabilities,
the next post discuss the ability of multiple metadata decorations.
What is Metadata?
metadata is piece of compile-time information that can be attached to exported part.
- metadata is adding peripheral information to the part,
(metadata information may define which operation system supported by the plug-in).
- metadata can be read before the instantiation of the part.
MEF support both typed and non typed metadata, as is the case in other .net component
the best practice suggest using the typed metadata paradigm.
(our series will focus on the best practice of type metadata).
Which steps is needed for working with typed metadata?
the steps is needed is:
- define the metadata (attribute)
- decorate the exported part
- define the metadata view contract
- add the metadata view contract into the import signature
how to define typed metadata
defining metadata is very simple, all its take is to define attribute which
having public properties and is decorated with the [MetadataAttribute]
as you can see it is no different from any other .net attribute definition,
except of the decoration of [MetadataAttribute] in line 1.
Decorate the exported part
as you can see in line 2 the exported part is decorated with some metadata.
line 1 is decorating for the export (see the Improving the usability section for
learning how it can be more usable).
Define the metadata view contract
metadata view present the portion of the metadata that we want to interrogate,
(this contract can be class of interface and it can reflect all or part of the attribute public fields).
in the above case the metadata view contract is reflecting all of the public properties.
the import definition should use Lazy type with 2 generics definitions,
the first definition for the plug-in contract, and the second for the metadata view contract.
as you can see in line 2, MEF will create enumerable of lazy plug-ins which having typed weather metadata.
Inquiring the metadata
having the above import we may use Linq query (or any other technique) to filter the plug-in
portion that suite our needs (without having to instantiate the unneeded plug-ins).
the above sample is using the typed metadata to filter the sunny activities.
Behind the scenes
what is happening behind the scenes it that MEF is using reflection emit in order to construct
the typed metadata view.
Improving the usability
we can improve the usability of the previous sample by inheriting the ExportAttribute
(instead of Attribute), that way we can have single simple decoration for our export part.
the above attribute define both typed metadata and export for the PluginBase type.
line 3: is inheriting the ExportAttribute.
the exported type decoration can be define using single simple attribute decoration.
you are no longer having to use different attribute for export and metadata,
and as in this case the export type definition is handled by the attribute,
which enhance the consumer usability by having less area for errors.
the code sample is demonstrating scenario were we want to present only plug-ins that suit
the current weather (the sample is using Google API for getting the NY weather).