ServiceStack DTO with inheritance

Question

According to Mythz (Getting ServiceStack to retain type information) he recommends not using inheritance in DTOs. What about the use case where I want every request to optionally provide an API key, or a location parameter? Are interfaces bad to use but abstract classes are ok? Anyone have any recommendation?

score 3 · Accepted Answer · edited May 23 '17 at 10:28

3

Your use case, "every request to optionally provide an API key, or a location parameter" is traditionally handled in SS through filter attributes

Here's an example where a required authorization header is managed both server-side and client-side.

Given the right requirements, Mythz has recommended the use of a custom interface in DTOs: "Request DTO that implements a custom ITenant interface that just has a Tenant property. Another solution is to use a IHttpRequest.Tennant() extension method that you can re-use inside all services which inspects the AbsoluteUri or RawUrl properties." See this comment: (Multi-tenant ServiceStack API, same deployment to respond to requests on different hostnames?)

edited May 23 '17 at 10:28

Community

1
1

answered Sep 09 '13 at 14:20

Pauli Price

4,187
3
34
62

How bad would it be if I just added another interface (in addition to the IReturn) to my DTOs? By "bad", I mean will it harm efficiency of serialization? – mariocatch Sep 09 '13 at 14:38
I couldn't say. I think this is just something you have to test. – Pauli Price Sep 09 '13 at 18:40

score 2 · Answer 2 · answered Sep 09 '13 at 14:06

2

I use interfaces and then check for implementations of the interface in a request filter.

answered Sep 09 '13 at 14:06

jeffgabhart

1,117
7
13

ServiceStack DTO with inheritance

2 Answers2