Persistence « Database JDBC « Java Articles

The Data Access Object (DAO) pattern provides an abstraction layer between the business logic tier (business object) and the persistent storage tier (data source). Business objects access data sources via data access objects. This abstraction layer encapsulates the persistent storage type/vendor implementation. Ideally, changes made to the data source, such as switching database vendors or type, should not modify the business objects; only the data access objects themselves would need to change.

PathProxy is a design pattern for persisting complex relationships without cluttering up your database. In this article JavaWorld contributor Matthew Tyson introduces his PathProxy pattern and walks you through an example application implementation based on Spring, JSF, and JPA/Hibernate.

How does all this relate to data persistence with Waba? If you'll recall, Waba is also a cross-platform solution, and its creators did not want to provide a data mechanism which would make it a Palm-only solution. Like the kjava.Database class, persistence in Waba understands only byte arrays. This is quite primitive, but Waba gives you some help that the KVM doesn't.

Editor's note: It's usually better to solve problems with simplicity and finesse rather than muscle. That's the premise behind the recently released Better, Faster, Lighter Java. Its authors, Bruce Tate and Justin Gehtland, put this belief to the test in this two-part series on Spring, excerpted from Chapter 8 of their book. This week Bruce and Justin continue where they left off in part one, taking you through adding persistence to the Pet Store example, and looking at the area of presentation logic in the Spring framework.

Persistence using a prevalent system is transparent, as transactions are applied directly to the business objects with no need to use SQL either directly or through object-relational mappings.

Over the years, several persistence frameworks have evolved that help you manage your object-relational mapping and data persistence needs. Selecting a framework that suits your requirements is, however, not a trivial task, because several factors influence this decision. In this article, I intend to discuss some of the more widely used Java persistence frameworks against three fundamental criteria: Which, When, and What. In Which, I will introduce a framework; in When, I will discuss some of the scenarios when should you consider adopting it and some scenarios when should you look for an alternative; and finally, in What, I will discuss what benefits and what liabilities the framework has if you decide to adopt it. Let's begin with the following frameworks that are best known in the Java persistence landscape.

The Java Persistence API was designed as a simple way to load and save your data objects without using any SQL at all. Since it was also designed to be implementation independent, you can change your database or persistence provider as your needs change and not worry about anything breaking. Though Java Persistence was originally designed for server tasks, it performs beautifully in client applications, letting client-side developers spend less time on storage and more time on what they are good at: building killer GUIs.

Java Persistence is a powerful technology designed to store all of your data objects in a full relational database without having to write a single line of SQL. Though originally created for the server side, I will show you how useful it can be in client applications. In " An Introduction to Java Persistence for Client-Side Developers" I introduced the Java Persistence API, the libraries to support it, and showed you how to set up a trivial but complete application. In part two we will take a look at advanced features like automatic table creation, property control, and inter-object relationships. Then we will build a complete address book application using everything we have learned.

Java object serialization provides a great medium-weight solution for saving objects to files and sending them over a network. Even for large projects that do use commercial databases or communications middleware, it can still be used as a valuable file format for auxiliary files or miscellaneous communication. In addition, the Java Remote Method Invocation and JavaBeans APIs both use object serialization for storing and communicating with objects. So in any Java application involving persistence or distribution, object serialization can be a powerful programming tool.

With the preceding discussion in mind, lets look at what's been happening with the next version of J2EE. According to the text of JSR-244, the theme of J2EE 1.5 is "ease of development", with the goal of addressing the needs of a wide range of developers, "including less sophisticated developers". This is a laudable goal, and quite frankly, it's about time. By adding new features that enable better tool support, ease of application development, and ease of maintenance, the Java will hopefully become more widely adopted and remain a competitive platform for enterprise development.

Persistent Object Implementation Made Easy Java's support for object serialization makes implementing persistent objects extremely easy. By contrast, saving, and restoring every field of an object is complex and repetitive. You certainly could write your own serialization mechanism, but the simplicity Java provides in its serialization is hard to beat. Java serialization offers developers the following:

This article is the second in a series discussing how three different object-persistence technologies (EJB, Java Data Objects, and Hibernate) attempt to simplify the chore of connecting relational databases and the Java programming language.

Introducing Object Persistence Persisting Java objects to a relational database is a unique challenge that involves serializing hierarchically-structured Java objects to a tabular-structured database and vice versa. This challenge is currently being addressed by a number of different tools. Most of these tools allow developers to instruct persistence engines as to how to convert Java objects to database columns/records and back. Essential to this effort is the need to map Java objects to database columns and records in a manner optimized for speed and efficiency.

At the JDO 2.0 Specification kickoff meeting held in Washington DC in August, the JDO Expert group, which consists of commercial and open-source JDO vendors, JDO consultants and trainers, end customers, and vendors with alternative technologies, identified a number of topics as critical to continuing the success of Java Data Objects. This article explores some of these topics and discusses the value of each to Java developers and JDO customers.

The code above shows you the minimum required to define a persistent object. Let's now manipulate this object. I want to persist my customer, update some of its attributes, and delete it from the database. These CRUD operations are made through the javax.persistence.EntityManager interface of JPA. For those of you who are familiar with the DAO pattern, the EntityManager can be seen as a DAO class providing you with a set of life cycle methods (persist, remove) and finders (find) (see Listing 1).

At this point you have created an EJB 3.0 entity class that contains enough information for the persistence engine to store MusicOrder objects. Next you need to use the persistence framework API to cause persistent entities to be created, updated, and deleted.

Typically, those not familiar enough with SQL will choose CMP entity beans or frameworks such as TopLink and Hibernate, which generate queries and help to isolate them from the Java code. Regardless of which you choose, the resulting code will still contain Java-based queries. This article advises against this approach and proposes an alternative form of persistence that uses database stored procedures.

