Any MEF books coming?

Nov 18, 2009 at 4:48 PM

Just dipping my toes in MEF waters for the first time, and while the blog sphere is providing a lot of useful examples I'm really looking for something far more structured that goes way beyond the MEF whitepaper etc. Does anyone know if any MEF books are coming?

Developer
Nov 18, 2009 at 8:56 PM

Sorry I'm not aware of any books in the works (of course that doesn't mean there aren't any).

Nov 20, 2009 at 6:17 AM

Hi polyGhost

Kathleen Dollard, myself and Daniel Plaisted are in the early stages of authoring a MEF book. We're hoping ot have it out some time next year.

What would you want to see in such a book?

Glenn

Nov 20, 2009 at 11:25 AM
gblock wrote:

Hi polyGhost

Kathleen Dollard, myself and Daniel Plaisted are in the early stages of authoring a MEF book. We're hoping ot have it out some time next year.

What would you want to see in such a book?

Glenn

Hi Glenn,

While I appreciate that MEF has been designed to be lightweight enough (in terms of dependencies) to be domain agnostic, I would love to see a use case in the book that specifically mashed up MEF to enable 3rd party customisation (composition) within a existing UI.

Assuming it's even possible, how would one go about getting on the reviewers list for such a book.

Kind regards,

Tom Kirby-Green

Technical Architect,

SunGard Adaptiv.

 

 

Nov 20, 2009 at 2:11 PM

Hi Glenn,

I'd like to see the design & architechture of MEF.

Maybe start with something like "implement a MEF yourself step by step", and then introduce how to use MEF and how to extend it.

Nov 20, 2009 at 5:07 PM

Hey Glenn,

A number of potential topics come to mind for me:

1) A discussion of how to build a fully composable application - one with a public, extensible object model (ala Excel or VS) that is independent of and has an extensible user interface (WPF is fine for concrete examples - how to make menus, ribbons, dialogs, etc. runtime composable).

2) A discussion of containment & hierarchy - how to create systems where a given part may need to be non-shared from the point of view of the entire system, but shared from the point of view of its "contained" parts. Think of Excel as a model - a workbook can have many sheets that are created or destroyed based on user requests. These worksheets are non-shared from the workbook point of view, but their contained objects (cells, ranges, etc.) see the sheet as a shared object.

3) A discussion of part lifetime. How do you build a system with a dynamic set of parts (think Excel again) that properly cleans up after itself when a part is no longer needed? Probably such a discussion ties in tightly with #2.

4) A discussion of performance. What are the bottlenecks in MEF (i.e. discovery, composition, etc.)?

5) A discussion of how MEF relates to threads and AppDomains. In particular, how do I build an MEF-based system that allows me to isolate a subset of its parts in a separate AppDomain so I can unload it when I'm done using those parts? What are the implications of creating parts on a different thread, or using a part on a thread other than the one on which it was created?

I too would love to be on the reviewer list for this book...

Ron

Nov 22, 2009 at 2:26 PM

Thanks for the input! I'm really looking forward to sharing what we've learned in the book and learning more along the way. I have some questions on the comments you've made:

>>

I'd like to see the design & architechture of MEF.

Maybe start with something like "implement a MEF yourself step by step", and then introduce how to use MEF and how to extend it.

<<

Do you mean the architecture of how MEF itself works, or do you mean how to architect with MEF. We are leaning to the latter as far more interesting.

>>

1) A discussion of how to build a fully composable application - one with a public, extensible object model (ala Excel or VS)

<<

My current thinking is that we can arbitrarily divide MEF architectures into three groups based on how we think of the app. Ecosystem apps, like VS or an Excel type app, plug-ins, and MEF architectural apps. Of these, I think people are least likely to write the first. Would a simple business app sample be more interesting to you?

I'd love to hear more about AppDomain scenarios.

Here's the current thinking on the book: MEF has a lot of stuff to talk about. We can get very geeky with it. But if we don't restrain ourselves we wind up making MEF sound way more complicated than it is. My thinking includes scenario based mainstream usage that tends toward agile learning with almost a YAGNI approach. If we have scenarios that use MEF features, then the belong in the book. If the scenarios feel like side cases, we'll leave those details for blogs and Internet searches. Any thoughts on that?

Kathleen

Nov 22, 2009 at 6:20 PM

Adding to what Kathleen is saying, there's a breadth of topics we could cover. Which ones we choose will greatly depend on the target audience. To date our lean has been that this book is for developers who know nothing about MEF, nothing about IoC type concepts, but wants to get off the ground. We believe this probably 80 to 90% of the market.  For that target, we would want them to know the basic problems MEF addresses, why you would use it, and how. We'd shy towards the most basic scenarios and use cases, and maybe cover some more advanced stuff later in the book.

 

Nov 23, 2009 at 5:13 PM

Hi Kathleen,

The "ecosystem" app is the style of application in which I am truely interested - we are not writing simple business applications. I believe ecosystem applications is one area where MEF really has the potential to shine - if applied correctly. It is that "if" with which I am struggling at the moment. I feel there is a lot I do not understand about the intricacies of MEF that is going to bite me in the future, but that is just a gut feel - no hard data yet (fortunately, I suppose).

