CODEWITHSUNDEEP
c#design-patternsdto
Rahul Kushwaha
Rahul Kushwaha

Reputation: 561

How to design DTO for this scenario?

I have the following situation:

User Object

I want to use DTO pattern for transferring the user information between different layers.

Questions:

  1. Should I make a large DTO containing all the properties of both of the Service Object and the DB Object?

  2. Should I create Third Party Data Objects as properties of the DTO. I mean hide the Service Data objects behind an interface and make that interface as a property of the DTO.

  3. Do I need to make interfaces for DTO in case 1 or 2?

Upvotes: 0

Views: 702

Answers (1)

MutantNinjaCodeMonkey
MutantNinjaCodeMonkey

Reputation: 1249

Generally, the best DTO design has to do with the requirements of the client and the method/function that's returning it. I'm assuming you're doing this for purposes of serializing results.

If you're simply mapping all of the data you're storing to a DTO, you've not really gained much, and could probably just emit the data object you've stored in a serialized way.

So to answer your questions

1) No. You should make a DTO with data that's relevant to the call you're making for a few reasons..

  • DTO's are generally transferred over the wire in a serialized way. So smaller = less data.
  • There can be overhead to populating and serializing a DTO. You don't want to penalize every call that returns a large DTO with a burdensome process just to populate a property that isn't relevant to the purpose of the call.
  • It might be a bit more self documenting.

Keep in mind that it's okay to send some "irrelevant" bits of data for purposes of code re-use. Just be mindful of how much data that is, and how much effort the process takes to generate the data. No hard and fast rule here more than what makes sense in terms of readability and efficiency.

2) Depends on your application, but I'd be inclined to say that knowing it's 3rd party data isn't usually relevant to the calling client getting the DTO. The 3rd party you're getting your data from could be getting it from 3rd parties as well. But the DTO's they are returning to you are likely not singling that data out for you.

3) Interfaces, again really has to do with the app you're developing. From the client perspective, any interface isn't going to mean much unless you're supplying the library of DTO's in an assembly. If the DTO's are being generated by a proxy (such as adding service reference), or the client is creating their own client-side verions of the DTOs, those interfaces won't carry through to the client.

Upvotes: 3

Related Questions