Differencebetween a Javabean and a Pojo

What is the difference between a JavaBean and a POJO?

A JavaBean follows certain conventions. Getter/setter naming, having a public default constructor, being serialisable etc. See JavaBeans Conventions for more details.

A POJO (plain-old-Java-object) isn't rigorously defined. It's a Java object that doesn't have a requirement to implement a particular interface or derive from a particular base class, or make use of particular annotations in order to be compatible with a given framework, and can be any arbitrary (often relatively simple) Java object.

Difference among Model, javabean and POJO

If you're using the MVC architecture then the Model represents your domain: means your entities and it's not a java related term.

Your Models are represented in Java as Java Beans (best practice in Java EE).

A Java Bean is a normal Java class which implements the Serializable interface and have a parameterless constructor and have getters and setters for each field.

However POJO is just a denomination for objects not bound by any restriction other than those forced by the Java Language Specification (Wikipeadia). This is just for conventions sake and it's not strictly related to the MVC architecture.

Note that Java beans are POJOs implementing the Serializable interface.

Programming difference between POJO and Bean

Only difference is bean can be serialized.

From Java docs - http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html

Serializability of a class is enabled by the class implementing the java.io.Serializable interface. Classes that do not implement this interface will not have any of their state serialized or deserialized. All subtypes of a serializable class are themselves serializable. The serialization interface has no methods or fields and serves only to identify the semantics of being serializable.

Difference between DTO, VO, POJO, JavaBeans?

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.

What is java pojo class, java bean, normal class?

Normal Class: A Java class
Java Beans:
- All properties private (use getters/setters)
- A public no-argument constructor
- Implements Serializable.
Pojo:
Plain Old Java Object is a Java object not bound by any restriction other than those forced by the Java Language Specification. I.e., a POJO should not have to
- Extend prespecified classes
- Implement prespecified interface
- Contain prespecified annotations

Is java bean and java pojo same?

All JavaBeans are POJOs but not all POJOs are JavaBeans.

A JavaBean is a Java object that satisfies certain programming conventions:

the JavaBean class must implement either Serializable or Externalizable

the JavaBean class must have a no-arg constructor

all JavaBean properties must public setter and getter methods (as appropriate)

all JavaBean instance variables should be private

Java-Use of knowing the differences between Entity, Vo, POJO, Javabeans, etc

You understood the difference between them, now you need to understand their purpose.

There is a neat definition for each one in this link.

Who cares if I create a POJO or a JavaBean? At the beginning I will create a POJO if I have no other constraint, until I realise I must make it a Javabean and deal with it's restrictions.

You need to think what the purpose of the class is. Is it a standalone class with no annotations that provides functionality but can be isolated (not counting libraries used)? Then it is likely a POJO.

Is it a class that serves as a bridge between layers of your project? Is it annotated? Does it implement some business logic for your project? Then it is a JavaBean.

When do you tell yourself: "I need a DTO"? Only for web services or when any client/server call is made? In that case, do you put all the data you need (and the one you think you will need?) in one DTO bunch?

DTOs are generally used to share information between layers. Their main purpose is isolating Entities so that you can change how your information is persisted from how the information flows through the different beans and controllers in your project.

To know when I need a DTO and when not I follow these rules:

Does the method more than three parameters? Then use a DTO.
Does the method return more than a single parameter? Then use a DTO.
When passing parameters to method calls / from method results: Does each element have more than one type (for Maps you would look at the value)? Then use a Collection of DTOs.
Otherwise use String, int, Long, etc.

Also never mind reusing DTOs even if most of its fields are not used for a specific method, you won't be wasting much memory if it's properly design. On the other hand, don't worry if you need to create new DTOs that share fields with some others, it might be clearer when reviewing your code. Try to find the right balance between too many DTOs and overpopulated DTOs.

Lastly, in a MVC model, where does each one go? Can I make an entity or a vo in either layer? Where does the DTO go?

It depends on how you structure your project. The term layer is a bit open as it can refer to each of the MVC elements and to the Data/Business/Client architecture (when I used the word layer in this answer, I'm talking about the later classification).

It is a good practice to separate each layer in a different project (specially in large projects). This is a common structure I use for enterprise web applications:

ProjectNameDao: Includes database access methods and entities.
ProjectNameBo: Includes all the business logic. Shares information with the other layers by using DTOs. It is, along ProjectNameDao, the Model in a MVC model.
ProjectNameWeb: Includes views and controllers from the MVC model.
ProjectNameDto: Includes all DTOs.
ProjectNameUtils: Shared utils, normally POJOs that hold constant values or provide basic functionality like Date formatting.

This structure needs to be adapted to whatever your requirements are, of course.

Confuse among JavaBeans, POJO, beans?

A POJO is a plain java object that doesn't adhere to any framework standard. Often Java Beans are considered POJOs as well, since the Java Beans Standard (or what is used of it) is kind of weak.

Java Beans are Java classes that adhere to certain naming conventions (mainly the getter setter thing) and are used in many contexts. JSPs is one of them. There is actually more to Java Bean then most people use. You can learn about it in this tutorial: http://docs.oracle.com/javase/tutorial/javabeans/index.html

Why is it called bean? I can only guess: Java -> Coffee -> Bean on one hand and on the other hand a bean is something simple, self contained which is kind of appropriate for a 'component'