Functional or not, data transfer objects are a must.

  • 1
    We should just start calling them what they are: the public interface domain.
  • 1
    And now define what a DTO is.

    (I had very angry discussions about this topic. So it's a serious thing for me, as some people have VERY weird and brainfucked ideas what an DTO is)
  • 2
    @IntrusionCM no reason to get angry over interpretation. My understanding is there are several uses. My most common use is simply an object used to encapsulate data so each system layer using it knows how to expect that set of data. Also useful for methods that need more then 5-6 parameters. Anything more then 3 I would then require a DTO or curry it if it makes sense to.
  • 0
  • 0
    That's not what they're for though. DTOs are meant to do interprocess communication. That's it.

    IPC: DTO
    Application: Domain, Records
    Persistence: Entity

  • 2
    @dUcKtYpEd not angry at u or anyone else. Sorry for being offensive / rude.

    It's just this bad feeling mixed with a lot of bad memories.

    Some people eg. see this as an legitimate DTO:

    class DTO extends AbstractDTO {
    private int key;
    private string value;
    private Service bla;

    public DTO(Service bla) {
    this.bla = bla;

    public setKey(String key);
    public getKey();


    public doStuffWithDTO()
    return this.bla(this);

    It's not the worst I have seen... Very uncreative at the moment.

    Otherwise.... Pretty interesting ideas of having stateful DTOs.... DTOs must be OOP and contain logic. DTOs with several layers of composition....

    DTOs must be mutable for OOP reasons.

    :) When reading DTO my brain goes into " RUN FOREST RUN " mode.
  • 0
  • 1
    @SortOfTested how is inner process communication any different then my personal definition of providing data in a format across different layers of an application (different systems)
  • 1
    It's not "innerprocess" it's interprocess. A very specific term:


    We're just talking around each other. I didn't get the distributed concept, you missed a letter. We're a pair ;)
  • 0
    @IntrusionCM see not in any language I’ve worked with rather larsvel(php) or c# have I seen a DTO that has a high level of functionality involved. When working with HL7 which was very tricky to keep track of what needs what, What we called DTOs existed between every systems piece of functionality. If it makes everyone happy I can just say I need a fuckin object that represents the data I need shared between 3+ services so that the dependent data is never confused. I can ..... just quit using acronyms and be as literal as possible lol
  • 0
    I want to be a correct as possible when using these terms but it seems I’m not finding the definition to match what is I’m using. Hahaha
  • 2
    @dUcKtYpEd yeah... those definitions of mine are completely bogus.

    Don't do that.

    An DTO can have different meanings, as each language has it's own PITAs.

    When I would define a DTO, I'd usually come up with the following:

    It's a simple object that has no logic and has the sole purpose of being a container for data.

    If you need an immutable DTO, it would be what many people call a value object.

    The reason for DTOs is very simple - as SortOfTested pointed out - to eg deliver data from one layer to another.

    Best example is usually an database entity. An database entity shouldn't be anywhere used except in the database layer. If u need to pass data around, put into an container and ship it (aka the DTO).

    That's the reason I'd avoid most OOP stuff, too. As an DTO is just a container or value holder, it's replaceable.

    If you add logic or association / composition to it, it will become a bloody mess to untangle and the sole container / value holder isn't replaceable anymore or easily changeable since it's inweaved with other objects / classes / logic.

    For some people a DTO is a value object, but there should be a distinction imho. A value object is immutable and mostly consists of a constructor to set the values, and getters to return values.

    A DTO can exist simply with public fields imho, since it's just to ship data.
  • 0
    Whatever you call DTO (Data transfer object sounds simple )
    It is a life saver , like no need to explain another dev properties of an api just give him DTO
    Like no messing up of web with mobile , just give mobile dev a DTO

    Dynamic data required, no worry just have a DTO with properties required as filled values keeping other null.

    Having a list of similar data just DTO comes to rescue...

    DTO may not have its own data, but surely it is no less than a super hero with super powers in coding...

Add Comment