Dynamic proxy

Dec 22, 2009 at 8:20 AM
Edited Dec 22, 2009 at 9:50 AM

I would like to create a factory to generate certain interfaces dynamically i.e. generate WCF proxy dynamically. I tried to write something similar to CatalogExportProvider. But as I tried to dig through it, it seems to use TypeCatalog that needs to find ExportAttribute on classes. There seems to be no way I can inject my own proxy discovery in TypeCatalog. It would be nice if we can do so so that we don't have to iterate through types many times....

Dec 22, 2009 at 8:23 AM

BTW, I saw http://blog.eworldui.net/post/2008/11/MEF-2b-Factories-Using-an-Export-Provider.aspx but haven't tried. Is ExportProvider quite similar to IBuilderStrategy in Unity?

Jan 5, 2010 at 11:34 AM

Instead of creating ExportProvider, I ended up creating my own Catalog to export all the types instead. Is it the most appropriated way to do it?

Jan 5, 2010 at 5:48 PM

You can certainly use a catalog. There are many situations where you can choose either a catalog or an export provider to do the trick. There is a big difference between the to though, and there are a set of things that catalogs can do that ExportProviders by themselves don't. Export providers provide a value. Catalogs provide part definitions which are composed (i.e. imports are satisfied / exports are pulled). As a result, ExportProviders are often far simpler to implement.

In this particular case if your proxies do not have a need to have imports injected (and I am guessing they don't) then an ExportProvider can work. I don't mean duplicating the CatalogExportProvider, as it is a specific implementation that ties very heavy to the catalog. I mean creating a light ExportProvider from scratch. ExportProviders are fairly easy to author, you inherit from ExportProvider and then override a single method.

You can learn more about Export Providers here: http://codebetter.com/blogs/glenn.block/archive/2008/12/25/using-exportprovider-to-customize-container-behavior-part-i.aspx

Here is a link to a sample EP I put together for talking to a CommonServiceLocator: http://www.codepaste.net/s6w6az

Hope this helps

Glenn

 

Jan 5, 2010 at 5:50 PM

Can you describe a bit more what you did in your catalog?

Jan 5, 2010 at 11:39 PM

First I created CustomCatalog inherited from ComposableCatalog and passing in assemblies/types in there. CustomCatalog will inspect all exported types. In my case, I just inspect all interfaces. If that interface implements my custom attribute, then I will include it in the list. After that, I start exporting all export definition for each interface upfront. For the construction, I overrided ComposablePart to construct my own dynamic proxy when there is an import matched with the export. I don't quite like this approach as I needed to scan types separately again where DirectoryCatalog already scanned it but it only looked for type/memberinfo having ExportAttribute applied.

Jan 5, 2010 at 11:47 PM

I see...I think this will likely be far easier to implement with an export provider.

With a simple export provider you won't need to do all that work. Instead what you would do is create exports on the fly to match the imports coming in. For example in the CSL EP I linked to above, here is the code that creates an export to pull from an IoC...

var export = new Export(definition.ContractName, () => serviceLocator.GetInstance(contractType));

In your case your export should call your DP. So if a part imports IOrderService, you would then create an export which invokes your DP mechanism to create it.

Thanks

Glenn

 

 

Jan 5, 2010 at 11:54 PM

But I need to find out the contract type from ExportTypeIdentity? Then I came back with the problem that I don't really know where that interface is located as it can be located in different assemblies. ExportTypeIdentity doesn't include assembly information in there. I have then also need to pass assemblies into the exportprovider and then iterating to do type lookup?

Jan 5, 2010 at 11:57 PM

I can see that you use RegisterType to register the type upfront. I think I can do the same thing but just as I mentioned previously. It means I need to do assembly/type scanning outside the catalog.

Jan 6, 2010 at 12:10 AM

Forgot to mention one good thing about ComposablePart, I can specify other dependencies to be used in GetImports. In my case, I need socket connection, serializer. I can inject those quite easily with ComposablePart...

Jan 6, 2010 at 12:11 AM
Edited Jan 6, 2010 at 12:12 AM

There is a way to get to the type :-)

You need to use our ReflectionModelServices API. Using it you can drop down to pull out the import and inspect the type. It will only work for contract based import definitions though.

Check this other codepaste which contains the code for my GenericCatalog and you'll see how to parse the definition.

http://www.codepaste.net/xtk68x

Thanks

Glenn

Jan 6, 2010 at 12:14 AM

An alternative approach is to take the type identity can call Type.GetType() passing it in. If the type is loaded in the app domain (and it should be as it's being imported), then you "should" get it back. This won't work for generic types though as the type identity format is different than the clrs for generic types.

 

Jan 6, 2010 at 1:31 AM

Aaah, you have imports. If you have imports than catalogs are the way to go. You might still want to look at using that ReflectionModelServices API as with it you could define a part for your proxy without having to create your own custom compososable part / definition, etc.

Glenn 

Jan 7, 2010 at 2:12 PM

this is a simplify version of WCF that using the Command pattern at the server side (the client sending logical target and the server is peeking the right command).
it is actually used in reallife (the none simplified version) by one of my colleague.

if you want to consider this design you can download the sample here

http://cid-9bf7c1a515d76a9a.skydrive.live.com/self.aspx/Code%20Samples/MEF/SDP/Yaniv%20MEF%20with%20WCF.zip