Documentation Archive Developer
Search
PATH  WebObjects 4.0 Documentation > EOF Developer's Guide

Table of Contents Previous Section

From Objects to Database

After your program has accumulated changes to enterprise objects, it needs to push those changes back to the database. Enterprise Objects Framework manages this process, too, analyzing the objects for changes, generating corresponding database operations, and executing those operations to synchronize the database with in-memory enterprise objects. The Framework has mechanisms for ensuring that the integrity of your data is maintained between your application and the database:

Each of these is described in the following sections.

Validation

A good part of your application's business logic is usually validation-for example, verifying that customers don't exceed their credit limits, that return dates don't come before their corresponding check out dates, and so on. In your enterprise object classes, you implement methods that check for invalid data, and the framework automatically invokes them before saving anything to the database.

Referential Integrity Enforcement

Enterprise Objects Framework allows you to specify rules governing the relationships between objects. You can specify whether a to-one relationship is optional or mandatory. For example, you can require that all departments have a location (mandatory), but not require that every employee have a manager (optional).

You can also specify delete rules for relationships. For example, when you delete a department object, you can specify that:

For more information on Framework's referential integrity enforcement, see the chapter "Designing Enterprise Objects". To learn how to define these rules in the EOModeler application, see the book Enterprise Objects Framework Tools and Techniques.

Automatic Primary and Foreign Key Generation

With Enterprise Objects Framework, you don't have to maintain database artifacts such as database primary and foreign key values into your application. Database primary and foreign keys aren't usually meaningful parts of a business model; rather, they're attributes created in a relational database to express relationships between entities. For example, the primary key (MOVIE_ID) for a movie doesn't have any meaning to users. Users identify movies by their titles.

Enterprise Objects Framework keeps track of primary and foreign key data for you. You don't have to represent that information in your enterprise objects, and you don't have to worry about generating and propagating key values.

For information on eliminating database artifacts from your object model, see the chapter "Designing Enterprise Objects". For information on how the Framework generates primary key values, see the chapter "Answers to Common Design Questions".

Transaction Management

For the most part, Enterprise Objects Framework handles transactions for you. You don't have to worry about beginning, committing, or rolling back transactions unless you want to fine-tune transaction management behavior. The Framework uses the native transaction management features of your database to group database operations that correspond to the changes that have been made to enterprise objects in memory. For more information, see the chapter "Behind the Scenes".

Additionally, the Framework provides a separate in-memory transaction management feature. You can create nested contexts in which a child context's changes are folded into the parent context only upon successful completion of an in-memory operation. For more information on nested contexts, see the chapter "Application Configurations".

Locking

The Framework offers three types of locking:

For more information on Enterprise Objects Framework's locking strategies, see the chapter "Behind the Scenes".

Table of Contents Next Section