1

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?

|improve this question
  • Which of the alternatives leads, in your eyes, to simpler code? – Doc Brown Jun 4 '18 at 11:27
  • Well, I guess if I opt to restore the relationship then its simpler to have both the reference and the id in one object. But am not sure whether it makes sense to do so. I trying to find out if there is standard approach I can follow but maybe there isn't one and it just depends on situation. – Shane Jun 4 '18 at 13:17
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.

|improve this answer
  • So I guess what you are saying is there is no one right way of doing it which is the conclusion I am coming to. In our case there a potentially four sets of objects - the objects that are pulled from the database, the objects that are sent out from the web service, the objects that are received from the webservice and finally the objects that are consumed by the client. Its starting to sound like a lot of duplication if we keep parallel class definitions for each. – Shane Jun 5 '18 at 2:37
  • ORM has little to do with BLL. – Basilevs Jun 5 '18 at 3:01
  • @Basilevs: ORMs can avoid the need for having a separate DAL. But not every ORM is equally well suited for this. – Doc Brown Jun 5 '18 at 5:25
  • @Shane: the more of these objects you can generate from a common meta description, the less painful this duplication is. – Doc Brown Jun 5 '18 at 5:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.