Terminology

This section provides a key to some of the overloaded terms in the Enterprise Objects frameworks:

• the Enterprise Object technology is also referred to as “Enterprise Objects” (note capitalization) or as the “Enterprise Objects frameworks”

• classes or instances of classes that implement the EOEnterpriseObject interface are referred to as “enterprise objects” (note capitalization)

The terms “Enterprise Objects,” “the Enterprise Objects frameworks,” and “the Enterprise Object technology” refer to all of the classes in WebObjects that begin with the prefix “EO.” This document speaks specifically to the core Enterprise Objects frameworks: classes in the package com.webobjects.eocontrol (referred to as the control layer) and classes in the package com.webobjects.eoaccess (referred to as the access layer).

How to Learn About Enterprise Objects

The Enterprise Objects frameworks provide a great deal of flexibility through an extensive API—most of which you’ll never need to use or know about. You can go far in building an Enterprise Objects application if you’re familiar with a handful of classes and a few dozen methods. The best way to learn about these particular classes and methods is by performing small, focused tasks to gradually get acquainted with the commonly used ones. By learning the technology through these tasks, you build up a set of mental tools that you can later use to build real, data-driven applications. This document provides a number of these tasks to help you get started.

While learning the technology, don’t be tempted to use classes and methods that you either don’t need or don’t understand. You’ll probably ever use only 10% of the public API throughout the technology, so don’t be too adventurous in the beginning. An axiom of Enterprise Objects development is that “he who writes the least code wins.” That is, if in dealing with a particular problem, you end up writing a lot of complicated, custom code, you’ve probably overlooked functionality that the frameworks provide.

When learning this technology, keep in mind that the learning curve is high but the productivity that results allows you to rapidly build sophisticated, elegant business solutions in a fraction of the time that other database application development systems require. To help tackle the high learning curve, don’t try to understand the whole system at once. Fortunately, the layered design of Enterprise Objects facilitates this approach. By working with one layer at a time, the whole system gradually comes into focus.

Part of the difficultly in learning Enterprise Objects is its abstract architecture. It is designed to allow you to work with data sources at an abstract level; it allows you to work with objects that are abstractions of data sources. The objects within the frameworks provide abstract representations of databases, of database transactions, and of the data retrieved from databases.

Although the abstractions within Enterprise Objects contribute to its high learning curve, once you understand the architecture, you’ll see that its abstract design provides huge benefits in terms of portability to different data sources and to various client-server application configurations. So if all the abstraction at first seems confusing, be patient—you’ll eventually come to appreciate it.

Road Map to Concepts

If you’ve read Using EOModeler or have a little experience building Enterprise Objects applications, you should read these chapters first:

• Enterprise Objects Overview

• Business Objects

• Business Logic

If you are an intermediate developer who wants to know more about the mechanics of Enterprise Objects, read these chapters:

• Fetching Data

• Working With the Object Graph

• Saving Data

If you are an advanced developer, you may be interested in these chapters, which discuss advanced topics:

• Core Framework Stack

• Update Strategies

• Connecting to a Database

• Concurrency

Road Map to Tasks

If you’ve read Using EOModeler or have a little experience building Enterprise Objects applications, you are probably interested in the tasks described in these sections:

• Synchronizing Model Changes to Class Files

• Instantiating Enterprise Objects

• Providing Initial Values

• Adding Validation

• Writing Business Methods

• Manipulating Relationships

• Building a Reusable Framework

• Constructing Fetch Specifications

• Filtering Fetch Results in Memory

• Sorting Fetch Results in Memory

• Accessing WebObjects in Enterprise Objects

Intermediate and advanced developers are probably interested in the tasks in these sections:

• Providing Separate Stacks

• Accessing Lower-Level Objects

• Generating Custom Primary Keys

• Using Compound Primary Keys

• Recovering and Refaulting

• Recovering and Last Write Wins

• Providing a Connection Dictionary in Code

• Providing Multiple Database Channels

• Closing Database Channels

• Accessing Database Keys