Strategy for DTO template - multiple DTO per object or only one?

Question

I am building my first application with DTO. Currently, I have one DTO for receiving data for a specific object and another DTO for updating data (PUTting) - since only a few fields can ever be updated from any client, I decided to create a dedicated DTO for PUTting to avoid sending unnecessary data / fields by wire. Is this good practice in terms of maintainability, or is it some kind of no-no?

Answer 1

I have no problem using the same type for multiple operations. You may have several GETs that return similar data for similar purposes. There is no reason why you cannot reuse the same type in this scenario.

However, you find that GET and PUT operations require different data. Thus, this is not only different operations, but also different data.

+----------------+-------------------+--------------------------+ | Similar Data | Similar Purpose | Try to Reuse | | Similar Data | Different Purpose | Consider; is it logical? | | Different Data | Similar Purpose | New Type | | Different Data | Different Purpose | New Type | +----------------+-------------------+--------------------------+ 

There are other advantages to creating a new DTO to meet a specific need, for example:

• Do not confuse the developer (even if it's you!)
• Do not open a safety hole in which fields that are not intended for use are filled.

To make it easier:

• interfaces can be used to enforce common fields between types.
• The ASP.Net Web API (not sure if you are using your question) has strong support for dynamic inputs . This can eliminate the need for DTO (albeit at the expense of less compilation time).

Answer 2

This is a matter of choice. I have a habit of using orm mappers to shorten code. I found that spending time determining storage and working with the same dto class improves scalability and maintainability, even if it means that all fields are updated. There are regional cases. If your tables use fields with large amounts of blob data, you might need to subclass these updates in some way. This is a matter of opinion.

Answer 3

I use several DTOs for each object. However, quite often, I don’t even have a predefined DTO for presentation, I just create an instance of an anonymous class, which is a projection of objects using Linq, and associates them with a graphical interface.

eg. showing a list of users

 var users = ... // fetch from DB ViewData["users"] = users.Select( u => new { Id = u.Id, Name = u.First + " " + u.Last}); 

Display invoice:

 var users = ... // fetch from DB ViewData["users"] = users.Select( u => new { Id = u.Id, Name = u.Last, Score = u.Score}); 

This saves me from creating two different DTOs. A potential drawback is that the view is not strongly typed, so depending on the version of ASP.NET MVC I need to declare the view model as dynamic or use some ExpandoObject tricks, but all this is perfectly hidden.

However, I always create DTOs for state changes and treat them as commands. Usually I have different DTOs for different operations on the entity, for example. ChangeUserAddressDTO , ChangeUserLevelDTO , etc.

Answer 4

It is not, but using the same DTO for CRUD will make it more convenient to maintain in the long run. Later, you may have to change your code throughout the layer if a new field is added and removed. You never know when your client will change his mind about editing more or less data.