we've been evaluating MEF for the purpose of using it for our enterprise application, so please pardon me for an ignorant question.
I've been looking through the guide and API and the feeling that I got so far was that most of the resolution logic for imports lies withing the framework, and the typical way of affecting it is using metadata attributes.
For example, if I want to import an interface I1, and there are two class exporting it, C1 and C2, then the ways for me to pick one of them is either by:
a) metadata requirements
b) using collection import and then iterating over a collection and figuring out which import is the best myself.
What I needed was a little bit more control over import without the need to write complicated code at the import side. I wanted to extract this resolution logic in a strategy which I can then reuse.
Consider an example; I have a generic data-view framework. The view containers describe view placeholders within them using some sort of categorization (for example, "a tree view", "a thumbnail list", "a one-line list", "an
interactive workspace"). These categories specify what kind of view is expected at the placeholder - "a tree view" would want a view which is a one line with an icon, while "a thumbnail list" would expect something with an image and
The views are exported by modules together with data. The view has attributes defining its properties, but it also exports some dynamic information, such as image size or whether it is readonly. Among others, there may be specifiers about what kind placeholder
this view is most suitable for - "a one-line list" or "a tree view" or "an interactive workspace".
When the data need to be displayed by a container, it tries to find a view for it. It looks for a view matching the placeholder criteria. Imagine, this lookup is performed in many places, but the logic is generic among all places. By defining this categorization,
and annotating both placeholders and views, it removes a need for containers to know anything about views it will display, and views to know anything about containers they will appear in.
Two things you may see from the way I'm doing this view discovery:
a) the criteria is dynamic. It is not limited by the compile time attributes, but may be controlled by dynamic properties
b) there is a separable and reusable part of logic responsible for matching of imports with exports
These two requirements lead me to the need of a strategy-based resolution. I heard that currently ImportDefinition is probably the place where the hard-coded strategy resides, but I was wondering if there are ways to insert pluggable strategies for different