8
votes

We are building our first small implementation of ServiceStack and we need some clarification regarding DTO's located in a separate assembly that is shared between the client and the server.

The WIKI page for the new API recommends the following for DTO

In Service development your services DTOs provides your technology agnostic Service Layer which you want to keep clean and as 'dependency-free' as possible for maximum accessibility and potential re-use. Our recommendation is to keep your service DTOs in a separate largely dep-free assembly.

There is also this snippet

*But let's say you take the normal route of copying the DTOs (in either source of binary form) so you have something like this on the client:

[Route("/reqstars")]
public class AllReqstars : IReturn<List<Reqstar>> { }

The code on the client now just becomes:

var client = new JsonServiceClient(BaseUri);
List<Reqstar> response = client.Get(new AllReqstars());

Which makes a GET web request to the /reqstars route. When a custom route is not present on the client it automatically falls back to using ServiceStack's pre-defined routes.

My question is... does the "largely dep-free" assembly still require a dependency on ServiceStack due the the route attribute on the DTO classes?

1

1 Answers

7
votes

The [Route] attribute exists in the ServiceStack.Interfaces project, so you still only need a reference to the dependency and impl-free ServiceStack.Interfaces.dll. This is by design, we want to ensure the minimum dependency as possible which is why we'll try to keep all metadata attributes you might use on DTO's in the Interfaces project.

The reason for wanting to keep your DTO's in a separate assembly is to reduce the dependencies required by your clients in order to use it. This makes it less invasive and more accessible for clients. Also your DTOs represent your Service Contract, keeping them separate encourages the good practice of decoupling them from the implementation, which you want to continue to be free to re-factor.