PATH Documentation > WebObjects 4.5 > EOF Developer's Guide

Table of Contents

Previous Section

From Database to Objects

Enterprise Objects Framework's database-to-objects mapping sets up a correspondence between database tables and enterprise objects classes so that database rows map to instances of the appropriate class as shown in Figure 2.

Figure 2. Mapping Between an Enterprise Object Class and a Single Table

The mapping is flexible. For example:

You can map an enterprise object to a single table, a subset of a table, or to more than one table. For instance, a Person object can get its first and last names from a PERSON table but get its street address, city, state and zip code from an ADDRESS table.
Generally an enterprise object instance variable maps to a single column, but the column-to-instance variable correspondence is similarly flexible. You can map an instance variable to a derived column, such as "price * discount" or "salary * 12".
You can map an enterprise object inheritance hierarchy to one or more database tables.

In addition to mapping tables to enterprise object classes and database columns to instance variables, the Framework maps database primary and foreign keys to relationships between objects. The Framework defines two types of relationships-to-ones and to-manys-which are both illustrated in Figure 3. The relationship a MovieRole has to its Movie is a to-one relationship, while the relationship a Movie has to its MovieRoles is a to-many.

Figure 3. Mapping Relationships

For more information on database-to-objects mappings, see the chapter "Designing Enterprise Objects", and to learn how to define this mapping with the EOModeler application, see the book Enterprise Objects Framework Tools and Techniques.

Uniquing

In marrying relational databases to object-oriented programming, one of the key requirements is that a row in the database be associated with only one enterprise object in a given context in your application. Enterprise Objects Framework maintains the mapping of each enterprise object to its corresponding database row, and uses this information to ensure that your object graph does not have two (possibly inconsistent) objects for the same database row. Uniquing of enterprise objects, as this process is called, limits memory usage and allows you to know with confidence that the object you're interacting with represents the true state of its associated row as it was last fetched into the object graph.

Without uniquing, you'd get a new enterprise object every time you fetch its corresponding row, whether explicitly or through resolution of relationships. This is illustrated in Figure 4.

Figure 4. Uniquing of Enterprise Objects

Resolution of Relationships and Faulting

When the Framework fetches an object, it creates objects representing the destinations of the fetched object's relationships. For example, if you fetch an employee object, you can ask for its manager and immediately receive an object; you don't have to get the manager's employee ID from the object you just fetched and fetch the manager yourself.

The Framework doesn't immediately fetch data for the destination objects of relationships, however. Fetching is fairly expensive, and further, if the Framework fetched objects related to the one explicitly asked for, it would also have to fetch the objects related to those, and so on, until all of the interrelated rows in the database had been retrieved. To avoid this waste of time and resources, the destination objects created are stand-ins, called faults, that fetch their data the first time they're accessed. Figure 5 illustrates this process.

The framework allows you to tune relationship resolution by prefetching relationships and batch faulting. For more information on these features, see the chapter "Answers to Common Design Questions". For more information on the general faulting mechanism, see the chapter "Behind the Scenes".

Figure 5. Resolution of a Fault

Table of Contents Next Section