Hibernate Tutorial | Persistent Classes and POJO http://www.hibernate-training-guide.com/java-bean...

Java Beans

Table of Contents JavaBeans

JavaBeans are just POJOs with some special characteristics. JavaBeans are commonly used in all types
of
Java applications. Originally they were created for a graphical environment but are now commonly
used in
Java EE applications. Server-side JavaBeans often implement business entities.

Via specification and conventions, there are more rules and guidelines around JavaBeans. Every
JavaBean
should provide a no argument constructor. Every JavaBean should implement java.io.Serializable.
JavaBeans
should extend no special base class. Typically, member variables start in lowercase, and have uppercase
letters on new words (“camel casing”): uniformNumber, userName, etc. Getters and setters start with
get and
set and are also camel cased: getUniformNumber(), setUniformNumber (int number), etc. Accessors
(getters)
accept no parameters and the method return type is that of the attribute they are associated with.
Mutators
(setters) accept one parameter (of the type of the attribute they are associated with) and return void.

Even these simple requirements are not set in stone and they do not affect Hibernate’s ability to persist
JavaBean instances. In fact, the “rules” that Hibernate enforces on your persistent classes are also
considered
best practices for POJO/JavaBean implementation.

Hibernate persistent classes must have a default constructor. This default constructor can be
non-public. The
constructor may need to be package-visible (public, protected or default accessibility). In some cases,
the
class cannot be final. The rationale for these last two points will be discussed later in class. The default
constructor allows Hibernate to instantiate instances using Constructor.newInstance() (from Java
Reflection).

Hibernate does not require the POJOs or JavaBeans to implement any special interface or extend any
special
sub-class. This is one of the features that distinguish Hibernate from some of the other persistent
frameworks.
In fact, Hibernate does not even require persistent classes to implement Serializable as the JavaBean
spec
requires.
Training Resources
Persistent classes do not need to import or use any Hibernate packages.
.NET Training
C# Training In fact, nothing in the persistent class (like BallPlayer above) would necessarily indicate Hibernate is
used to
VB.NET Training persist the instances of the class. Hibernate is transparent when programming at the persistent class
ASP.NET Training level.
This transparency helps improve code readability, maintainability, and portability (maybe even to be
WPF Training
used
WCF Training with other persistent frameworks).
WF Training
An instance of a persistent class can be stored in the database from anywhere in your application. No
LINQ Training
special
Silverlight Training container, as in EJBs, is needed. No special build time process is required, as in JDO. Therefore,
Java Training Hibernate
can be used just as well and easily in non-managed Java SE applications as it can in managed Java EE
JSP Training applications.
Hibernate Training
Struts Training
Spring Framework Training
JSF Training

1 sur 3 29/04/2010 15:21

Hibernate Tutorial | Persistent Classes and POJO http://www.hibernate-training-guide.com/java-bean...

VSTS
Courseware online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.
Consulting

2 sur 3 29/04/2010 15:21

Hibernate Tutorial | Persistent Classes and POJO http://www.hibernate-training-guide.com/java-bean...

3 sur 3 29/04/2010 15:21