5

Suppose there's an object that contains only setters and getters:

class Config
{
    public void setName(String name)
    {
        this.name = name;
    }

    public String getName()
    {
        return this.name;
    }

    public void setLanguage(String language)
    {
        this.language = language;
    }

    public String getLanguage()
    {
        return this.language;
    }

    // And so on, you got the point!
}

There are several terms that describe such objects:

  • DAO (Data Access Object)
  • DTO (Data Transfer Object)
  • VO (Value object)

Here lies my confusion:

It can be called Data Access Object, because it's responsible for data access. It can be called Data Transfer Object, because it might be responsible for transferring data between different objects. And finally, it can be called Value Object, because it has no behaviour and contains only values.

What are the origins of these different terms, which term should I choose in which context, and why?

closed as primarily opinion-based by Ampt, gnat, GlenH7, Dan Pichelman, Otávio Décio Nov 21 '14 at 17:50

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 4
    Ooo semantics. I always just call it "mutable struct" and move on. I also sometimes will call it POD (plain old data), but that has special meaning in C/C++, in which case people call it POCO (plain old C++ object). I'm partial to calling it POO. In the end, it doesn't really matter what you call it as long as you define it in your documentation and use it consistently. – IdeaHat Nov 21 '14 at 13:43
  • 1
  • 5
    It's a record. I don't even bother with getters/setters for these - their only value is moving data from one point to another, and if any processing needs to happen I'd rather make it explicit instead of hiding it in a setter or getter and pretending I have anything more than a dumb collection of data. – Doval Nov 21 '14 at 14:29
  • 3
    To whomever is suggesting to close this question as "primarily opinion based" - these different terms have a historical background / background from different schools of thought - there is nothing opinionated in their origin (only when thinking in terms of "which one is better", but that was not the question). – Doc Brown Nov 21 '14 at 15:05
  • @DocBrown only when thinking in terms of "which one is better", but that was not the question He concludes with "Please explain, which term you would choice [sic] and why." I don't see how this is anything more than a thinly-veiled poll. He understands the rationale behind those names, he just wants to know which one is more common or popular. – Doval Nov 21 '14 at 15:20
8

I certainly wouldn't call it a value object because that conflicts with the idea in domain-driven-design. Going from wikipedia:

In computer science, a value object is a small object that represents a simple entity whose equality is not based on identity: i.e. two value objects are equal when they have the same value, not necessarily being the same object.

For example, a Person might have a Name. The Person is not a value object because even if they change their name, they are still the same person. Their equality is based on identity. The Name itself on the other hand is a value object- change any letter in that name and it becomes a new, different name.

As for what to call these, another term I've commonly heard is Property Bag. This is maybe a bit more of a C#-centric name than Java-centric, but it still describes the same idea. The difference between this and DTO/DAO is that it's being used to describe what the class is rather than what it's for. Whether this is more or less appropriate depends on the situation.

  • 'Property bag' fits the best to this specific style of class design, IMHO. Most C# developers would understand what you meant. – Tom W Nov 21 '14 at 17:51
10

A DAO class usually has the CRUD operations like save, update, and delete. Whereas the DTO is just an object that holds data. So there is actually a difference between those two. The term then depends on what the object does.

A VO and DTO used to be synonyms: early Java EE literature used the term value object to describe a DTO, but it changed it in a later version. "A Value Object doesn't have any identity. It is entirely identified by its value and is immutable." ~ http://www.adam-bien.com/roller/abien/entry/value_object_vs_data_transfer

3

I would call them structs. An old school name for old school design.

  1. DAOs contain persistence-related functionality. That's not a DAO.

  2. That could be a poorly implemented value object. Value objects should generally be immutable and they should have proper constructors. (However, a configuration could very well be an example of a value-like object that could be reasonably designed as mutable. It could be thought of as a map with fixed keys.)

  3. A DTO could look like that, but an object is a DTO only when its sole purpose is to carry data over remote interfaces or such.

1

As others have answered, DAO and DTO reflect the role of the Object whether you want to use it in a persistence layer or to transfer informations in a call.

A value Object should be immutable.

Since your code is in Java (and the terminology is quite Java Oriented), the term that comes to my mind is JavaBean but your class should implement Serializable.

I think you should have a look at that answer on Stack Overflow

0

I've heard and used both Data Access Object and Data Transfer Object, though I usually just call them Data Models (Objects) because it implies a container and doesn't imply what you are actually going to be doing with it.

0

In the .NET world, your class qualifies as a plain old CLR object (POCO).

In the Java world, you have plain old Java objects (POJOs).

  • 1
    Not entirely sure I agree. OP's objects have no methods, just setters & getters. POCOs and POJOs might be very complex, just unencumbered with external dependencies (i.e., inheritance from a particular framework). What am I missing? – Dan Pichelman Nov 21 '14 at 18:54

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