출처 : http://msmvps.com/blogs/kathleen/archive/2008/01/14/system-addin-scenarios.aspx
I started writing an entry about the System.AddIn pipeline and realized that post was not helpful without having a clue why you might be interested in System.AddIn. So, let me start here.
System.AddIn is designed to isolate portions of your application. It was designed for the scenario of AddIns. Despite the naming confusion, this has nothing to do with Visual Studio. System.AddIn is all about extending your application.
Let’s say you have a commercial application and some clients want to do extra stuff. Giving them back channel access to your database should give you an anxiety attack. With System.AddIn, you just build interfaces with very specific access to your business layer in a way you control. You create an API, and System.AddIn manages it for you.
Understand – with System.Addin and your API, later programmers do not alter your code. They do not even recompile or have the source code. They access your application on channels you define. And you can sandbox them as much as you like.
Don’t yawn. System.AddIn manages application domain boundaries so poorly behaved add-ins don’t crash your application making you look bad. That sand boxing thing is pretty important if there are third parties involved. And System.AddIn assumes your application and the add-in will independently version. You can version in a way that won’t break applications clients or third parties wrote for your application.
Actually, yes, you could have done all this yourself. .NET 3.5 sits on top of 2.0 so I know of nothing changed in the CLR that suddenly opens a new day. You could have written HashSet as well. Heck, there’s a lot in the framework you could have done yourself. But why would you want to. System.AddIn has Microsoft’s backing and commitment so it’s the way to provide application extensibility to your application going forward.
I believe System.AddIn is important beyond retail applications. Here are a few key scenarios:
You need to let your clients or third parties add functionality
Internally, you need to logically branch your application for multiple client’s business logic
Different clients need different WPF user interfaces
You need to unload code so it can be changed without closing the application
Different segments of your application will evolve at different rates
Interacting with a semantic based organization wide service bus
The second and third are similar, but I wanted to call out the fact that the WinForms model does not play well with System.AddIn. There is a workaround on the team blog involving hosting WinForm pieces in WPF on both sides. I haven’t done that yet but it looks like an interesting approach.
The fourth one is what drew me to System.AddIn. The new version of my code generation harness will have the best possible support for VB 9 XML Literal Code Generation. This means templates will be in assemblies and you’ll want to load the harness, run, change templates, run again. Stopping the harness for a small change would be a major pain. I need to unload after each harness run.
That’s not the only time I’ve wanted to unload an assembly. The last time was when we rejected doing customization through satellite assemblies because we could not update them without shutting down the application – and users would be updating localization strings on the fly. Honestly, we’d probably have a tough time anyway because satellite assemblies aren’t setup to run through System.AddIn and you would not want the hit of crossing the isolation boundaries. But we didn’t explore further because updating at runtime of any assembly required app domain isolation which brings in a slew of issues that the CLR team solved with System.AddIn.
The fifth will probably be the most important role of System.AddIn to most programmers within the next few years. One of the side benefits of services is that they allow independent evolution of different segments of your applications, with the corresponding versioning challenges. But what if you are working with an app that does not need service boundaries for deployment, or needs independent evolution within a single service boundary? Why use WCF if what you really need is versioning support? The concept of what an application is has changed in service based world, System.AddIn allows that same shift in thinking without service boundaries – it’s a different kind of API boundary.
I’m going to postpone discussing the last until I can do a really good job of it, and let my friend David McComb look over it. Dave expanded my view of coding in the most amazing way because of his insights on the range of the ecosystem from assembly bytes to organizations. I’d darn near work for free if I get another chance to work for Semantic Arts. My fingers are just itching to keep going on this…but I really need to wait and do it right.
These are some good reasons to keep an eye on System.Addin. There may be more. Prior to the PipelineBuilder release, System.AddIn was such a pain to use that I couldn’t recommend it. The beauty is that System.AddIn went from an absolute pain to downright easy in one day. It’s a tool you should understand for your arsenal, especially if you claim to be anything resembling an architect.
Look for more in upcoming posts…
