This project has moved and is read-only. For the latest updates, please go here.

Need expert's advice. Could it be done with MEF?

Nov 29, 2009 at 9:02 PM

Our company is starting to develop a software using WPF/Silverlight. And one of our aims is to get easy extensible application as much as it possible. So as many of developers wanted their apps to be - nothing special.
Untill we knew nothing about MVVM and IoC and dependency injection frameworks we planned to store pure XAML in database letting end user to easily retrieve and customize it. When app requires that functionality that use this XAML it is retrieved from database and dinamically "attached" to it's codebehind file using XamlReader. Of course we take care about all initialization and binding controls to their handlers, what in usual way is done automatically in *.g.cs file. Not the best solution maybe, but we have XAML as pure text in DB, which is easy to modify.
So, now MVVM gives us more pure way to separate View and ViewModel. But extensibility issue still exists and we still in search of more elegant solution, if it exists.
As far as I know from surface acquaintance with MEF - it suppose storing all parts (including Views) in assemblies. But we think that it is not convenient to end user. If he want to make an extension he must write dll, in which he includes his form. But he has no access to source of standard Views as they also stored in compiled dll, while in most cases the want only to change Xaml in lightweight utility like Kaxaml and not to be awared of any code.
There is another side of coin - View layer, though it represent presentation logic constists both of XAML and Codebehind file that could include at least initialization (InitializeComponent method) and also could represent some complex presentattion logic, that couldn't be described declaratively in XAML (hope it would be very rare, but it could be). So nevertheless it has no specific logic it exists as part of a View. And storing its separately obligate us to  have some logic to initialize form and bind it with it's codebehind, which is not convenient for us as developers.
So my question - is it possible while using MEF to combine both approaches, that would provide easy access to xaml its changing and provide the MEF's parts catalog with the View as whole object as it stored in dll?

Thanks in advance!

Nov 29, 2009 at 9:28 PM

MEF is not bound to using assemblies for providing exports. You several options available. One is to create a custom ExportProvider which provides exports from a data source you choose as as an XML/XAML file. You can learn a bit more about ExportProviders in this post. Creating an EP is relatively easy to do, far simpler than option 2 which is to create a custom programming model. Once you have a custom EP, you can pass it to the container in it's constructor and then exports will be resolved from it in addition.

Option 2 involves creating a custom programming model / catalog. Using a catalog you can create parts that represent your views. Creating programming models is not easy, but it does provide benefits in terms of static analysis. Here's an older post that will point you in the direction. Our bits have changed so there'll be a few things you'll have to do differently.

I'd recommend option 1 though as it will take signficantly less work.



Nov 30, 2009 at 11:25 PM

Thanks for Your answer!

I still have some questions and would appreciate if You advise me: 1) where can I find examples of implementing a custom ExportProvider (as I found nothing); 2) How would instantiation of partial class, defined in XAML and codebehind, looks like? I mean as we store VIEW outside of an assemblies, we get them as pair of textblocks (one for XAML and one for Codebehind). So how to instantiate them in order to import it where we need? I also wonder, if automatically initialization and other automation from *.g.cs would be done for us in this case?