What are adf business components?
Create a WebLogic Domain for your ADF Business Components that supports WebLogic Server, Oracle Application Core (Webapp), and Oracle JRF.
To create a WebLogic domain that supports the required components:
ADF entity objects are business components that encapsulate data, persistence behavior, and business rules for items that are used in your application. For example, entity objects can represent: Elements of the logical structure of the business, such as product lines, departments, sales, and regions.
ADF Business Components addresses these tasks through its library of reusable software components and through the supporting design time facilities in JDeveloper. Most importantly, developers save time using ADF Business Components since the JDeveloper design time makes typical development tasks entirely declarative. In particular, JDeveloper supports declarative development with ADF Business Components to:
ADF Business Components provides a foundation of Java classes that allow your business-tier application components to leverage the functionality provided in the following areas:
Simplifying Data Access
Enforcing Business Domain Validation and Business Logic
Supporting Sophisticated UIs with Multipage Units of Work
Implementing High-Performance Service-Oriented Architecture
Streamlining Application Customization
ADF Business Components implements the business service through the following set of cooperating components:
Entity object
An entity object represents a row in a database table and simplifies modifying its data by handling all data manipulation language (DML) operations for you. These are basically your 1 to 1 representation of a database table. Each table in the database will have 1 and only 1 EO. The EO contains the mapping between columns and attributes. EO’s also contain the business logic and validation. These are you core data services. They are responsible for updating, inserting and deleting records.
The Attributes tab displays the actual mapping between attributes and columns, the mapping has following fields:
View object
A view object represents a SQL query. You use the full power of the familiar SQL language to join, filter, sort, and aggregate data into exactly the shape required by the end-user task.
The attributes in the View Objects are actually coming from the Entity Object. In the end the VO will generate a query but you basically build a VO by selecting which EO need to participate in the VO and which attributes of those EO you want to use.
That’s why you have the Entity Usage column so you can see the relation between VO and EO.
In the query tab you can clearly see the query that will be generated for the VO. At this stage we don’t need it and just use it for information purpose. In later stages we might use it.
Application module
An application module is the controller of your data layer. It is responsible for keeping hold of the transaction. It exposes the data model to the view layer. You expose the VO’s through the Application Module. This is the abstraction of your data layer which you want to show to the outside word.It defines an updatable data model and top-level procedures and functions (called service methods) related to a logical unit of work related to an end-user task.
While the base components handle all the common cases through built-in behavior, customization is always possible and the default behavior provided by the base components can be easily overridden or augmented.
When you create EO’s, a foreign key will be translated into an association in our model. It defines the type of relation and who is the master and child as well as how the visibility of the association looks like.
A similar concept exists to identify relations between view objects. These are called view links. These are almost identical as association except that a view link is based upon attributes defined in the view object. It can also be based upon an association.
Here’s a short summary:
