JavaFX

Digg This!

Page 1 of 4   next page »

Java is a great language for developing enterprise applications. It's powerful, scalable, robust, secure, and typically very complex. As a software developer, I want to solve business problems, not spend man-months building the plumbing for my applications. This article will demonstrate how you can speed up the development and simplify the maintenance of enterprise-class Swing applications by keeping things simple. We'll look at ways to reduce the complexity of your application and the amount of custom code written for it. By limiting the complexity and the amount of plumbing code required, you'll develop more quickly, the application will be easier to maintain, and you can focus on the business logic that provides value to the customer.

In particular, I'll show you how to address three of the primary issues facing developers today:

1. Persistence and object relational impedance mismatch
2. Why too many technologies make development and maintenance difficult
3. What to do when there's more application "plumbing" code than custom business logic

What Is Object Relational Impedance Mismatch and Why It's a Problem
Relational databases are the dominant database technology in the market today and they are well matched for use with procedural programming languages. However, with the move to object-based development languages (C++, Java, Delphi, etc.) it quickly became apparent that objects don't always map easily to relational tables and vice versa. This problem has become known as the object relational or impedance mismatch.

According to the Progress Software Web site, "An R.B. Webber study concluded that coding and configuring object relational (O-R) data access typically accounts for 30% to 40% of total project effort."

There are development and performance repercussions due to this mismatch. Developers must spend time writing code that breaks objects into pieces that can be saved to and re-assembled from relational tables and determining the best way to map objects to relational tables becomes more difficult as the objects grow in complexity. There is also a certain amount of overhead due to this assembly and breakdown of objects that impacts performance. Finally, queries can take longer since the application has to perform multi-table joins when retrieving complex objects from the database rather than just opening the object.

Historically programmers have dealt with this by writing a data access layer that manages the reading/object assembly from the database and object disassembly/writing to the database. Recently there's been an explosion in the number of XML-based mapping tools that attempt to replace the native language data access code with frameworks that define the mapping using XML. The problem with this approach is that while it provides a mechanism for persisting and retrieving objects, letting the developer to deal with objects exclusively, it requires quite a bit of additional work (defining and maintaining the XML mappings), incurs a performance hit when the objects are read from and saved to the database, and often requires the user to query the database with non-standard object query languages that aren't as mature and powerful as SQL.

Eliminating the Object-Relational Impedance Mismatch
One way to eliminate the object-relational impedance mismatch altogether is to use an object database for your application's persistence layer. Object databases are now mature, robust, and fast. More importantly, they provide an easy mechanism for persisting and retrieving objects without the overhead of a mapping framework. This means faster development, better performance, and less code to maintain.

You can browse a list of object-oriented databases at Service-Architecture.com. As with any technology, every vendor's implementation provides slightly different features and functionalities. It's important to review each one to find the one that best fits your project's needs. Next, I'll demonstrate how using an object database instead of a relational one can dramatically simplify and speed up the development of your entire application.

Example # 1: Defining and Accessing Objects Using An Object-Oriented Database
For these examples, I'll use InterSystems Corporation's Caché Database. The databases from db4objects, Matisse, and Progress also provide Java interfaces and transparent object persistence. However, features and implementations are specific to each vendor's database.

With InterSystems Caché you create your database by defining the objects that it will contain. The objects contain properties that are analogous to standard SQL data types and are mapped to Java datatype equivalents. The objects support aggregation and inheritance and can be projected as Java classes that include methods for retrieving, modifying, and persisting the object.

Note that Caché also lets you access your data/objects via an SQL projection, meaning you can access your data in either a relational or object-oriented fashion, whichever is most appropriate for the task at hand.

• Aggregation: When an object is composed of other objects. For example, a car object is comprised of an engine object, a transmission object, four wheel objects, etc.
• Inheritance: An object inherits the attributes and methods of another class (the base or parent class).

Savings # 1: Eliminate the Code and Performance Overhead of Mapping
By using an object-oriented database, you eliminate the need to create and maintain a mapping layer or data access layer. Not only does this speed up development, but you have less code to maintain and one less technology to learn. Look at Figure 1 to see what this means for the typical struts-based Web application.

The object database replaces four pieces of the application software stack. In addition, you will improve performance by eliminating the overhead of any XML mapping layer.

Just so you have an idea of some of the effort being eliminated, here's an example of a JDO XML map for a very simple object with only two fields. When using a mapping framework, you would normally create one of these for each object class in your database. By using an object database, you eliminate this step.

<?xml version="1.0"?>
<!DOCTYPE mapping PUBLIC "-//EXOLAB/Castor Object Mapping DTD Version 1.0//EN"
"http://castor.org/mapping.dtd">
<mapping>
   <class name="myapp.ProductGroup" identity="id">
     <description>Product group</description>
       <map-to table="prod_group" xml="group" />
       <field name="id" type="integer" >
     <sql name="id" type="integer"/>
   </field>
     <field name="name" type="string">
       <sql name="name" type="char" />
     </field>
   </class>
</mapping>

Example: Object Definition That Demonstrates Aggregation and Inheritance
Now I'll demonstrate how easy it is to create persistent Java objects using Caché by creating a very simple employee database.

Caché comes with a GUI tool called Studio that's used to simplify the definition of classes. You define classes in much the same way you would define relational tables - except when you're done, you can access the objects directly without writing data access code or using an object-relational mapping layer. Much of the class definition text can be generated by wizards in the application - but it can also be manually coded if desired. We'll define four classes including:

1. An address class that can be reused as a property template in persistent classes
2. A person class that represents a simple person object
3. An employee class that extends the person class by adding additional properties
4. Persistent Class: Persistent objects can be stored in the database.
5. Serial Class: Serial objects can be embedded in persistent objects to create complex, reusable data definitions - such as addresses.

The Address Class
Here's the definition for the address class. Note that it extends a %Serial-Object so it can't be persisted by itself and must be included in a persistent class. Serial classes are great for simplifying the definitions of complex objects. We'll use this one to simplify the design of the Person and Employee classes.

Page 1 of 4   next page »