Difference between DTO, VO, POJO, JavaBeans?

Question

Have seen some similar questions:

• What is the difference between a JavaBean and a POJO?
• What is the Difference Between POJO (Plain Old Java Object) and DTO (Data Transfer Object)?

Can you also please tell me the contexts in which they are used? Or the purpose of them?

Solution 1

JavaBeans

A JavaBean is a class that follows the JavaBeans conventions as defined by Sun. Wikipedia has a pretty good summary of what JavaBeans are:

JavaBeans are reusable software components for Java that can be manipulated visually in a builder tool. Practically, they are classes written in the Java programming language conforming to a particular convention. They are used to encapsulate many objects into a single object (the bean), so that they can be passed around as a single bean object instead of as multiple individual objects. A JavaBean is a Java Object that is serializable, has a nullary constructor, and allows access to properties using getter and setter methods.

In order to function as a JavaBean class, an object class must obey certain conventions about method naming, construction, and behavior. These conventions make it possible to have tools that can use, reuse, replace, and connect JavaBeans.

The required conventions are:

• The class must have a public default constructor. This allows easy instantiation within editing and activation frameworks.
• The class properties must be accessible using get, set, and other methods (so-called accessor methods and mutator methods), following a standard naming convention. This allows easy automated inspection and updating of bean state within frameworks, many of which include custom editors for various types of properties.
• The class should be serializable. This allows applications and frameworks to reliably save, store, and restore the bean's state in a fashion that is independent of the VM and platform.

Because these requirements are largely expressed as conventions rather than by implementing interfaces, some developers view JavaBeans as Plain Old Java Objects that follow specific naming conventions.

POJO

A Plain Old Java Object or POJO is a term initially introduced to designate a simple lightweight Java object, not implementing any javax.ejb interface, as opposed to heavyweight EJB 2.x (especially Entity Beans, Stateless Session Beans are not that bad IMO). Today, the term is used for any simple object with no extra stuff. Again, Wikipedia does a good job at defining POJO:

POJO is an acronym for Plain Old Java Object. The name is used to emphasize that the object in question is an ordinary Java Object, not a special object, and in particular not an Enterprise JavaBean (especially before EJB 3). The term was coined by Martin Fowler, Rebecca Parsons and Josh MacKenzie in September 2000:

"We wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it's caught on very nicely."

The term continues the pattern of older terms for technologies that do not use fancy new features, such as POTS (Plain Old Telephone Service) in telephony, and PODS (Plain Old Data Structures) that are defined in C++ but use only C language features, and POD (Plain Old Documentation) in Perl.

The term has most likely gained widespread acceptance because of the need for a common and easily understood term that contrasts with complicated object frameworks. A JavaBean is a POJO that is serializable, has a no-argument constructor, and allows access to properties using getter and setter methods. An Enterprise JavaBean is not a single class but an entire component model (again, EJB 3 reduces the complexity of Enterprise JavaBeans).

As designs using POJOs have become more commonly-used, systems have arisen that give POJOs some of the functionality used in frameworks and more choice about which areas of functionality are actually needed. Hibernate and Spring are examples.

Value Object

A Value Object or VO is an object such as java.lang.Integer that hold values (hence value objects). For a more formal definition, I often refer to Martin Fowler's description of Value Object:

In Patterns of Enterprise Application Architecture I described Value Object as a small object such as a Money or date range object. Their key property is that they follow value semantics rather than reference semantics.

You can usually tell them because their notion of equality isn't based on identity, instead two value objects are equal if all their fields are equal. Although all fields are equal, you don't need to compare all fields if a subset is unique - for example currency codes for currency objects are enough to test equality.

A general heuristic is that value objects should be entirely immutable. If you want to change a value object you should replace the object with a new one and not be allowed to update the values of the value object itself - updatable value objects lead to aliasing problems.

Early J2EE literature used the term value object to describe a different notion, what I call a Data Transfer Object. They have since changed their usage and use the term Transfer Object instead.

You can find some more good material on value objects on the wiki and by Dirk Riehle.

