Wednesday 21 December 2011

Managed Extensibility Framework in .NET 4.0

 

Had a lot of catching up to do on .NET 4.0 & .NET 4.5, I stumbled upon the Managed Extensibility Framework (MEF) new to .NET 4.0.  A good start to understand the MEF would be to run through the channel 9 series of videos at

In case you want to run through a sample look at Visual Studio 2010 Training KIT - http://www.microsoft.com/download/en/details.aspx?id=23507

MEF derives a lot of its thought process of the classical design problem statement “ My client application need certain features down the line I’m sure there are licensed at a premium price but I’m not sure if I will be include this in my deployment kit”.

Or in other word look at the USB its plug an play can accept any kind of devices on the fly as long it adheres to USB standards.  This is a classical interface based designing where one may go define a standard operating interface for USB ( its related operations).

Obviously if a designer intends to solve this problem the interface design way he/she would publish a standard interface have every new component implement this interface & write the binary locations in the config file and have the code load up this assembly.

Interestingly MEF encapsulates the assembly loading part but it does have all components honor the Interface Definition Commitment no moving from this.

What it means for the .NET world I can add new functionality to the client application without having to change the client codebase, just copy paste the new assembly which implements the new interface in the application bin directory and you are pretty much done.

In short the key take away from .NET developer

  • Use MEF pattern for extensibility of components, which can go in as separate deployable unit on demand or at a later stage.
  • You can go Dependency or IOC this is a lot cleaner
  • Singleton is good to use in the application what about scenario where I may want to move to Multi instance if lifetime management behavior is embedded in the core application I need rewrite it would be good to abstract the lifetime management outside of the application by going MEF using PartCreationPolicy
  • Dependency Resolution: Good part of under the hood MEF has been written to load up all the related dependencies to the new type loaded.
  • Modularity: MEF allows for modularity by allowing you to separate functionality into different modules and load them dynamically as needed.  Imagine a large application that has ten menu items, but users typically may only go into one.Only when the user needs a piece of functionality will their application download the extension and make it available. This allows them to get up and running faster and conserves resources by only supplying what is needed.

In short life for a .NET developer is highly simplified with MEF as compared to the earlier options for building composable apps. Leaving with

http://msdn.microsoft.com/en-us/magazine/ee291628.aspx – a good read for a finish.

To make things better in scenarios one can end up using Lazy Loading as the data loading can be deferred to point of usage. Multiple Implementation Pattern of  Lazy Loading

  • Lazy Initialization
  • Virtual Proxy
  • Ghost
  • Value Holder.

 

Using MEF for unmanaged world is still a thought , some answer could be reasoning out of introduction of Windows Runtime in Windows 8 which in a way is more closer to un managed world, so there is likely possibility in the future using Windows Runtime with MEF.

No comments: