8.1 Why Alternative Frameworks?
The Java philosophy is heavy on the idea
that you adhere to the standards and compete on implementation. As a
general rule of thumb in the Java world, you should avoid deviating
from standards unless the standards in question simply do not meet
your needs. Java's persistence models, however, are
far from well-accepted standards. Part of the reason behind this
divergence is that no single persistence model can support the needs
of every application. Each approach to persistence requires design
decisions that necessarily exclude features provided by other
systems.
Each alternative framework brings its own advantages to database
programming. As a general rule, alternative frameworks offer you:
The ability to meet specific needs not addressed in the EJB or JDO
standards. As with EJB and JDO, Hibernate and Castor rely on XML descriptor
files for persistence mapping. This lends itself to providing a very
easy to understand mapping file that describes complex database
relationships. The alternatives in this chapter limit the amount of code developers
need to write in order to make objects persistent. The alternatives in this chapter are open source. As such, they come
with all of the benefits—and the drawbacks—of open source
tools.
|
BEST PRACTICE: Use alternative persistence frameworks in applications designed for low-cost deployment environments or for applications that have niche requirements for which an alternative framework is uniquely suited.
|
|
Alternative persistence APIs are not without their own drawbacks:
Alternative persistence APIs are simply that: an alternative. These
APIs do not conform to recognized standards such as EJB 1.1, EJB 2.0,
and JDO. Alternative persistence APIs do not provide a container-managed
transaction system such as those provided by the EJB container. With
EJBs, the transaction demarcation is done automatically by defining
the transaction attributes in your deployment descriptor and is
strictly enforced by the container.
The open source model is a model for
distributing software based on the philosophy that the people who use
software should have the right to the source code for the software,
including the ability to modify the source code. Though it is often
associated with the concept of free—meaning without
cost—software, open source software describes itself as free,
as in speech. In other words, open source software may or may not
cost any money.
The benefits of open source software include:
Greater control over your software, including the ability to improve
the software instead of waiting for a vendor to fix it for you. Given a large contributor base, open source software tends to have a
more diverse developer base than proprietary software. Open source software—even when it is not free—is
generally cheaper than proprietary software since the business models
for open source companies tend to be based on services around their
software.
On the other hand, open source software has its drawbacks:
Support for the software often depends on the whims of its developers
rather than a solid service agreement. Releases of open source software without large developer bases are
inconsistent and even prone to long periods of inactivity. The benefits of the greater control over your software can become
liabilities if you lose the ability to maintain your changes.
|
|
BEST PRACTICE: Do not use alternative frameworks for applications meant to be deployed in a variety of corporate environments. In such environments, adherence to standards is critical to the confidence of those who will be responsible for supporting the application.
|
|
|