Data Transfer Object

Data Transfer Object or DTO is a (anti) pattern introduced with EJB. Instead of performing many remote calls on EJBs, the idea was to encapsulate data in a value object that could be transfered over the network: a Data Transfer Object. Wikipedia has a decent definition of Data Transfer Object:

Data transfer object (DTO), formerly known as value objects or VO, is a design pattern used to transfer data between software application subsystems. DTOs are often used in conjunction with data access objects to retrieve data from a database.

The difference between data transfer objects and business objects or data access objects is that a DTO does not have any behaviour except for storage and retrieval of its own data (accessors and mutators).

In a traditional EJB architecture, DTOs serve dual purposes: first, they work around the problem that entity beans are not serializable; second, they implicitly define an assembly phase where all data to be used by the view is fetched and marshalled into the DTOs before returning control to the presentation tier.

---

So, for many people, DTOs and VOs are the same thing (but Fowler uses VOs to mean something else as we saw). Most of time, they follow the JavaBeans conventions and are thus JavaBeans too. And all are POJOs.

Solution 2

DTO vs VO

DTO - Data transfer objects are just data containers which are used to transport data between layers and tiers.

• It mainly contains attributes. You can even use public attributes without getters and setters.
• Data transfer objects do not contain any business logic.

Analogy:
Simple Registration form with attributes username, password and email id.

• When this form is submitted in RegistrationServlet file you will get all the attributes from view layer to business layer where you pass the attributes to java beans and then to the DAO or the persistence layer.
• DTO's helps in transporting the attributes from view layer to business layer and finally to the persistence layer.

DTO was mainly used to get data transported across the network efficiently, it may be even from JVM to another JVM.

DTOs are often java.io.Serializable - in order to transfer data across JVM.

VO - A Value Object [1][2] represents itself a fixed set of data and is similar to a Java enum. A Value Object's identity is based on their state rather than on their object identity and is immutable. A real world example would be Color.RED, Color.BLUE, SEX.FEMALE etc.

POJO vs JavaBeans

[1] The Java-Beanness of a POJO is that its private attributes are all accessed via public getters and setters that conform to the JavaBeans conventions. e.g.

    private String foo;
    public String getFoo(){...}
    public void setFoo(String foo){...}; 

[2] JavaBeans must implement Serializable and have a no-argument constructor, whereas in POJO does not have these restrictions.

Solution 3

Basically,

DTO: "Data transfer objects " can travel between seperate layers in software architecture.

VO: "Value objects " hold a object such as Integer,Money etc.

POJO: Plain Old Java Object which is not a special object.

Java Beans: requires a Java Class to be serializable, have a no-arg constructor and a getter and setter for each field

Solution 4

Java Beans are not the same thing as EJBs.

The JavaBeans specification in Java 1.0 was Sun's attempt to allow Java objects to be manipulated in an IDE that looked like VB. There were rules laid down for objects that qualified as "Java Beans":

1. Default constructor
2. Getters and setters for private data members that followed the proper naming convention
3. Serializable
4. Maybe others that I'm forgetting.

EJBs came later. They combine distributed components and a transactional model, running in a container that manages threads, pooling, life cycle, and provides services. They are a far cry from Java Beans.

DTOs came about in the Java context because people found out that the EJB 1.0 spec was too "chatty" with the database. Rather than make a roundtrip for every data element, people would package them into Java Beans in bulk and ship them around.

POJOs were a reaction against EJBs.

Solution 5

POJO : It is a java file(class) which doesn't extend or implement any other java file(class).

Bean: It is a java file(class) in which all variables are private, methods are public and appropriate getters and setters are used for accessing variables.

Normal class: It is a java file(class) which may consist of public/private/default/protected variables and which may or may not extend or implement another java file(class).

View more solutions

Comments

[sinuhepop]

I was wrong and I preferred to delete my message. Thanks for correction. I want to notice that the POJO meaning has changed some time ago. First, they're only made of private properties and their accessors. Now, we consider a POJO a class with annotations, implementing and extending other classes, etc.

