Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Inheritance in DTOs is a bad idea - DTO's should be as self-describing as possible and by using inheritance clients effectively have no idea what the service ultimately returns. Which is why your DTO classes will fail to de/serialize properly in most 'standards-based' serializers.</p> <p>There's no good reason for having interfaces in DTO's (and very few reasons to have them on POCO models), it's a cargo cult habit of using interfaces to reduce coupling in application code that's being thoughtlessly leaked into DTOs. But across process boundaries, interfaces only adds coupling (it's only reduced in code) since the consumer has no idea what concrete type to deserialize into so it has to emit serialization-specific implementation hints that now embeds C# concerns on the wire (so now even C# namespaces will break serialization) and now constrains your response to be used by a particular serializer. Leaking C# concerns on the wire violates one of the core goal of services for enabling interoperability.</p> <p>As there is no concept of 'type info' in the JSON spec, in order for inheritance to work in JSON Serializers they need to <strong>emit proprietary extensions</strong> to the <a href="http://www.json.org/">JSON wireformat</a> to include this type info - which now couples your JSON payload to a specific JSON serializer implementation.</p> <p><a href="https://github.com/ServiceStack/ServiceStack.Text/">ServiceStack's JsonSerializer</a> stores this type info in the <strong>__type</strong> property and since it can considerably bloat the payload, will only emit this type information for types that need it, i.e. <code>Interfaces</code>, late-bound <code>object</code> types or <code>abstract</code> classes. </p> <p>With that said the solution would be to change <code>Animal</code> to either be an <strong>Interface</strong> or an <strong>abstract</strong> class, the recommendation however is not to use inheritance in DTOs.</p>
    singulars
    1. This table or related slice is empty.
    1. POGetting ServiceStack to retain type information
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USmythz
    1. USmythz
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POGetting ServiceStack to retain type information
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COWhat to do in the case where I have multiple services that take essentially the same DTO? For example a user registration service and a user maintenance service? Both expect a UserAccount DTO with some difference in which fields should be filled in. The repository is expecting a UserAccount DTO because it's going to be inserting or updating the UserAccount table. So I created a UserAccount DTO. The UserRegistration DTO and UserMaintenance DTO inherit from it. [Also want to add here a big thanks for creating ServiceStack.]
      singulars
      1. PO
      1. USGeorgeBarker
    2. COUgh...to answer my own now seemingly obvious comment/question: A message should not "be" a business domain object, it should "contain" one (or more). A simple matter of "has" vs "is". So for my example the UpdateUserMsg and RegisterUserMsg would both contain a UserAccount DTO. Neither would BE a UserAccount DTO. No need for inheritance.
      singulars
      1. PO
      1. USGeorgeBarker
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload