We Keep Coding

What's the point of having DTO object when you have the same object as POJO (Entity)?

I would like to understand what's the benefits to create DTO objects when you already have POJO object (as Entity).
In my project I have both :
DTO classes are used to communicate between Web Service and the application
POJO entity classes (JPA) are used for communication between database and the application
If I look at a DTO object class (let's call it MyObjDTO) and the same class but POJO side (let's call it MyObjPOJO) there is no difference at all except MyObjPOJO as annotation due to the fact it's an #Entity.
So in fact, I got in my project 2 classes who look the same (same attributes, same methods) but for different puprose.
IMO, in this case the DTO class is useless and increase application complexity because all I do with DTO class I can do it with my POJO class and moreover, for a single type of object I have to maintain at least 2 classes (the DTO and POJO), for instance if I add an attribute I have to add this attribute in both classes.
I'm not an expert and I'm questionning about my thoughts; what do you think about it ?

This answer is a replica of what can be found on stack exchange. IMHO the OP should be closed for being posted in the wrong forum. It's currently also attracting opinionated answers, though not necessarily so, and isn't tied to java in any particular way.
DTO is a pattern and it is implementation (POJO/POCO) independent. DTO says, since each call to any remote interface is expensive, response to each call should bring as much data as possible. So, if multiple requests are required to bring data for a particular task, data to be brought can be combined in a DTO so that only one request can bring all the required data. Catalog of Patterns of Enterprise Application Architecture has more details.
DTO's are a fundamental concept, not outdated.
What is somewhat outdated is the notion of having DTOs that contain no logic at all, are used only for transmitting data and "mapped" from domain objects before transmission to the client, and there mapped to view models before passing them to the display layer. In simple applications, the domain objects can often be directly reused as DTOs and passed through directly to the display layer, so that there is only one unified data model. For more complex applications you don't want to expose the entire domain model to the client, so a mapping from domain models to DTOs is necessary. Having a separate view model that duplicates the data from the DTOs almost never makes sense.
However, the reason why this notion is outdated rather than just plain wrong is that some (mainly older) frameworks/technologies require it, as their domain and view models are not POJOS and instead tied directly to the framework.
Most notably, Entity Beans in J2EE prior to the EJB 3 standard were not POJOs and instead were proxy objects constructed by the app server - it was simply not possible to send them to the client, so you had no choice about haing a separate DTO layer - it was mandatory.
Although DTO is not an outdated pattern, it is often applied needlessly, which might make it appear outdated.
From Java guru Adam Bien:
The most misused pattern in the Java Enterprise community is the DTO. DTO was clearly defined as a solution for a distribution problem. DTO was meant to be a coarse-grained data container which efficiently transports data between processes (tiers). ~ Adam Bien
From Martin Fowler:
DTOs are called Data Transfer Objects because their whole purpose is to shift data in expensive remote calls. They are part of implementing a coarse grained interface which a remote interface needs for performance. Not just do you not need them in a local context, they are actually harmful both because a coarse-grained API is more difficult to use and because you have to do all the work moving data from your domain or data source layer into the DTOs. ~ Martin Fowler
Here is a Java EE specific example of a common but incorrect use of the DTO pattern. If you're unfamiliar with Java EE, you just need to know the MVC pattern: a "JSF ManagedBean" is a class used by the View, and a "JPA Entity" is the Model in the MVC pattern.
So, for example, say you have a JSF ManagedBean. A common question is whether the bean should hold a reference to a JPA Entity directly, or should it maintain a reference to some intermediary object which is later converted to an Entity. I have heard this intermediary object referred to as a DTO, but if your ManagedBeans and Entities are operating within the same JVM, then there is little benefit to using the DTO pattern.
Futhermore, consider Bean Validation annotations (again, if you're unfamiliar with Java EE, know that Bean Validation is an API for validating data). Your JPA Entities are likely annotated with #NotNull and #Size validations. If you're using a DTO, you'll want to repeat these validations in your DTO so that clients using your remote interface don't need to send a message to find out they've failed basic validation. Imagine all that extra work of copying Bean Validation annotations between your DTO and Entity, but if your View and Entities are operating within the same JVM, there is no need to take on this extra work: just use the Entities.
The Catalog of Patterns of Enterprise Application Architecture provides a concise explanation of DTOs, and here are more references I found illuminating:
HOW TO DEAL WITH J2EE AND DESIGN PATTERNS
How to use DTO in JSF + Spring + Hibernate
Pros and Cons of Data Transfer Objects Martin Fowler's description of DTO
Martin Fowler explains the
problem with DTOs. Apparently they were being misused as early
as 2004

Most of this comes down to Clean Architecture and a focus on separation of concerns
My biggest use-case for the entities is so i don't litter the DTO's with runtime variables or methods that i've added in for convenience (such as display names / values or post-calculated values)
If its a very simple entity then there isn't so much of a big deal about it, but if you're being extremely strict with Clean then there becomes a lot of redundant models (DTO, DBO, Entity)
Its really a preference in how much you want to dedicate to strict Clean architecture
https://medium.com/android-dev-hacks/detailed-guide-on-android-clean-architecture-9eab262a9011

There is an advantage, even if very small, to having a separation of layers in your architecture, and having objects "morph" as they travel through the layers. this decoupling allows you to replace any layer in your software with minimal change, just update the mapping of fields between 2 objects and your all set.
If the 2 objects have the same members...well, then that's what Apache Commons BeanUtils.copyProperties() is for ;)

Other people have already informed you of the benefits of DTO, here I will talk about how to solve the trouble of maintaining one more DTO version object.
I deveploy a library beanKnife to automatically generate a dto. It will create a new class base the original pojo. You can filter the inherited properties, modify existing properties or add new properties. All you need is just writing a configuration class, and the library will do the left things for you. The configuration support inheritance feature, so you can extract the common part to simpify the configuration even more.
Here is the example
#Entity
class Pojo1 {
private int a;
#OneToMany(mappedBy="b")
private List<Pojo2> b;
}
#Entity
class Pojo2 {
private String a;
#ManyToOne()
private Pojo1 b;
}
// Include all properties. By default, nothing is included.
// To change this behaviour, here use a base configuration and all other final configuration will inherit it.
#PropertiesIncludePattern(".*")
// By default, the generated class name is the original class name append with "View",
// This annotation change the behaviour. Now class Pojo1 will generate the class Pojo1Dto
#ViewGenNameMapper("${name}Dto")
class BaseConfiguration {
}
// generate Pojo1Dto, which has a pojo2 info list b instead of pojo2 list
#ViewOf(value = Pojo1.class)
class Pojo1DtoConfiguration extends BaseConfiguration {
private List<Pojo2Info> b;
}
// generate Pojo1Info, which exclude b
#ViewOf(value = Pojo1.class, genName="Pojo1Info", excludes = "b")
class Pojo1InfoConfiguration extends BaseConfiguration {}
// generate Pojo2Dto, which has a pojo1 info b instead of pojo1
#ViewOf(value = Pojo2.class)
class Pojo2DtoConfiguration extends BaseConfiguration {
private Pojo1Info b;
}
// generate Pojo2Info, which exclude b
#ViewOf(value = Pojo2.class, genName="Pojo2Info", excludes = "b")
class Pojo2InfoConfiguration extends BaseConfiguration {}
will generate
class Pojo1Dto {
private int a;
private List<Pojo2Info> b;
}
class Pojo1Info {
private int a;
}
class Pojo2Dto {
private String a;
private Pojo1Info b;
}
class Pojo2Info {
private String a;
}
Then use it like this
Pojo1 pojo1 = ...
Pojo1Dto pojo1Dto = Pojo1Dto.read(pojo1);
Pojo2 pojo2 = ...
Pojo2Dto pojo2Dto = Pojo2Dto.read(pojo2);

Is the JSF Bean different from the standard Bean? [duplicate]

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?

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.

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.

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

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":
Default constructor
Getters and setters for private data members that followed the proper naming convention
Serializable
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.

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

Value Object : Use when need to measure the objects' equality based on the objects' value.
Data Transfer Object : Pass data with multiple attributes in one shot from client to server across layer, to avoid multiple calls to remote server.
Plain Old Java Object : It's like simple class which properties, public no-arg constructor. As we declare for JPA entity.
difference-between-value-object-pattern-and-data-transfer-pattern

First Talk About
Normal Class - that's mean any class define that's a normally in java it's means you create different type of method properties etc.
Bean - Bean is nothing it's only a object of that particular class using this bean you can access your java class same as object..
and after that talk about last one POJO
POJO - POJO is that class which have no any services it's have only a default constructor and private property and those property for setting a value corresponding setter and getter methods.
It's short form of Plain Java Object.

Are Jackson mapped objects DAOs?

I'm using Jackson to map JSON to a Java object.
Is the created Java object a DAO since its an object representation of the JSON structure and so is providing access to the JSON data?

It is not a DAO design pattern.
DAO pattern stands for providing the access to the Data Layer.
I will rather say it Value Object.

No, i would say its a data transfer object.
DAOs are used to persist data.

Since you are mapping from one instance to another instance, I think you are using more of a Converter or Adapter (take a look at the adapter pattern here).
To my knowledge, the purpose of the DAO (Data Access Object) is to provide a layer, or an object, which provides some sort of access to your data storage.

It is a Memento, for "Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later" I wouldn't argue with calling it Value Object but it's definitly not a DAO which the defining characteristic is the abstraction of a persistent data story.

Difference between DTO(data transfer object ) and class object in java?

We can use a class object for transfering data to another class. what is the speciality of data transfer objects? How to create them ? Is it just like class objects?

The primary difference is that DTOs, by design, don't have any business logic in them. They're just data structures.
For instance: You might have a database in which you store "users", and if using DTOs, you might use a UserBean to store and retrieve user objects. But your business logic may have a User object (possibly derived from the bean, more likely using the bean via aggregation) that not only has the data, but additional methods for things that User can do.

I believe this should be true:
assertTrue(POJO == DTO)
The only special thing about DTO is that they should not contain any behavior.

1, The class object maybe contains too many references to other objects, thus too big to be serialized to transfer. DTO only selects the interesting parts, this can be a performance gain.
2, In Hibernate, the entity object may contain lazy-initialized references, these objects need session context to do initialization. These entity objects looks like "smart objects", DTO here convert these "smart objects" to "plain objects", because transfer "smart objects" is meaningless when the session context is no more existed.
Personally, I don't like DTO, it introduce another layer of redundant, but sometime (especially when working with Hibernate ORM) I can't live without it.

A DTO class is an ordinary Java class with a just special meaning - just like a Observer, a Factory or a Model. The name is coming from a core J2EE design pattern (the Transfer Object pattern) and the pattern proposes a common way to transfer information between a database and java-classes-based model.
In brief, a DTO is a java class where the class name maps to a database table name and each database column maps to a class attribute. Then it contains getter and setter methods.
Here is one explanation of the (Data) Transfer Object pattern.

What is the difference between POJO (Plain Old Java Object) and DTO (Data Transfer Object)?

I cannot find difference between them. Does anyone know how to differentiate them?

POJO or "Plain Old Java Object" is a name used to describe "ordinary" Java objects, as opposed to EJBs (originally) or anything considered "heavy" with dependencies on other technologies.
DTO or "Data Transfer Object" is an object for... well... transferring data, usually between your "business" classes and persistence layer. It typically is a behavior-less class much like a C-style struct. They are an outdated concept.

A POJO is just a simple Java object, the acronym is used to emphasize that it really is nothing special.
A DTO is a Data Transfer Object which is used to encapsulate data that is transferred over a connection between layers or subsystems. See the wikipedia article, it's also a Core J2EE pattern (http://www.oracle.com/technetwork/java/transferobject-139757.html).
http://en.wikipedia.org/wiki/Data_transfer_object

All DTOs are POJOs, but not all POJOs are DTOs. An example of POJO that is not a DTO is a business class that contains state and behavior (business logic).

DTO (Data transfer object) : Is a Core J2EE design pattern used for transferring data within the system.DTO Pattern
POJO (Plain Old Java Object) : It is just an acronym people use for suggesting that is a simple java object (which nowadays is heavily annotated for doing some meaning full work).
DTO Pattern
J2EE Pattern Catalog

DTO is pojo, but pojo is not dto, because pojo can have more behavior but DTO just basically no behavior
Oracle document has clear description.

A POJO can have behavior. The book POJOs in Action details use of POJOS for application development.
DTOs are data containers that help transfer data from one layer to another. DTOs aren't supposed to contain any behavior.

I could understand the difference between POJO and DTO from this sentence of DTO's wiki:
DTOs are simple objects that should not contain any business logic but may contain serialization and deserialization mechanisms for transferring data over the wire.
Also, DTO is perfectly visualized and described in detail in Martin Fowler's Catalog of Patterns of Enterprise Application Architecture

POJO = Plain Old Java Object
DTO = Data Transfer Object
-- Edit
Well, this is assuming you don't know what the acronyms mean. A Pojo is just an object that is free from any sort of inheritance chain. A DTO exists in your data model, so probably follows a strict chain relating it to a given entity.