[Jaime Hablutzel]

So if I have a convenience class created just for transfering unrelated data like this one class SomeClass { public String foo;public String bar; } inside a class with a lot of complicated logic, for sure it is not a JavaBean, it can't be a VO as it is mutable, could it be a DTO? altought it is not targeted for remote invocations of any sort. May it be considered a POJO?

[jscherman]

Sorry for comment sooooo late, but i am learning about the differences between them and i have a question. What if i have a Java Bean class, but with another methods like doSomething(). What kind of class would it be? Regards

[jscherman]

Sorry for comment sooooo late, but i am learning about the differences between them and i have a question. What if i have a Java Bean class, but with another methods like doSomething(). What kind of class would it be? Regards

[cHao]

@user2601512: It'd still be a Bean. :P There's nothing wrong with a Bean having behavior -- in fact, it's pretty much expected to. If it does nothing else, it's basically a DTO.

[uvsmtid]

What is described as Value Object above is, in fact, called Value Type. Wikipedia also correlates on these meanings. Value Object is rather a concept in DDD which means an object without identity (two objects with equal field values are the same thing). It is irrespective to implementation. They may be two instances of some class, but DDD treats them as the same thing anyway conceptually because their field values are the same. They are opposite to Entities which have identity and are still considered different by DDD even if they have the same field values.

[cHao]

@xSNRG: Partly because it demotes objects to data that other code acts upon. That's a step backwards from an OO perspective, where objects act and should be responsible for their own state. DTOs are occasionally a decent solution if you actually are just transferring data -- hence the name -- but encapsulation basically goes out the window, and you typically lose any validity/consistency guarantees that a real object could provide.

[Kumaresan Perumal]

@pascal why can not we pass the data in DOMAIN or MODEL java object? But i use MODEL without DTO. please explain me briefly. thanks

[Kumaresan Perumal]

@srinivas why can not we pass the data in DOMAIN or MODEL java object? But i use MODEL without DTO. please explain me briefly. thanks

[cHao]

@KumaresanPerumal: You can, if you want. But the model is distinct from the data layer, and has different aims and rules. The data layer typically needs everything laid out and arbitrarily settable, and the model ideally wants to hide data and enforce invariants. You want to use model objects for storage, you're going to have to compromise on one side or the other.

[Kumaresan Perumal]

@chao Please tell me aims and rules and explain me in an easy way. it will help me.

[cHao]

@KumaresanPerumal: The data layer is there to store and retrieve data. To do that, it all but needs full access to whatever object holds the data, since retrieval means setting values in an object somewhere. But the model manages that data within the system, and is bound by OO principles, like encapsulation -- the idea that objects should maintain control over their internal state and not have other code messing around with their innards arbitrarily. DTOs can bridge that gap; the data layer can access them at will, and the model doesn't have to abdicate control.

[Kumaresan Perumal]

do we write down any business logic on model class?

[cHao]

@KumaresanPerumal: That's actually where most of your business logic should live, according to the MVC gurus. A "fat model" design puts most of the business logic in the model, and lots of people swear by it, especially for web apps.

[DarthVader]

I find this answer invalid. DTOs are not an anti pattern. There is no clear definition of POJO and Beans here.

[Fareed Alnamrouti]

as can you notice all the "convention" mentioned above is for runtime reflection purposes which have the worst performance ever! what a horrible language

[portfoliobuilder]

Are responses also considered DTOs? They are similar classes of requests. So you could have two classes, one for requests named GetProfileRequestDto and another for response named GetProfileResponseDto. Is that good naming convention?

[cellepo]

What about VO, as the Question asked? This is not an Answer until it answers the full Question

[cellepo]

What about VO, as the Question asked? This is not an Answer until it answers the full Question

[cellepo]

What about VO, as the Question asked? This is not an Answer until it answers the full Question

[cellepo]

Can VO Value Objects contain nested Objects, where "values" of the VO are not necessarily all at the [un-nested] top-level of the VO (but can be nested arbitrarily deep below that top-level)?