Showing posts with label Pluggable. Show all posts
Showing posts with label Pluggable. Show all posts

Friday, September 6, 2013

Using IoC for Runtime Plug-ins

If you are already using an IoC container in your code it can be easier to leverage it to create a plug-in model. (Instead of using a plug-in framework like MEF - which is still valid, but you may not want to introduce another similar paradigm into your code).


You'll need to add the following to the app.config so that plug-in DLL's will be in the probing path.
 

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <probing privatePath=".\Plugin" />
    </assemblyBinding>
</runtime>



This is where the plug in DLLs will be saved at runtime. In your composition root the plug-ins assemblies will need to be loaded into the AppDomain so the IoC container can find the plug in types.

public class AssemblyMetadata
{
    public string FileName { get; set; }
   
    public string Path { get; set; }
}

public class PlugInAssemblyLoader
{
    public void DiscoverAssembliesInPlugInFolder(string path, Predicate<AssemblyMetadata> assemblyFilter)
    {
        if (!File.Exists(path))
        {
            return;
        }

        var assemblies = Directory.GetFiles(path).Where(f => Path.GetExtension(f) == ".dll").Select(f => new AssemblyMetadata {FileName = Path.GetFileName(f), Path = f});
        assemblies = assemblies.Where(a => assemblyFilter(a));
        foreach (var assemblyFile in assemblies)
        {
            Assembly.LoadFile(assemblyFile.Path);
        }
       
        LoadAssembliesIntoAppDomain(discoveredAssemblies);
    }
}

public class CompositionRoot
{
    public void MapTypes()
    {
        // Other type registrations with your IoC container...omitted...
       
        // Load any (if any) plugin libraries into memory
        string plugInLibraryLocation = AppDomain.CurrentDomain.BaseDirectory + @"\Plugin"; // Or look up from app.config etc
        new PlugInAssemblyLoader().DiscoverAssembliesInPlugInFolder(plugInLibraryLocation, metadata => metadata.FileName.StartsWith("MyCompany"));
       
        // Be sure to trigger loading app.config registrations for your IoC container. This is where your plugins will be registered.


        // Plugin types could be replacement for standard types necessary in the application, or they could be optional plugins (ie additional filters e
    }
}




Sunday, June 3, 2012

WCF 4 Code Samples

The official code samples from Microsoft for WCF 4 on MSDN.

Saturday, April 16, 2011

MEF versus IoC

The Microsoft Extensibility Framework (MEF) has been around for a couple of years now and is used to allow extension to Windows applications without changing the original code (Recomposition).  It can be used with either Silverlight, WPF, and WinForms. MEF is not a replacement to PRISM. The PRISM toolkit to help you implement the MVVM pattern and is similar to MVVM Light or any of the other MVVM Toolkits. PRISM is also only intended for WPF and Silverlight.  So what is MEF?  The MEF Website describes it as
"Application requirements change frequently and software is constantly evolving. As a result, such applications often become monolithic making it difficult to add new functionality. The Managed Extensibility Framework (MEF) is a new library in .NET Framework 4 and Silverlight 4 that addresses this problem by simplifying the design of extensible applications and components."


I've been a long standing fan of IoC, and after reading many articles about MEF and writing a few test applications, there seems to be a cross over with IoC.  IoC is far more generic and is a more broad pattern to use across your entire system, whereas MEF is specifically targeting extending and recomposition of the UI.  So where's the cross over?  MEF is a kind of object factory (aka container), it makes replacement of UI Views and Controllers (aka View-Models) easy.  By decorating a public property with an attribute the MEF framework with find all subclasses of (or a chosen one) and instantiate it and inject it into the property.  Very much like an IoC container.  But MEF does have some cool features for searching application folders for runtime add-ins etc.  But so does StructureMap.

Here's an excellent comparison from MSDN:

My take on it, is MEF will suit people new to IoC better, and might be more approachable. The documentation for MEF is pretty good, better than StructureMap's documentation for sure.  Using a mature feature rich IoC container like StructureMap however you get most of the functionality of MEF, but it requires a little more work to use. But it gives you the advantage of a unified approach and good consistency.

Thursday, September 2, 2010

Microsoft Patterns & Practice's Prism Demo

References:

Summary (from the official Microsoft Site)

Prism (Composite Application Guidance for WPF and Silverlight) is designed to help you more easily build enterprise-level Windows Presentation Foundation (WPF) client applications. This guidance will help you design and build flexiblecomposite client applications-composite applications use loosely coupled, independently evolvable pieces that work together in the overall application.
The Composite Application Guidance can help you develop your client application in a modular fashion. With this approach, you manage the complexity of a large application by breaking it down into smaller, simpler modules. The modules can evolve independently while working together as a unified application.
This version of the Composite Application Guidance is designed to help you build applications in WPF and Silverlight that have a single code base.


Architectural Goals

The Composite Application Library is designed to help architects and developers achieve the following objectives:
  • Create a complex application from modules that can be built, assembled, and, optionally, deployed by independent teams using WPF or Silverlight.
  • Minimize cross-team dependencies and allow teams to specialize in different areas, such as user interface (UI) design, business logic implementation, and infrastructure code development.
  • Use an architecture that promotes reusability across independent teams.
  • Increase the quality of applications by abstracting common services that are available to all the teams.
  • Incrementally integrate new capabilities.

Messaging and Event Aggregators

Comparing the Prism offering of Event Aggregator and with Mvvm Light, is clear that Mvvm Light is a far nicer syntax.

Mvvm Light Event Aggregator - Send a Message / Event Notification

Messenger.Default.Send(new NotificationMessage(this, "Show Modal Dialog"));

Mvvm Light Event Aggregator - Receive a Message / Event
Messenger.Default.Register<NotificationMessage>(this, SomeEventHandlerMethod);

Compare that with the Prism Event Aggregator:

Sender:
NotificationEvent x = eventAggregator.GetEvent<NotificationEvent>();
x.Publish("Show Modal Dialog");


Listener:
NotificationEvent x eventAggregator.GetEvent<NotificationEvent>();
x.Subscribe(message => SomeEventHandlerMethod(message));

Yep... I know which one I prefer.

I don't think I'll look any closer at Prism (or MEF or whatever its called this month) until I need more loose coupling with internal components.