the Autoquery/IQuery concept seems to be lending itself towards a more generic handling of query-oriented messages.
In turn, the REST-collections-with-HTTP-Verbs is a very elegant way of handling entity-types and their child collections (and the basic CRUD operations of each)
It makes sense to me, therefore, to use a Command-Handler pattern for the balance of the service interaction (ie: Actions). I noticed that there are some classes that seem to be geared towards this in ServiceStack already.
my questions :
1. is there any special processing/handling for the Command-Pattern classes in the ServicesStack stack?
2. using CommandHandlers gives me a neat little testable triangle of classes comprising a Command message, a CommandResponse message and a CommandHandler class into which I can inject my dependencies (which I can unit test without running full service-stack integration tests); but this means that I will have ServiceStack services that do no more than use the CommandHandlerFactory to get a Handler instance and run it (basically a very thin orchestration layer of repetitive code). Would there be a way to hook into the pipeline to run this boilerplate code for all classes implementing the ICommand interface, so that this repetitive code can be bypassed? My entity interactions and query interactions are likewise simply being passed on to an IRepository implementation - which could perhaps similarly be handled in a generic fashion from within the Pipeline based on the presence of an IQuery/IEntity interface? what do you think?
What you’re describing sounds similar to ServiceStack’s Request/Response DTO and Service handler. You also don’t need a full HTTP stack to test Services as they’re pretty testable in isolation: https://github.com/ServiceStack/ServiceStack/wiki/Testing
A way to add generic behavior across all DTO’s is to have them share an interface, which you can check for in Typed Filters (or normal filters) to apply custom behavior:
https://github.com/ServiceStack/ServiceStack/wiki/Request-and-response-filters#typed-request-filters
or Custom Service Runner: https://github.com/ServiceStack/ServiceStack/wiki/Customize-HTTP-Responses#using-a-custom-servicerunner
For an automated AutoQuery-like solution that saves having to write a 1 line methods you can just do the same thing that AutoQuery does 
i.e. code-gen 1-line stub implementations:
https://github.com/ServiceStack/ServiceStack/blob/master/src/ServiceStack.Server/AutoQueryFeature.cs#L175
Which makes it behave like normal Services, i.e. shows up in metadata, etc. This does make it more “magical” and less visible/debuggable as you’ll lose the typed Entry Point into your services.
Ryan Britton:
awesome! thanks for the direction, Demis. I think I’ll approach things the same way that you did with the AutoQuery Module…