Entity Objects:An entity object implements the business rules for a given table, view, or snapshot. Entity objects are intended to be used in many clients (not just an OA Framework UI), and as such, should consolidate all of the relevant validation/behavior for the table.
1. Each table should have at most one entity object.
2. Entity objects should include attributes for all columns in its table.
3. You can subclass your own common entity objects .
4. You will commonly add object initialization, attribute validation, entity-level
validation, and other functional behaviors to your entity objects.
5. Finally, you can create server "helper" objects and interfaces as needed to create modular code.
Entity Associations (Association Objects):
Associations let you create declarative relationships between entity objects. At runtime, BC4J uses these relationships to coordinate the related objects. There are two basic types of associations:
1. Composition - A strong association where the source entity object owns the destination entity object.
In other words, the destination cannot exist independent of its source.
2. Reference - A weak association where the source entity object only references the destination entity object.
Create reference associations for any entity objects that you're likely to update or instantiate at runtime.
View Objects and View Rows:
view objects encapsulate database queries and provide access to associated entity objects. One of the most important view object design decisions is whether it should be based on plain SQL, or on entity objects.
1. All trivial UI view objects for things like Lists of Values (LOV) and poplists are based on plain SQL.
2. Any validation view objects, created to implement simple business rules for an entity object, are based on plain SQL.
3. All other view objects created for the UI, regardless of whether they are updateable, are based on entity objects.
View Links :As described above, an association defines a relationship between two entity objects. Similarly, a view link defines a relationship between two view objects that BC4J uses to automatically query and coordinate the destination view object based on the current source view object.
View links can be based on an association or a declarative join relationship between two view objects. For example, suppose two tables have a master-detail relationship based on a foreign key. The corresponding entity objects are related via an association, and view objects based on those entity objects can be related by a view link based on the association.
Although view links can be very convenient, use them sparingly in the web applications pages because they cache both the master and detail records as the user navigates from one master row to the next -- and this can be expensive. Use view links only in the following cases:
1. When specific beans (like the HGrid) require them.
2. When you have updateable master/detail view objects (on the same or different pages) whose underlying entity objects are related using composition, you must define a view link between them .
3. When you have a read-only master and detail view object on the same page, and navigating to a master row should cause the children to query automatically.
Application Modules(AM):Application Module UsesThe following is a list the distinct roles that application modules can play in your application:
1. UI Root Application Module -
Establishes the transaction context for one or several related UI pages. Every page has a root application module which
includes any view objects and nested application modules used by the page.
2. UI Shared Region Application Module - Any UI region with created for use in multiple pages should have its own containing
application module. When this region is used in a page, OA Framework automatically nests its application module beneath
the page's root application module.
No comments:
Post a Comment