CODEWITHSUNDEEP
asp.netdesign-patternsweb-applicationsdto
RobVious
RobVious

Reputation: 12915

Strategy for DTO pattern - multiple DTOs per entity or just one?

I'm building my first application with DTOs - I currently have one DTO for GETting data for a particular object, and another different DTO for updating (PUTting) data - since only a few fields can ever possibly be updated from any client, I decided to create a dedicated DTO for PUTting to avoid sending unnecessary data/fields over the wire. Is this good practice in terms of maintainability, or is this some kind of no-no?

Upvotes: 4

Views: 5044

Answers (4)

Zdeslav Vojkovic
Zdeslav Vojkovic

Reputation: 14581

I do use multiple DTOs per entity. However, quite often I don't even have a pre-defined DTO for a view, I just create an anonymous class instance which is a projection from entities using Linq and bind that to GUI.

E.g. showing the list of users

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

Showing the score board:

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 2 different DTOs. A potential drawback is that view is not strongly typed, so depending on version of ASP.NET MVC I need to declare view model as dynamic or use some ExpandoObject tricks, but it is all nicely hidden.

However, I always create DTOs for modifying the state and treat them as commands. I typically have different DTOs for different operations on entity, e.g. ChangeUserAddressDTO, ChangeUserLevelDTO, etc.

Upvotes: 0

Tim M.
Tim M.

Reputation: 54368

I have no problem with using the same type for multiple operations. Perhaps you have multiple GETs which return similar data for similar purposes. There's no reason you can't reuse the same type in that scenario.

However, you've identified that your GET and PUT operations require different data. So not only are they different operations, but they also need 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 benefits to creating a new DTO to meet the specific need, such as:

  • not confusing the developer (even if that's you!)
  • not opening a security hole whereby fields not intended to be used are populated

To make it easier:

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

Upvotes: 3

Atul
Atul

Reputation: 1774

Its not no-no but using the same DTO for CRUD will make it more maintainable in long run. Later you might have to change your code in all layer if a new field is added and removed. You never know when your client change their mind to edit more or less data.

Upvotes: -2

Ross Bush
Ross Bush

Reputation: 15175

It is a matter of choice. I have a habit of using orm mappers to reduce code. I have found that spending the time up front to define the saves and gets to work with one dto class allows for better scalability and maintainability, even if it means all fields get updated. There are edge cases. If tables makes use of fields with large gobs of blob type data then maybe you should subclass these updates somehow. It is a matter of opinion.

Upvotes: 0

Related Questions