tag:blogger.com,1999:blog-15136575.post40920963660415509..comments2023-10-17T12:00:16.772+01:00Comments on Code rant: Managed Extensibility Framework: Why?Mike Hadlowhttp://www.blogger.com/profile/16441901713967254504noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-15136575.post-613993849104947482008-09-26T16:15:00.000+01:002008-09-26T16:15:00.000+01:00Ayende has a good post on this:http://ayende.com/B...Ayende has a good post on this:<BR/><A HREF="http://ayende.com/Blog/archive/2008/09/25/the-managed-extensibility-framework.aspx" REL="nofollow">http://ayende.com/Blog/archive/2008/09/25/the-managed-extensibility-framework.aspx</A>Mike Hadlowhttps://www.blogger.com/profile/16441901713967254504noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-13929700457972265612008-09-10T13:12:00.000+01:002008-09-10T13:12:00.000+01:00The generic IoC container used by Microsoft here i...The generic IoC container used by Microsoft here is "Unity".<BR/>See http://msdn.microsoft.com/unityMohamed Meligyhttps://www.blogger.com/profile/06133694828261636610noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-16668194741910819442008-09-09T22:16:00.000+01:002008-09-09T22:16:00.000+01:00You "could", techincally however some things will ...You "could", techincally however some things will behave differently than you think. <BR/><BR/>For one thing our lifetime / instancing story is not what you would expect with a traditional IOC today. <BR/><BR/>There's no way to register a keyed instance at runtime. You can add multiple instances to the container that have the same contract. But the only way to find a specific one would be to import the entire collection, i.e. IEnumerable of ILogger, and then iterate through it to find the one you want. <BR/><BR/>Let say you had a list of exports that each one needed to be associated with a specific Order. You'd have no way to add this export with a key for Order123 and this one for Order234. You would have to add orders to the container and find them yourself by doing a GetExports() for example.<BR/><BR/>This is not broken, its because MEF's discovery mechanism is focused on the "types" of things you bring into the system rather than the instances of those types. Even the metadata you add to contracts it type (part) related, and doesn't change at runtime.<BR/><BR/>The point is not that you can't use it, it is what is it optimized for. You can use / misuse technologies in lots of ways. You can write a for loop that makes 1000 web service calls for example. But is that a good use of the for loop? You can use Biztalk when all you need is a simple file scanner. <BR/><BR/>It's the same thing here, you can use MEF, but in doing so you are forcing yourself to conform to a design that was build to address a different set of concerns than you are addressing.<BR/><BR/>Not sure if this is making any sense.Glenn Blockhttps://www.blogger.com/profile/07655000103244874233noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-33346318441448939732008-09-09T16:27:00.000+01:002008-09-09T16:27:00.000+01:00Glen, thanks for the comment.You're right of cours...Glen, thanks for the comment.<BR/><BR/>You're right of course that the primary reason that people use IoC containers is not as a plugin framework. But that doesn't mean you can't use them like that. In fact I think the kind of discoverability that you describe would be a nice addition for something like Windsor. From my naive point of view I still don't see the reason for having two separate frameworks that do pretty much the same thing: dependency resolution and object lifetime/lifestyle management. Sure you can provide a bridge between MEF and a 'traditional' IoC container, but surely it would be better for MS to provide a generic IoC container with the discoverability functionality added. Or is there some architectural reason why a generic IoC container isn't a good starting point for the plugin features?<BR/><BR/>Just for the sake of argument, what is there to stop me from using MEF in a traditional IoC role? You say that non-attribute based configuration will also be available, so couldn't I just ditch my current IoC container and just use MEF as the one-container-to-rule-them-all?Mike Hadlowhttps://www.blogger.com/profile/16441901713967254504noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-52029237894651813452008-09-09T06:42:00.000+01:002008-09-09T06:42:00.000+01:00I forgot to mention additional support that we hav...I forgot to mention additional support that we have for the scenario which is our contract adapters. You'll see an illustration of this in the MEFTris example. Essentailly it allows adapting one contract to another. One place this is important is in supporting multiple versions of a plugin in the same app. A second is for doing adapting to a completely different type, which we do in MEFTris with shapes.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-47219045038376437242008-09-09T06:20:00.000+01:002008-09-09T06:20:00.000+01:00Chad, MAF has app-domain facilities, MEF doesn't. ...Chad, MAF has app-domain facilities, MEF doesn't. The acronyms are close. :)<BR/><BR/>MEF does have features similar to DI containers. This is because we've seen DI from a pattern perspective as a fine way to solve a specifc problem. It is that problem that we are optimized for which is discovery of extensions. Really what that boils down is our implementation. MEF includes catalogs and such for discovery. These are first class citizens. That discovery mechanism (at least the default ones) use attributes as the mechanism for how parts are discoved. <BR/><BR/>This discovery mechanism is focused on extensions for the system that are not predetermined. Additionally MEF a layer of metadata above and beyond the parts themselves which helps facilitate this discovery. This allows upstream querying of the container not just based on type but based on the metadata as well. <BR/><BR/>Why is that important? Because MEF applications adapt themselves based on what is available at deployment time. A further difference between a traditional IoC is the notion of exports, our exports are very different than a simple type registration in the container. <BR/><BR/>All of these differences are specifically based on supporting app-plugins / non-determinant scenarios. That is allowing a vendor to ship a 3rd party dll that you just drop in the bin folder and your app "lights" up. In these cases the person who owns the app is not the person who wrote the plugin. Furthermore in many cases the person who added the plugin is a third person..the user.<BR/><BR/>Is this the reason generally that people use IoC today? Not really. The primary reason (at least in my experience) is for the internal decoupling [like for supporting TDD] that you mentioned, as well as the framework aspects like interception, etc. In these cases the pieces getting thrown in the container are not indeterminate but determinate. Meaning when I do a unit test, I know what I am throwing in the container. When I run my app, I know what is being registered. Normally I am the person who owns the code of the app as well as the pieces being plugged in. For these reasons having pure convention based configuration and such make a lot of sense. <BR/><BR/>Because of this, we think the two actually can play well together. At the ALT.NET meeting in Seattle, we recently discussed this and it seemed to have legs. To make it possible we would need some kind of bridge both ways between the two. An IoC can talk to MEF for MEF things, and MEF can talk to IoC for all other IoC things. <BR/><BR/>Let's take an example. Imagine I have a part that imports a logger in its constructor. That part also exports itself. Now I could have MEF import my logger (i.e. I mark the logger as an export). However, when my app is deployed, that's not likely the kind of thing that I just want you to drop the logger in and it works. So if I have a bridge, MEF can ask the container as its building up the part if it can supply an ILogger. If it can then MEF uses it. If no container is present than MEF will rely on its own facility. You could also imagine going the other way. So Windsor has a component that requires a pluggable authentication service that "might" be in MEF, depending on the configuration. So the container is hardwired to ask MEF if it can provide an IAuthenticationProvider. If it can, the containerr uses it, otherwise it reverts to its internal registry.<BR/><BR/>This is just an illustration to start the conversation going.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-33534100853678409282008-09-08T18:51:00.000+01:002008-09-08T18:51:00.000+01:00What about when you want to unload a plugin? MEF ...What about when you want to unload a plugin? MEF manages app domains and such. I see as MEF overlapping a little with IoC containers, but it does have functionality that most (all?) .NET IoC containers do not have.<BR/><BR/>It's possible that some of the containers will lean on MEF to provide remote load/unload capabilities (in another app domain)Chad Myershttps://www.blogger.com/profile/14930587550535317718noreply@blogger.com