Apple WebObjects 5 - Manual (Page 29)

C H A P T E R 3
Enterprise Objects
Mapping Your Enterprise Objects to Database Tables 29

Apple Computer, Inc. January 2002
Because of the controller's central mediating role, model objects need not know
about the state and events of the user interface, and view objects need not know
about the programmatic interfaces of model objects.
From the perspective of this paradigm, enterprise objects are model objects.
However, WebObjects also extends the MVC paradigm. Enterprise objects are also
independent of their persistent storage mechanism. Enterprise objects do not need
to know about the database that holds their data, and the database doesn’t need to
know about the enterprise objects.
Mapping Your Enterprise Objects to Database Tables
Enterprise objects make use of a separate file, known as a model, to specify a
mapping between tables in the database and your enterprise-object classes. This is
formally called an entity-relationship (E-R) model. You use EOModeler to create
and maintain these models. With EOModeler you can
■ read the data dictionary from a database to create a default model, which can
then be tailored to suit the needs of your application
■ define data entities that represent the tables in your database
■ define the attributes of each entity; these attributes usually correspond to
columns on a table
■ specify relationships between entities and referential integrity rules for these
relationships
■ generate source code files (enterprise-object classes) for the entities you specify
■ define fetch specifications (queries) that you can invoke by name in your
applications
■ create, modify, or delete tables or databases
A model represents a level of abstraction above the database. The
database-to-objects mapping embodied in a model sets up a correspondence
between database tables and the model’s entities; frequently, table rows map to
instances of the appropriate data entity, as shown in
Figure 3-2 (page 30).