JsonServiceClient methods and IReturn

Question

In our team, we use the request and response DTO's, through our hierarchy of business logic assemblies (beyond the isolated DB DTO's ).

We have a requirement for no SS dependencies at the business logic layer.

So we don't use the IReturn or IReturnVoid interface. We use only simple c# objects without inheritance.

As for the Routing, we use the Fluent API, in the AppHost.Configure, creating essentially a routing table.

ServiceStack behaves exceptionally well, in our case.

Our Service.Model can be used from the business logic layer, without dependencies.

The service function is a thin wrapper actually, calling the business logic function, to return the response DTO.

But the JsonServiceClient.Get function accepts only as parameter an IReturn object, OR directly the URI.

It does not accept an object as parameter , like the Post function.

Any advice ?

Update 1.

mythz,

About IReturn, unfortunately, in our case there are requirements not using in business logic modules,

even the lighter SS dependency.

The service functions are a thin wrapper calling the business modules.

The link between the two layers are only the Request and Response DTOs. We like very much this approach.

Yes, they are "message operations" but they serve as messages also between the application layers.

Also my clients mainly are Jquery Ajax, not C#. Because of the mobile, the great majority inclined to Jquery Ajax.

So, in our case, we can use only objects, not marked with IReturn. ServiceStack behaves very well.

Answer 1

The API only accepts IReturn<TResponse> to make it clear that it only accepts and works with Request DTO's and not just any DTO or object. Request DTO's are "message operations" and shouldn't be re-used for anything else, the DTO types can be, but not the Request DTO which is your external facing service contract and shouldn't be coupled to any other concerns.

The DTO attributes like [Route], IReturn<T>, [Api], [Restrict], etc are just extra metadata that can't be expressed in C#, but just like defining the type of a DTO property, it's still metadata describing the service, and if you attribute them on the DTO's then they become sharable and introspectable on the client as well. E.g. the ServiceClients will only be able to use the custom routes defined with [Route] because that's the only information clients have, if there are none it will end up falling back to using the pre-defined routes.

ServiceStack encourages defining IReturn<T> markers as it lets you infer more about the service by glancing at the Request DTO, ensures services are restricted in returning the same type (good practice) and centralizes what the Service returns rather than spreading out over the different (more verbose/non-DRY) call-sites, which also means if you change the Response a service returns you'll get compiler feedback on which call-sites needs updating. Not everyone is aware of this info/behavior which is why ServiceStack wants to encourage this "pit of success" development by encouraging the use of IReturn<T> markers, so not everyone has to be.

As for the dependencies, the only dependency your DTO's should need to reference is ServiceStack.Interfaces.dll which is purposely a light-weight, impl-free dll. In v3 this needs to reference the ServiceStack.Common NuGet pkg but for v4 we'll provide a stand-alone ServiceStack.Interfaces NuGet pkg providing the minimum/lightest dependency your DTO's can reference.