In general terms, entity objects encapsulate the business policy and data for
the logical structure of the business, such as product lines, departments, sales, and regions
business documents, such as invoices, change orders, and service requests
physical items, such as warehouses, employees, and equipment
Another way of looking at it is that an entity object stores the business logic and column information for a database table (or view, synonym, or snapshot). An entity object caches data from a database and provides an object-oriented representation of it.
Depending on how you want to work, you can create entity objects from existing database tables (reverse generation) or define entity objects and use them to create database tables (forward generation).
When you use a Business Components for Java wizard to create entity objects from existing tables, each database table becomes an entity object. Each column in the database table becomes an entity object attribute, which can have the same name as the column or a different name that is more meaningful to your business application. The attributes of an entity object store data type information as specified in the database table they were derived from, including primary and foreign key relationships, the number of characters allowed, precision and scale specifications, and object REFs.
An entity object can have an attribute for each column or you can use a subset, for example, if you don't need to work with that column or if a table contains information for more than one entity.
You can use Business Components for Java wizards to define entity objects, and their attributes, without starting with an existing database table. When you use a wizard to generate database tables from the entity objects, each entity object becomes a table and each entity attribute becomes a table column.
Usually, you have one entity object per table. However, some tables store multiple types of information, so they may map to more than one entity. There are two ways this can happen:
Different entity objects apply to different rows. For example, an Items table might store inventory items, requisition items, order items, and so on, which are different "entity types." So you can omit columns that do not apply to the entity object you are defining. However, you must always include the primary key.
Two entity objects apply to the same row. Ideally, you should not have two entity objects that operate on the same row to prevent conflicts. But if you do, you need to make sure that they are not modifying the same row at the same time. Also, make sure that each updateable attribute appears in one entity object only; otherwise, you could make changes in a row that are not reflected in the other entity object.
You can create and edit entity objects by using the Entity Object Wizard and Editor. For reverse generation, you can also use the Business Components Project Wizard or Package Wizard or Editor to create default entity objects.
During runtime, each entity object instance represents a row in the database table and stores its data. There is only one instance per row, and all instances of the same entity object class are cached together. Multiple view object queries returning the same row refer to the same entity object instance, so updates are visible to all view objects; one entity object can be used by multiple view objects.
Entity objects are not exposed to clients. Instead, clients access an entity object’s data through one or more view objects. In the view row class, you can expose entity object methods to a client by writing a view object method that calls the method you want to expose.
Relationships between entity objects are expressed through associations. They match attributes, typically key fields, from source and destination entity objects. Methods that return rows and row sets through the association are available on the entity object class.
You implement the majority of your business logic in entity objects. For example, validation rules (such as "sal > 700") can ensure that the values returned by a query are valid or that users do not enter invalid data into a table. Business logic is defined and updated in one place, with the benefit that multiple clients can use it and be instantly updated when changes are needed.
The following figure shows an entity object named Emp based on the EMP table. The developer of this entity object has also added a validation rule to specify that an employee's salary must be greater than 700.
To decide what entity objects your application needs, you usually use UML object-oriented modeling techniques to model entities.
Related topics
The Files that Define an Entity Object