home movie radio music chord lyrics book game Dictionary clip
[ Team LiB ] Previous Section Next Section

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

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.

    [ Team LiB ] Previous Section Next Section