Barry Burd interviewed Bruce Tate at the No Fluff, Just Stuff Java Symposium. Bruce is the author of several books, including Bitter Java, Bitter EJB (with Mike Clark, Bob Lee, and Patrick Linskey) and the Jolt-winning Better, Faster, Lighter Java (with Justin Gehtland). In this interview, Bruce compares some of the major Java persistence frameworks.

Customers have a home address but Watermelon also needs to define a set of delivery addresses. Each of these addresses can be used on the weekend or/and in the evenings. I will implement this information by adding tags to an address. To do all this I will use one-to-many and many-to-many relationships with JPA. Figure 1 shows the business model to implement.

A: We introduced the Java Persistence API to the Java platform for two reasons. First, this new API simplifies the development of Java EE and Java SE applications using data persistence. Second, we wanted to get the entire Java community behind a single, standard persistence API.

Bruce Tate is a father, mountain biker, and kayaker in Austin, Texas. He's the author of three best-selling Java books, including the Jolt winner Better, Faster, Lighter Java. He recently released Spring: A Developer's Notebook. He spent 13 years at IBM and is now the founder of the J2Life, LLC, consultancy, where he specializes in lightweight development strategies and architectures based on Java technology and Ruby.

I've found that the Simple Persistence for Java library's straightforward API and zero-configuration approach greatly simplify object-relational persistence. If you need persistence (especially in small utility programs) but you want to avoid writing SQL, using a persistence framework, or installing a standalone database in your computer, then using Simple Persistence for Java v2.1.0 with the HSQLDB database is a viable option.

Experience in using ORM tools in many projects reveals better approaches to these same problems. Just as business domains differ, so do their domain models, persistent or not. This article covers best practices that apply to many domain models across industries. The best practices we present here can lead to a more consistent, reusable, and maintainable domain model. We use Hibernate to demonstrate these best practices, but you can apply many of the concepts to other ORM tools.

One new feature of Merlin has been thrown around in various incarnations at Sun's Swing Connection for some time now; in fact, it was first discussed at the 1999 JavaOne show. That feature is the ability to save the JavaBean component state for long-term persistence within an XML document. Serialization works fine for short-term marshaling needs, with CORBA and RMI, or for saving state information within an executing servlet. However, serialization can run into problems across versions of class libraries or Java run-time environments, among many other issues. The new XMLEncoder / XMLDecoder classes permit the dumping of the JavaBean component state to a text file for easy modification outside of a Java program or more likely for the generation of such files. Let's take a look at how to use the classes and examine the file generated.

Besides the Java language, a world of Java frameworks exists. These frameworks can afford substantial improvements in programmer productivity and enhance the quality, performance, reliability, and interoperability of different Java applications. Fortunately, many of these popular and widely used frameworks are open source projects, so anyone can benefit from them if he can invest some time learning when and how to use such frameworks. This article is the second installment in the frameworks series and aims to introduce persistence frameworks in general and the open source Java persistence framework, Castor JDO, in particular.

Using the EJB 1.1 specifications, container managed persistence beans were not very powerful. In most cases, bean developers went quickly beyond the capabilities of CMP and had to convert to use bean managed persistence. Many developers shied away from using entity beans altogether. The EJB 2.0 quickly addressed many of these issues. This now allows the bean developer to implement most persistence requirements using container managed persistence. The four features that facilitate this are the following:

Combining all of these techniques into a single methodology, and using these processes to enhance the well-accepted Model/View/Controller structure of a modern Web application is the goal of a number of projects. One example is the open-source Keel meta-framework. Keel calls the individual application logic classes "Models," as in MVC. Models are, as often as possible, written to be threadsafe, and may be combined into sequences or even sophisticated workflows entirely by configuration, maximizing reuse and simplifying maintainability considerably.

Why go through all this bother when you're designing a new application? The answer is simple: users expect applications to be intelligently persistent. Properly implementing persistence translates into an easier to use application with happier users. Ultimately that translates to either sales or job security (or both!) for the developer. Look at it this way: having an application without persistence is like going out to sleep every night at a hotel. The furniture is always in the same place when you get there, whether you like it or not. Wouldn't you rather sleep at home, where you've moved the couch and the bed to just the right spots, and they stay there when you're away? That's what persistence can do for your applications: make the user feel right at home.

Just as the JDBC API brought a standard way to access relational databases, the Java Data Objects API, JDO, brings a standard means for accessing all data stores, relational or otherwise. It has the great advantage of being a very simple API, with none of the complexity or required overhead of Entity EJBs—it can, however, co-exist with Entity beans or with many other persistence techniques, as we will see.

This article describes the implementation of a simple library for doing something that many programs have to do: save data. It's not going to solve all of our data-saving needs, because, regardless of what some database vendors might tell you, there is no one piece of software that can properly handle every data-saving situation.

For Java developers, there is a new way to implement data persistence. Java Data Objects (JDO) is a Java-based solution to help solve data persistence in java systems. JDO can be defined as:

Nevertheless, testing is a key part of the software development process, and just as flossing prevents dental decay, testing prevents software decay. The persistent layer, like most other application components, is not immune to decay and so requires testing. You need to write tests that verify that the domain model is mapped correctly to the database and that the queries used by the repositories work as expected. There are two main challenges when testing a persistent domain model. The first challenge is writing tests that detect the ORM-specific bugs. These bugs are often caused by inconsistencies between the domain model, the ORM document, and the database schema. For example, one common mistake is to forget to define the mapping for a newly added field, which can cause subtle bugs. Database constraints are another common problem that prevents the application from creating, updating, or deleting persistent objects. It's essential to have tests for the persistent domain model that catch these and other issues.