Extending the configurability #121
Description
@faniereynders - you may recall I posted a few remarks to you yesterday. Let me tell you why I am looking at WebApiProxy and this problem area in general.
What I'm seeking is a way to have applications be able to leverage service functionality either as a true service or by invoking a locally loaded (into the app's AppDomain) assembly. My goal is for developers to be able to test complex multi service scenarios without necessarily having to have access to true, hosted IIS services (or running multiple local IIS Express services).
WebApiProxy certainly seems to do much of what is needed but would need to be further extended to allow a client to configure local as well as remote definitions.
I was reading what you posted here - which was helpful for me to see how you designed all this.
This shows an example of a proxy config file. The XML would need to be enhanced to allow us to define an assembly file and so on, rather than a URL etc. Then with the correct configuration the client would generate proxy code for the classes/methods in the assembly.
However this would mean that we'd need to interrogate the assembly in a similar way to a service (to get the detailed metadata) and this in turn implies we'd need to introduce a pattern (and attributes) that enable us to describe ordinary code (in our assembly) just as we describe (attributes) the code in the controllers.
Obviously here - our service is (in its actual implementation) is calling into these "business" assemblies and the REST service is nothing more than a thin wrapper around the assembly.
So to summarize an app under test (by a developer say, working at his desk) is either
- Making direct calls into the business assembly (but via a generated proxy).
- Making service calls to a service, which then itself makes direct calls into the business assembly (via a generated proxy).
What are your thoughts about this?
Thanks.