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?

  • 2
    DTOs are for avoiding needless remote calls. It seems your case is more about having a presentation model that differs from the domain model. It's hard to tell since you give very little information about the change you've made. What's the date really about? How does it relate to an Offer? When it gets created? Can it change? Is it persistent?
    Commented Nov 30, 2015 at 14:02
  • It is persistent. It appends date to each offer, since offer doesn't have the date, it stores for example byte for dayOfWeek, and from that I have to calculate DateTime and return to mvc view.
    – sensei
    Commented Nov 30, 2015 at 15:21
  • Sounds more like a ViewModel than a DTO to me.
    – Eric King
    Commented Nov 30, 2015 at 21:15

5 Answers 5


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.


"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.

  • 6
    Although the data is important, I don't think it has to be the most important thing in the software. I prefer domain driven design, which focuses on business logic, rather than relying on the data. I mean, I don't reall care what the real data is and where it comes from, as long as when passed to my domain it is processed correctly.
    – Andy
    Commented Nov 30, 2015 at 13:24
  • @DavidPacker you're quite right - I used 'data' to mean schema (or domain) as I was trying to emphasise the non-code aspect.
    – gbjbaanb
    Commented Nov 30, 2015 at 13:28
  • My bad, sorry, misunderstood your answer.
    – Andy
    Commented Nov 30, 2015 at 13:31

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.


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...


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.


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.

  • 3
    This reads awfully like Mike Nakis might be the architect in question
    – JamesT
    Commented Nov 30, 2015 at 13:03
  • @JTolley LOL! yes, you are right, it would be quite funny if it was so. But no, I don't know John, and in all likelihood we live thousands of kilometers away.
    – Mike Nakis
    Commented Nov 30, 2015 at 13:07
  • 2
    That's fine if your data is transient or simplistic. If your data is used for business purposes, though (e.g., you're working with orders or inventory levels) then you really should put some thought into how to store and structure it.
    – TMN
    Commented Nov 30, 2015 at 14:15
  • @TMN, well, describing the data in terms of the class model does not in any way imply that no thought is being put into how it is structured. But in general I agree with your remark, so I amended my answer.
    – Mike Nakis
    Commented Nov 30, 2015 at 15:03

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