MEF lab [How to: Keep implementation details out of a MEF contract assembly by implementing an interface-based event handler]

This blog has moved to a new location and comments have been disabled.

All old posts, new posts, and comments can be found on The blog of

See you there!

Comments (4)
  1. Samuel Jack says:

    Presumably another way would be to eschew events and expose IObservables instead?

  2. David Anson says:

    Samuel Jack,

    Assuming the same problem doesn't come up, that seems reasonable as well! 🙂 From my current perspective, people seems to be pretty divided on whether to embrace the Rx framework or not, so I'm not sure I'd make it part of an official API just yet. Something else that's kind of interesting to follow is the Visual Studio Async CTP (i.e., the "await" keyword):…/async.aspx Of course, that's also not finalized, so I wouldn't use it in an official API, either. 🙂

  3. Stimul8d says:

    if (null != handler)


               handler(this, new MyEventArgs("MyEventArgs"));


    Nice use of Yoda expressions 🙂

  4. David Anson says:


    I assume you mean "null != handler" vs. "handler != null"? Yep, someone gives me a hard time about that every couple of months or so… 🙂

    For people who don't know why the former might be preferred, here's a pretty good discussion (there's also some coverage on StackOverflow):…/wiki

    The good news is that C# doesn't have quite the same risk as C/C++ because of "warning CS0665: Assignment in conditional expression is always constant; did you mean to use == instead of = ?". However, there are two reasons I continue to use this pattern:

    1. I still code in C/C++ from time-to-time and like to use the same coding conventions everywhere.

    2. It's only a *warning* in C#, so someone may ignore it, suppress it, etc..

    In case it matters, after a little while putting constants on the left, you won't find it hard to read anymore. At this point, I find it quite natural… 🙂

Comments are closed.

Skip to main content