Is it usual to "re hydrate" DTOs into full objects with relationships when consuming web services?

Question

We are designing a web API to transfer objects obtained from a database to a client application which is a front end GUI. The server side business logic will be implemented (for better or worse) in stored procs.

To minimize the size of transferred objects, integer ids will sent in the case that an object references another object only the id is sent so for example a customer record might consist of customer_id, name, address and company_id and there would be a separate method to send companies which might be represented by company_id, name.

So the client will have a set of minimal DTO objects with just data fields with no object references. My question is whether it is usual to take these objects and then use them to build richer objects which hold references to other objects? Additional business functionality may also be added to these object.

So for example a Customer object would hold a reference to a Company object. This would mean having two versions of each type of object. One which is a DTO and one which is I guess is a business object.

Or, would it make sense to just have one type of object which has everything, with id and reference fields which are populated after all objects are pulled down from the web service?

Answer 1

First, it does not matter if your DTO objects are coming from a web API or from a database, they are persisted somewhere, and the essential problem is quite the same in both situations. So lets say those DTO objects live in a data access layer (DAL), and the business objects in a business layer (BLL).

There are people prefering to have a DAL and a BLL separated, even if this leads to a lot of similar looking code in both layers (for example a DalCustomer and a BllCustomer like in this older SE question) .

And there is also the approach of avoiding this duplication by using an ORM framework which makes this distinction quite obsolete (see the discussion below the linked question, and also the controversial answers).

So which approach you choose is up to you, it should depend on the tools you have available. However, I recommend to care for two things

• make a decision for one approach, don't mix them.

• avoid having to write duplicate or boilerplate code manually. For example, if you can generate your DTOs or parts of your BLL objects from the meta data of the web API, I recommend to do so. If you go for DAL and BLL separated, look if you can utilize something like an automapper.