locked
Best Extensibility Framework? RRS feed

  • General discussion

  • At my company, we have a central database which houses most of our operations and financial information. Many different areas need access of varying degrees to this information - either simply reports or more complex editing interfaces. Over the years, all of these applications have been rolled up into a single monolithic application split into many different assemblies. The result is, in essence, a plug-in architecture, though not so much by design as happenstance.

    I want to re-engineer this system using a well-designed, well-thought-out plug-in/extension architecture. The core application would be more of a shell that would host satellite applications (which could be added per user as needed). The advantage for the users is a single source for all of their applications. The advantage for the developers is a single, consistent framework in which to develop. The advantage for the "deployers" is the ability for the core application to pull down the latest assemblies dynamically, as needed.

    I'm wondering if anyone has experience with this kind of architecture - either tools, or DIY. What are the advantages and pitfalls and what's the ROI, in your opinion. Any experience with MEF?


    Wednesday, June 15, 2011 5:47 PM

All replies

  • If it's an in house system I don't really see why you would have a plug in architecture at all.

    I think clickonce or a web application solves your distribution issues without introducing any extra complexity.

    Thursday, June 16, 2011 8:53 AM
  • The application consists of well over a hundred individual "applets" - screens that represent applications which, other than for some plumbing, act independently of one another. It would seem to me that a more formal extension of plug-in architecture would ease the development and maintenance process, though I don't have enough experience to even guess what kind of overhead there would be.

    I'm just wondering what's out there. What are people using? What kinds of patterns are helpful? Etc.

    Thursday, June 16, 2011 12:54 PM
  • I have worked with MEF on a couple of projects, and personally I like it. It is incredibly easy to add new extensions, it uses lazy loading (assemblies are only loaded when you need them), and it's easy to use. The only real downside is that you have to do a lot of up-front planning. You have to define exactly what information you need from each plugin up-front, and all plugins have to provide the same information. If the contract is changed later, it can cause a lot of headaches.
    Thursday, June 16, 2011 1:36 PM
  • The application consists of well over a hundred individual "applets" - screens that represent applications which, other than for some plumbing, act independently of one another. It would seem to me that a more formal extension of plug-in architecture would ease the development and maintenance process, though I don't have enough experience to even guess what kind of overhead there would be.

    I'm just wondering what's out there. What are people using? What kinds of patterns are helpful? Etc.


    Since these are independent already, what overhead are you removing?

    What are these applications written in?

    How much do they overlap?

    EG

    Do you have many views on the same data each used by separate roles.  Separating out the view into a plug-in would be a great match.

    or

    Do you have many discrete areas each with their own applet.  In which case you'd just be plugging in the applets to one central menu.

     

    So I guess my question would be.

    What are you going to plug in and to what?

    Thursday, June 16, 2011 2:28 PM
  • The informal process currently employed rests on properties and functions discovered and invoked using reflection (rather than interfaces) - so while there is some architecture, there is no proper enforcement of that architecture.

    Though the individual screens are not reliant upon each other, the assemblies and screens are, in effect, hard-wired into the core application (it must be explicitly aware of them) - so there is no dynamic discovery.

    The application must be installed in its entirety for 100+ users, though access to the different screens is controlled though Active Directory (fortunately our Click-Once deployment loads assemblies as needed, but we might not stick with Click-Once for the long term given some of the sandbox restrictions) - a proper plug-in/extension architecture would allow us to install applications for each user on an as needed basis (without having to lean on Click-Once).

    We are currently using WinForms with VB.NET 2.0, I believe. I would like to upgrade to WPF with VB.NET 4.0, but with over a hundred "applets", that'll be a long-haul process. I'm hoping to use the Win Form host to make the transition easier, but we use a ton of 3rd party controls which might hiccup on us.

    The application basically works as a central menu from the users perspective, and as a framework from a development perspective (things like uniform data access strategy, etc.)

    Like I said, I haven't done much plug-in work, but it seems this application lends itself to such an architecture and would benefit greatly from a more formalized definition of such, even though it is strictly internal.


    Thursday, June 16, 2011 9:44 PM
  • Well if it's internal you could use Systems center to deploy via script.

    Or, much more simply, a command file to xcopy.

    Or a custom loader.

     

    For long term compatibility I would strongly recommend WPF or Silverlight.

    With win 8, xaml based apps can be win 8 apps and winforms are probably going to become legacy.

     

    The third party controls will presumably be stuck with old versions of the framework and you might find you're better having your applets as separate exe.

    That points to something other than MEF (which loads into the same application).

     

    Maybe.

    Have some menu-like exe which uses some sort of config to list the possible applets, double checking it has the exe.

    So when you click on the button to start applet x you actually start another exe.

    You can then replace each applet at a time.

    If you wanted you could mix and match.

    Make the menu WPFand use mef to lazy load your replacement applets.

     

    I do winforms, wpf, silverlight and asp.net.

    There's quite a learning curve for xaml, wpf and MVVM but it's a great way to work.

    Friday, June 17, 2011 8:14 AM
  • i've seen many extensibility frameworks (EF) and did not like any of them.  Most of them require the actual application to invoke APIs in order to register types and/or kick-off discovery by way of specifying contracts ahead of time.  this is a silly way to do things because:

    1. the application ultimately is driving the discovery rather than the platform
    2. the application is bound to known types thus limiting future expansion
    3. the platform can be reduced to a fancy "class-factory" and not a true extensibility framework

    i was so disappointed i wrote my own.  client apps need only call a single startup() method on the platform at which point the platform discovers plug-ins by way of assembly interrogation.

    a true EF should know how to do one thing and one thing only - "load plug-ins".  everything else is plug-in driven.


    MickyD | http://mickyd.wordpress.com/ Help others by voting my post as 'Helpful' if you think it is so.
    Saturday, June 18, 2011 4:37 AM
  • Micky D, What patterns did you use to write your own? What kinds of issues did you encounter, and what kinds of services did you end up supplying to your plug-ins?

    Plug-ins seem simple on the surface, but I'm afraid there will be some huge headaches if I take the plunge and write my own framework.

    Monday, June 20, 2011 3:03 PM
  • Micky, I would disagree with your assessment of extensibility frameworks. The application writer should always define constraints which plugins must adhere to. Allowing a completely free plugin architecture is a huge security risk and makes things chaotic. If your plugins are really completely random and require no API interaction with each other or with your main application (other than being loaded) then they should not be plugins - they should be separate applications.

    Extensibility frameworks are not designed to take completely unrelated plugins and throw them in a sandbox together. It is to create organized extensibility, dynamic behaviors and customization, and easy maintenance. Just like components, each plugin should have a very specific purpose, and those plugins should be organized, maintained, and controlled by the hosting application.

    That's my philosophy and 2-cents anyway. I would not trust a completely "open" extensibility architecture - it opens the way for way too many maintenance problems in the long run.

    Monday, June 20, 2011 3:20 PM