The AppDomain scenario is simply one where we want to be able to unload things that we are no longer using. I suppose this will become less of an issue as the world moves to 64 bit and we have unlimited process address space to play with, but until then the 2 (or 3) Gb boundary can cause us problems. Anything we can do to reduce our memory footprint is significant. A secondary reason for separate AppDomains is isolation - as we open our architecture to 3rd party extension (one of the reasons we are using MEF), we want to make sure that code that is not quite as robust as it should be does not bring down the whole application.

I understand the need to address the largest possible audience with the book, but I implore you to consider the more advanced MEF user as well. Using MEF for a trival application is somewhat akin to swatting flies with a sledge hammer - it works but do you really need it? Please make sure the book does not address only trivial applications. MEF is a really powerful tool for building larger, more complex applications that will evolve over time, either by developer extension or customer extension. The developers working in that domain really need more in-depth coverage of the topic.

Regards,

Ron

Nov 23, 2009 at 6:57 PM

I can definitely see the value of guidance on using app-domains, but honestly I don't think this book is the place for it. It's not an easy problem that a simple chapter could even address as there is no easy answer.

Case in point, the managed add-in framework (System.Addin) was built to make app-domain management simplified. The result was it pushed a ton of constraints on every aspect of your development including the need to build/generate a multi-stage pipeline of components. We really need the CLR to offer better support for management of app-domain like things, without requiring so much work. Until we get that, it's just putting lipstick on a pig.

The first book is planned to be more of a "Getting Started with MEF". Going forward though we are also planning possibly more in-depth books which might be the appropriate place to cover this.

Thanks for the feedback Ron. We'll add it to our backlog of things to consider.

Regards

Glenn

Nov 23, 2009 at 7:12 PM
gblock wrote:

The first book is planned to be more of a "Getting Started with MEF". Going forward though we are also planning possibly more in-depth books which might be the appropriate place to cover this.

 I'd definately vote for a shorter book sooner. I need something I can reasonably expect members of my team to read (as compared say to a Joe Duffy esc. 1000 page tome [kudos to Joe, I did actually read the whole thing]). Advanced usage patterns could either be covered in a second volumn or supplied as additional chapters on the books website. Maybe. It would be fantastic if you folks could have gone to press at or before VS2010 RTMs.

Nov 23, 2009 at 7:53 PM

It likely won't be at or before :-) Within the first 6 months after we ship though is probably reasonable. I'll be talking to a publisher this week so we can get a pulse on realistic timeframe.

Glenn

Nov 24, 2009 at 2:21 AM
gblock wrote:

It likely won't be at or before :-) Within the first 6 months after we ship though is probably reasonable. I'll be talking to a publisher this week so we can get a pulse on realistic timeframe.

Glenn

Will it be put on the web site?

Nov 25, 2009 at 8:53 PM

It's possible we could develop the book in an open wiki in a Fowleresque style if that is what you mean. We haven't discussed that yet though. Once the book ships though it would be available for purchase like other technical books.

Glenn

Jul 15, 2010 at 3:21 AM
I'd like to learn from this book how to create a region manager for Silverlight. BTW, how are the things with book going?
Aug 9, 2010 at 2:57 PM

I too would like to know if there's a book I can look forward to reading? :-)

The particular scenarios I'm interested in currently are about versioning. Say, I have a interface that has some core functionality and then vendor specific extensions. Some functionality will be obsoleted as time goes by and some will be added or existing one modified. Much like, say, is the case with OpenGL with the core API and vendor specific extensions. How should one write a wrapper around such an interface and make the versioning work so that an interface and an implementation with a specific version and version can be selected? In such a scenario, is it possible to load dynamically a different version of the wrapped dll (and perhaps unload the old ones)?

I can come up with all kinds of more or less elaborate ideas using partial interfaces and functions, but currently it feels like being an awful lot of studies. Hmm, perhaps I should post these as questions to another thread since this started to interest me... :-)

Aug 9, 2010 at 4:08 PM

I'm sorry we've been quiet on this.

Setting the book aside for at least a while has been painful for all three of us, although I will only speak for myself. Other things are getting in the way and I do not know when/if I will return to that particular book. There are rumors other people are working on MEF books. I wish them the best and I hope someone provides a book that I can say “whew, the critical guidance is out there, I can continue to focus on other things.”

We all really need a book. Me too.

Aug 10, 2010 at 3:48 PM

There's more into life than work and programming or writing about interesting things. :-) Yeah, I wish someone is writing a quality book somewhere there already with some real world examples gleaned from the forums. I'd like to have some discussion on MAF too and security perspectives.

Aug 22, 2010 at 8:58 PM

There is a book coming out called "Dependency Injection in .NET" which will include a chapter on MEF, as well as other DI containers such as Sprint.NET, Unity, & a few more 

I've gotten a copy on their early release program, & from what I've read so far, it does a great job covering the topic dependency injection, but the MEF chapter isn't released yet, so will have to see. 

is here: http://www.manning.com/seemann/

The awesome thing about MEF is how elegantly is solves the problem & how short the learning curve is for the basics.  A book like this will be a great start, although it's probably not meant to be The Definitive Reference on MEF.