Plain Old Java Objects (POJO)

In software engineering, a plain old Java object (POJO) is an ordinary Java object, not bound by any
special restriction and not requiring any class path. The term was coined by Martin Fowler, Rebecca Parsons
and Josh MacKenzie in September 2000. The term "POJO" initially denoted a Java object which does not
follow any of the major Java object models, conventions, or frameworks; nowadays "POJO" may be used as
an acronym for "Plain Old JavaScript Object" as well, in which case the term denotes a
similar JavaScript object . It’s the Java equivalent of a C “struct”

The implied meaning is- a java class that does not extend any class. All entity beans extend the
javax.ejb.EntityBean interface, so they are not POJOs. A pojo that might represent a telephone contact
might look like:

Notice how the class doesn’t implement or extend anything. It is therefore a "plain old" java object.
Typically in enterprise java development, you would write POJOs as helper classes that support your
business logic.

A JavaBean is a POJO that is serializable, has a no-argument constructor, and allows access to properties
using getter and setter methods (mutator methods: methods used to control changes to a variable) that
follow a simple naming convention.

POJO is used to describe the same things as a "Normal Class" whereas a JavaBean follows a set of rules. 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 have public setter and getter methods (as appropriate);
 all JavaBean instance variables should be private.
POJO is an object which encapsulates Business Logic.

The Benefits of POJOs

1) Decoupling the application code from the infrastructure frameworks is one of the many benefits of using
POJOs.

2) They simplify development because rather than being forced to think about everything - business logic,
persistence, transactions, etc. - at once, you can focus instead on one thing at a time.

3) You can design and implement the business logic and then, once that's working, you can deal with
persistence and transactions.

4) POJOs also accelerate development. You can test your business logic outside of the application server
and without a database. You don't have to package your code and deploy it in the application server.

5) You also don't have to keep the database schema constantly in sync with the object model or spend
time waiting for slow-running database tests to finish. Tests run in a few seconds and development can
happen at the speed of thought.
Design decisions : POJO in business tier

There are two quite different ways to design an enterprise Java application.
One option is to use the classic EJB 2 approach, which refers to as the heavyweight approach.
The other option is to use POJOs and lightweight frameworks, which is_the
POJO approach. When using the POJO approach, your business logic consists entirely of POJOs.

The application consists of the Webbased presentation tier, the business

tier, and the persistence tier. The Webbased presentation tier handles
HTTP requests and generates HTML for regular browser clients and XML,
and other content for rich Internet clients, such as Ajaxbased clients
(asynchronous JavaScript and XML). The business tier, which is invoked by
the presentation tier, implements the application's business logic. The
persistence tier is used by the business tier to access external data sources
such as databases and other applications