July 2011 - Posts
MEF - Best Practice
In this post I will offer MEF practice that may ease your MEF life.
one of the MEF headache is to understand what's goes wrong,
when MEF reject the composition, you can read more about
MEF diagnostic in this post.
Most of the obscure loading failure happens when your Export dependencies doesn't
satisfied. in those case you solely relay on the MEF error message which is not enough
in cases of deep dependencies graph.
It will normally occurs when you are using the Import attribute (not ImportMany).
let take the following test case:
Code Snippet
- public interface IFoo
- {
- void Write();
- }
-
- [Export(typeof(IFoo))]
- public class Foo : IFoo
- {
- }
-
- public class Bar
- {
- [Import]
- public IFoo Foo { get; private set; }
- }
class Bar importing IFoo, which mean that the composition will fail whenever
MEF find no valid IFoo export or find more than single IFoo export.
we can use 2 patterns:
- [ImportMany] which will handle both the case of no export and too many export.
- [Import(AllowDefault=true)] which cover the case of no export.
using ImportMany and the IPartImportsSatisfiedNotification pattern.
we can validate the composition right after the composition stage.
Code Snippet
- public class Bar : IPartImportsSatisfiedNotification
- {
- public IFoo Foo { get; private set; }
-
- [ImportMany]
- private IFoo[] FoosInternal { get; set; }
-
- public void OnImportsSatisfied()
- {
- if (FoosInternal == null || FoosInternal.Length == 0)
- throw new Exception("MEF composition find no IFoo");
- if (FoosInternal.Length > 1)
- throw new Exception("MEF composition find to many IFoo");
- }
- }
at the OnImportsSatisfied method you can check whether
you got the composition right (instead of letting the MEF infrastructure
doing this job).
in most cases it is enough to ignore the to many IFoo composition case
and to apply the [Import(AllowDefault=true)] pattern.
Code Snippet
- public class Bar : IPartImportsSatisfiedNotification
- {
- [Import(AllowDefault=true)]
- public IFoo Foo { get; private set; }
-
- public void OnImportsSatisfied()
- {
- if (Foo == null)
- throw new Exception("MEF composition find no IFoo");
- }
- }
after the composition we can validate whether IFoo composition goes right.
Summary
MEF failure at the composition phase can be frustrating.
in this post I have tried to offer pattern to ease that pain.
last month I and Yaniv Rodenski had lecture about TPL (Task Parallel Library)
since than I was traveling to Croatia Slovenia and Italy, and didn't find the
time to upload the code samples for the sessions.
so I apologies for the long waiting :(
you can find the samples here.
Point of interest:
if you happens to be in Israel at 18/8/2011
you can here me lecturing about Tpl Dataflow, at the Israeli user .net group.
Rx Release
the Rx (Reactive Extension) is finally shipped,
and it seem a great time for speaking about the Rx future.

Rx was started as in process technology,
but with the addition of the IQbservable
(the Rx complementary of IQueryable),
Rx is breaking the process boundary.
actually this is the same story as for IEnumerable and IQueryable,
IQueryable broke the process boundary of the IEnumerable execution.
using IQueryable we can translate the IEnumerable into expression tree
which will later translate to none IL instruction like SQL query, LDAP or any other query provider (see LINQ-to-Anything).
bringing the IQbservable (Query observable) to the table IObservable can be
translate into expression tree, and be execute by different scheduler like
Cloud scheduler, WMI scheduler, ext… such scheduler can expose push over Rx
beyond the process boundary.
currently the Rx team turn the spot light into the cloud (azure) direction,
and we can expect a great cloud push model which will revolutionize the
way we use to subscribe remote data events.
it also having the fine tuning of ToObservable() that let us control which
part of our expression will execute remotely or locally.
Summary
In the near future I will extend my Rx post series and explore the
current and future release of Rx.