Suggestions: make it more agnostic, get rid of inheritance #125

Austin,

I think JSON-RPC.NET is very inspiring, to say the least.

Still, I think it can be improved in the following way: you can keep your/users' service classes more agnostic to JsonRpcService and developed independently, without any coupling with your framework.

From your code sample and documentation is apparent that the service classes should be derived from JsonRpcService.
(Please prove me wrong if I'm wrong.)

This is the unnecessary coupling. If a user has some already developed service functionality, the need for this inheritance can break an existing class hierarchy and create some hassles. Take into account the absence of "strong" multiple inheritance (for classes) in .NET. At the same time, it's quite possible to make the same functionality agnostic to the hierarchy.

To bind the existing service class with the RPC, you can use either the existing service-implementing class or even the interface matching the service contract. You need some "registration" facility to use reflection to collect all the information on the contract, that is, the methods marked with [JsonRpcMethod] (or other attributes like that), with all the metadata related to the method: name, profile, and so on. You can register the implementation class with the facility. Even better, you can register the implementation and its interface (during runtime, check up if it implements the interface during runtime), having the interface accessible to both client and service assemblies, so the client part would need only the interface, and implementation on the client side would be some proxy. Moreover, you can also use .NET Reflection.Emit (maybe you already do, please clarify), to improve the performance, which would boost if you have more than one service implementation.

I believe this architectural change can greatly improve the usability keeping the performance.

Thank you.
—SA