In my last project I used a Javascript framework called ExtJS with Asp.Net MVC acting essentially as lightweight webservices serving up snippets of JSON. ExtJS has a package called ExtDirect. What ExtDirect does is build up a Javascript client proxy using reflection to gather information about all your Controllers and their Actions. Calls, which can be batched, are then made via the client proxies to a DirectController which then instantiates your controllers and dispatches requests to them.

I was wondering if anyone had implemented something similar for WCF and here it is. I look forward to diving into it.

that’s great.

> typical WCF proxies are not generated with an interface and are not often used through an interface (unless you actually put in a bit of effort > to do so).

Normally you should extract an interface all the time, I consider that as best practice when working with WCF. Therefore it consider it easier to mock against an strongly-interface interface / contracts. In your case you need to know for example that HelloWorldRequest produces a HelloWorldResponse and this you cannot see in the contract. That is what I meant by knowledge of implementation details.

In the end you put a facade in front of you fine-grained services (in agatha those are different request handlers). I programmed something similar building on WCF message contracts, basically the same goal in mind . But at the moment I have a deeper look into REST

yes, the WSDL contains all the possible contracts:
http://davybrion.com/blog/2010/05/consuming-an-agatha-service-from-a-non-agatha-aware-client/

as for the stubbing/mocking being easier… typical WCF proxies are not generated with an interface and are not often used through an interface (unless you actually put in a bit of effort to do so). If you have many proxies, you need to do that for each proxy. With Agatha’s request dispatchers, you don’t need to do anything since they already implement an interface and you always use them through the interface

Another question comes into my mind: Why is stubbing/mocking a generic interface easier than stubbing/mocking the fine-grained interfaces? In order to mock the generic interface you described, you need to have implementation knowledge of the service.

I share your view of the disadvantages of regular WCF usage though. But my current preference is using a RESTful service design.

I’m torn as it does solve a very real problem, but at the same time, it hinders discovery of operations. To some extent, this is offset by the request classes, but there is a danger here of not knowing exactly how much data you need unless you create a request per call (whereas a method signature is much more explicit in terms of the parameterization).

good to know

if you ever run into problems with it or have any questions, just mail me

Pretty good. We have replaced Castle with Hiro and put our own implementation of KnowTypesProvider, but other than that, your code works just fine.

the complexity is isolated within the infrastructural classes… the actual request handlers are as simple as they can be, so i don’t see why it would be over engineering

Your design is interesting though I have my reservations about the value addition it does versus the complexity it brings. The main driving point for me in your arguments is – coarse / fine grained operations & both have their own disadvantages. I would still prefer going for coarse grained the reason being they are more explicit, easy to understand & consume. I agree it would add duplication of code (considering it might be duplicated for different clients / scenarios) but this duplication is more of instantiation & packing (not any algorthmic one). I would have fine grained repositories which inturn would create data & expose them through coarse grained contracts. Your solution looks like over engineering.

ah, cool! how has it worked out so far?