---

What Is an Enterprise Object?

An enterprise object is an instance of a class that implements the com.webobjects.eocontrol.EOEnterpriseObject interface. You can think of an enterprise object as a business object. It contains your business rules and represents the data on which your business relies.

An enterprise object is like any other object in that it couples data with the methods for operating on that data. However, an enterprise object has certain characteristics that distinguish it from other classes:

• It has properties that map to stored data; an enterprise object instance typically corresponds to a single row or record in a database.

• It knows how to interact with other parts of the Enterprise Object technology to give and receive values for its properties.

An enterprise object is an instance of a class (such as com.webobjects.eocontrol.EOGenericRecord) that has attributes that correspond to the data values from the database row or record from which the object is instantiated. An enterprise object has a corresponding model that defines the mapping between the class’s object model and the database schema. However, an enterprise object doesn’t explicitly know about its model.

This model (an EOModel) allows Enterprise Objects to map database tables to enterprise objects (Java objects) so that a database row maps to an instance of a particular enterprise object class. For instance, a database table named “LISTING” maps to an enterprise object class, which is usually an instance of or subclass of com.webobjects.eocontrol.EOGenericRecord, which implements the com.webobjects.eocontrol.EOEnterpriseObject interface.

You control what kind of enterprise object class a given database table maps to. “Figure 2-2” illustrates the mapping between a database table and an enterprise object.

You have a good deal of control over how this mapping happens. For example:

• You can map an enterprise object class to a single database table, a subset of a table, or to more than one table (via relationships, flattening, and other mechanisms). For example, a Listing enterprise object can get its price, square footage, and number of bedrooms from a LISTING table, its street address, city, state, and zip code information from an ADDRESS table, and its property tax information from a LISTING_TAX table.

• Generally, an enterprise object property (a datum in an enterprise object) maps to a single column in a table. For example, an employee’s salary can be defined strictly by the row value of the SALARY column in an EMPLOYEE table. But an employee’s salary can also be mapped to a derived attribute such as “SALARY + BONUS” or “SALARY * 12”.

• You can map an enterprise object inheritance hierarchy to one or more database tables. Inheritance is a powerful feature that lets you think of your database schema in terms of an object hierarchy. It is discussed in detail in EOModeler User Guide.

One of the most powerful features of Enterprise Objects is that it maps database joins to relationships between objects. Again, you have a great deal of flexibility with regard to how this mapping occurs. You can map to-one, to-many, and many-to-many relationships, and you can control the business rules that govern those relationships, such as delete rule, optionality, and ownership.

“Figure 2-3” illustrates the mapping between a database table and an enterprise object. A single row in the LISTING table is related to one or more rows in the LISTING_PHOTO table: there is a to-many relationship between the LISTING table and the LISTING_PHOTO table.

When an enterprise object is instantiated from the LISTING table, placeholder objects (called faults) for related rows in the LISTING_PHOTO table are also instantiated. When a Listing’s photos relationship is accessed, those faults are turned into fully formed enterprise objects, which allows the Listing enterprise object to access data in the ListingPhoto enterprise objects. All the SQL you would normally need to write to resolve the joins is handled for you automatically.

Faulting is explained in more detail in “Faulting.”

---