To understand the key components of the Enterprise Objects stack is to first understand the most important objects in the core stack. They are illustrated in “Figure 5-1.” A brief description of those objects follows.
An object store is an “intelligent” repository of objects. It is responsible for constructing enterprise objects, registering enterprise objects, servicing enterprise object faults, and saving changes made to objects. You can think of an object store as a workspace for enterprise objects. EOObjectStore is an abstract class that has a number of specific subclasses in the core Enterprise Objects stack.
A concrete subclass of EOObjectStore, an object store coordinator mediates between multiple object stores both in the control layer and in the access layer. It mediates between any number of editing contexts in the control layer and their associated database contexts (or other object store subclasses) in the access layer.
When multiple cooperating object stores needs to communicate with one another, the object store coordinator mediates this communication. It provides an abstraction to multiple data sources and multiple workspaces that contain data from those sources, allowing objects made up of data from different data sources to work together.
Another subclass of EOObjectStore, the cooperating object store defines the mechanics for object stores that work together to manage data from several distinct data repositories.
When multiple cooperating object stores need to communicate with one another, the object store coordinator mediates this communication. If a cooperating object store determines that certain changes need to be handled by another object store, it asks the object store coordinator to handle the changes (usually by handing them off to another cooperating object store that can handle them). This is an abstract class whose most commonly used concrete subclass is EODatabaseContext.
Another concrete subclass of EOObjectStore, an editing context is the core object with which you most often interact. Enterprise object instances live within editing contexts, and editing contexts provide the infrastructure that allows enterprise objects to communicate with one another. An editing context is the highest-level object in the core framework stack and it communicates with a database through its lower-level objects.
Another concrete subclass of EOObjectStore, a database context is responsible for analyzing the changes made to enterprise objects in editing contexts and determining exactly the changes that need to be made in the database based on the changes in editing contexts. It hands off this list of changes that need to be made in the database (this list is referred to as adaptor operations) to an adaptor channel by way of a database channel. You rarely need to explicitly interact with a database context.
A database channel is used by a database context to communicate with an adaptor channel.
An adaptor channel is responsible for actually communicating with a data source and sending it commands. However, the operations an adaptor channel performs are always made within the context of a transaction that is managed by an adaptor context object.
Last updated: 2007-07-11