QUESTION: Why wasn't Managed Extensible Framework used?
I was wondering the other day if there was a reason Managed Extensible Framework (MEF) wasn't used when building the Plugin API? Was there any consideration of MEF during the design phase?
I would have loved to have Interfaces I could have hooked into and think it would have simplified the provider architecture. This is by no means a slight on sitefinity or the team, it is more of a discussion point. If it was not considered, is there a possibility of retrofitting MEF into sitefinity down the road?
Imagine allowing a routine to be called when a document is saved in the libraries or a routine being called when a user submits a comment or form. (I have actually started a Hooks widget/module for forms that implements MEF). It is very basic right now, but allows you to execute code in the plugin assembly when a form is submitted, before it is submitted and after it is submitted. This would allow a developer to validate something before the form is submitted, maybe update a database record or call a webservice when it is submitted and then send an email after it is submitted and would take very little code as apposed to what it takes now to simply send an email when the form is submitted.
Instead of this http://www.sitefinity.com/devnet/forums/sitefinity-4-x/general-discussions/forms-module-notification.aspx#1582212
The code would look something like this.
[EXPORT(typeof(ISitefinityFormSavePlugin))]
public class SHBSFormExport : IFormExport public string DebuggerOutputName get return "SHBSFormExport"; public void OnBeforeFormActionExport(System.ComponentModel.CancelEventArgs args) //Do something Before the Form Action like validate fields. public void OnBeforeFormSaveExport(System.ComponentModel.CancelEventArgs args, FormControl formControl) //DO Something like Update the form submission count for the user. public void OnFormSavedExport(EventArgs args) //Send an email to the person for the form. Hello John Tolar,
We use Unity framework which is a full-blown IoC container. In general, IoC frameworks serve similar purpose but are more generic and help the incorporation of other architectural patterns such as Separation of Concerns and Dependency Injection.
Unfortunately, IoC design is used only in the lower level APIs and that particular case that you are describing is not covered. You are indeed right; we should provide pluggable architecture at the UI level as well. Whether this should be MEF or Unity is really a matter of discussion.
MEF is specifically designed for plugins and supports only singleton services, which is probably just right for such scenarios. On the other hand Unity can do the same but it also provides capabilities that are far beyond plugin architecture which could be an overkill to learn.
I’m really curious to learn what the community prefers. Should we stick with Unity only, or may be provide support for Common Service Locator and support both, or plain MEF?
All the best,
Bob
the Telerik team
Thank you for being the most amazing .NET community! Your unfailing support is what helps us charge forward! We'd appreciate your vote for Telerik in this year's DevProConnections Awards. We are competing in mind-blowing 20 categories and every vote counts! VOTE for Telerik NOW >>