Architect in our company is against DTO [closed]

Question

I have this easy DTO (Data Transfer Object):

public class SoonestOffersModel
{
    public Offer Offer { get; set; }
    public DateTime Date { get; set; }
}

Offer is entity. Our architect is against these DTOs, as he is saying this is very old and it is in need only when people don't think about design to include all fields before.

He is against model or database first approach and favors code first approach. In this case he has entity models pre-created.

So I asked him if we want to do some additional logic and apply Date with Offer entity for View purpose, he suggested I should've just add nullable DateTime field into entity model Offer itself.

First time hearing this. So if you have new requests each time to show more and more fields that correspond to Offer you are adding those in entity model?

I am not sure why DTO is bad, since I've always used it, and I don't do code first approach.

I would love to hear your opinion on how much this is true and if I should be worried about this?

Answer 1

It sounds as though your architect isn't against DTOs as much as your architect is against this DTO. They argue that having a DTO that is an Offer with a Date tacked on is a bit of a smell. I don't know if the Date should just be part of the Offer or not. In some cases, they should be distinct because the domain says that they should be separate things. In others, they should be together because the domain says they should be cohesive.

DTOs though are just there to create well defined, dumb bundles of data that serve as an implementation agnostic contract to some outside code. Sometimes that is some external API, sometimes it is your data store, sometimes it's just another module. That concept is good and fine, but it's just a tool. Good tools can still be misused.

Answer 2

"Code First" is the work of the devil. The data is what is important, the code is just some temporary processing that will come and go, be refactored, and even totally rewritten in time but your data is sacrosanct. So getting your schema right is far more important in the long run.

That said, a simplistic mapping of entities to DTO like you have is lazy and probably inefficient. To get the most from your database, you should be creating methods that perform specific domain processes and create an object to pass just the required data - not all the data the table or view returns. Ideally you'd be calling a stored procedure that returned a minimal set of data for the specific task.

Answer 3

Your DTO in this case is nothing more than the Offer object plus one field. I would agree with the architect in this case, one should just add the date to the offer object as opposed to creating a new object.

Typically DTOs would be smaller than your rich domain objects in your model. For example, the offer object might contain 50 properties, but sending that data (all 50) across the wire may not be needed. So we create a DTO with just the [N] properties that are needed to be transferred. Maybe its just 10 or 20 properties that need to go across the wire instead of the full blown model.

You may not need DTOs at all. If the object that is going across the wire is the same as the one in the model, why create another object? In this case the DTO object IS the object in your domain model + one field. Nothing wrong with that, just be careful to have a consistent approach of when and where to use a DTO.

Data and data structures are important. A poorly designed model and structure can make the system hard and nightmarish versus easy to extend and understand.

Answer 4

I tend to be suspicious of DTO. One of the goal of object oriented design is to have data and logic bundled together (in a class). A DTO, by definition, is pure data, with no logic.

In your specific case, it seems the the date and the offer have strong cohesion. If you want to keep the specificities of an offer with date and an offer without date, you might want to use inheritance:

public class SoonestOffersModel : Offer
{
    public DateTime Date { get; set; }
}

This would be a good time to re-read GRASP which will give you some pointers on how to choose where to put each responsibility...

Answer 5

The "Code First" approach is awesome. The database is just a persistence storage for the data that our code handles. It should be expendable. We should not need to care about it. We should be able to just drop the database and rerun our code and have it recreate the database from scratch.

In light of this, we don't need DTOs. Our class model is all that is necessary and sufficient to fully describe how the database schema should be. DTOs are just an unnecessary layer, serving no purpose other than making things look familiar to people who have a more traditional view of things.

We should be focused on writing code to solve the problem at hand, we should not be wasting our time curating the persistence storage.

Edit

Of course, all of the above depends on what kind of environment you are working in. If you are storing massive amounts of data which are being used by various different applications, then in your environment "data is king", so "code first" might be unsuitable for you. But I would assume that the architect in your company knows best what kind of environment you have over there.