blind folio oracle series tight / oracle jdeveloper ...€¦ · 12/08/2004 · chapter 8:...

ORACLE Series TIGHT / Oracle JDeveloper 10g Handbook / Faderman, Koletzke, Dorsey / 225583-8 / Chapter 8Blind Folio 8:223

CHAPTER8

Introducing ADFBusiness Components

P:\010Comp\Oracle8\583-8\ch08.vpThursday, August 12, 2004 10:45:39 AM

Color profile: Generic CMYK printer profileComposite Default screen

“If everybody minded their own business,”the Duchess said, in a hoarse growl,“the world would go rounda great deal faster than it does.”

—Lewis Carroll [Charles Lutwidge Dodgson] (1832–1898),Alice’s Adventures in Wonderland

Oracle Application Development Framework Business Components (ADF BC,formerly called “BC4J”) is JDeveloper’s J2EE-compliant technology for creatingbusiness services. Business services provide business logic, including validationand default logic, queries, transaction handling, and data access, for an MVCapplication. (MVC applications were explained in Chapter 4.) Business services,

including ADF BC, do not provide a user interface or control flow. They provide object/relationalmappings and encapsulate business logic. The view and controller layers of an ADF applicationcommunicate with business services through the model layer and provide the user interface andcontrol flow.

Chapters 1 through 4 provided an overview of the capabilities of JDeveloper and ADF. Part IIdiscusses ADF BC (one of ADF’s central technologies) in depth as well as how to expose it usingthe ADF model layer. Using ADF BC is the simplest way to design data-aware applications withJDeveloper and ADF. However, Part II will not teach you everything you need to write acomplete ADF application. In addition to a business services layer (provided by ADF BC) and theADF model layer, ADF applications require a view and controller, which you will learn to createin Part III.

This chapter provides an overview of ADF BC, describing its components and uses. Chapter 9explains how to create business components to represent database objects, object types, andconstraints. Chapter 10 explains how to use ADF BC to enforce complex business rules such asvalidation and defaulting logic.

Chapter 11 explains how ADF BC represents queries and relationships between query resultsand how it caches data. That chapter will show how to assemble the data your client needs whilemaintaining optimal performance. Chapter 12 explains how the ADF model layer exposes ADFBC to the view and controller. Chapter 13 explains how to write custom business services—methods that encapsulate complex business tasks. Chapter 14 provides an overview of someother business services technologies: EJB technology, Java classes with TopLink mappings, andweb services.

NOTEMany practices in Part II are sequential, but you can downloadstarting and ending files for any chapter’s practice from the authors’websites mentioned in the front of the book.

This chapter includes a brief discussion of the advantages of using ADF BC and a quick tour ofthe different business components: entity object definitions, associations, view object definitions,view link definitions, application module definitions, and domains. At the end of the chapter, ahands-on practice demonstrates how to create and explore a simple business componentsapplication.

224 Oracle JDeveloper 10g Handbook




Chapter 8: Introducing ADF Business Components 225


Why Use ADF BC?In previous releases of JDeveloper, two of the primary advantages of ADF BC (then called “BC4J”)were that, unlike other business services technologies such as EJB, it automated mapping of Javaobjects to database objects (saving the developer the arduous task of coding JDBC) and providedeasy hooks for binding user interface components. JDeveloper 10g mitigates both of theseadvantages somewhat. By making EJB technology easier to use, and by incorporating TopLink,JDeveloper now provides two other respectable ways of providing object/relational mappingwithout coding JDBC. And with the ADF model layer, JDeveloper now provides hooks, similarto those provided by ADF BC, for binding user interface components to EJB entity beans, Javaclasses with TopLink mappings, and web services (for more information about these businessservices technologies, see Chapter 14).

There are, however, still reasons why ADF BC is the simplest way to develop data-awareapplications.

Automatic Implementation of J2EE BluePrints The components that make up ADF BC alreadyimplement many of Sun’s J2EE BluePrints design patterns. These patterns make J2EE applicationsmuch more efficient, by reducing round-trips, reducing the amount of data that needs to be sentin each round-trip, and utilizing the cache more efficiently. Developers who do not use ADF BCand who want to create high-performance, scalable applications need to implement these designpatterns, or something much like them, themselves. If you use ADF BC, you do not need to worryabout these design patterns (Sun discusses them extensively on their website, java.sun.com); youwill automatically be designing to them.

Hooks for Business Logic ADF BC provides convenient hooks for implementing business rules.Business rules can be implemented at multiple levels of an application—in the database, the view,or the business services layer. There are times when each of these locations is appropriate.

Adding business logic to the database, in the form of triggers or stored procedures, providesthe maximum level of robustness. This business logic is guaranteed to be available and respectedby any application, even by SQL commands run directly from a SQL*Plus prompt. However,business logic coded in the database is not highly responsive. It does not fire until data is postedto the database, which requires either waiting for an explicit post command or posting data afterevery change, which will degrade performance by requiring excessive JDBC round-trips. Inaddition, adding business logic to the database requires the database to perform tasks in additionto handling data, which reduces its efficiency and your application’s modularity. Finally, addingbusiness logic to the database requires you to integrate your Java or Web application withbusiness logic written in PL/SQL code.

Adding business logic to the view layer, in Java for Java client applications or JavaScript forweb applications, provides the maximum level of responsiveness. For example, business logicthat triggers as each character is typed into a field, or as a mouse pointer passes over a graphicalimage, must be implemented at the view level. However, business logic added to the view layeris not robust. If users access the data through any other user interface, business logic added to theview layer will not be available or enforced.

Adding business logic to business services is a compromise between these alternatives. It ismore responsive than business logic coded in the database, because it is enforced as soon aschanges are made to Java objects in memory, and avoids the other disadvantages of addingbusiness logic to the database. It is more robust than business logic coded in the view layer,because it will be enforced by any application that uses the business services.





Your most critical business logic should be implemented in the database, or redundantly inthe database and business services (for increased responsiveness and easier Java integration at thecost of some productivity). Business logic that requires truly immediate responsiveness must beimplemented in the view layer. The remainder of your business logic can be implemented at thebusiness services layer. For this sort of business logic, the hooks provided by ADF BC are a distinctadvantage over other business services technologies.

Deployment-Configuration Independence ADF BC is “deployment-configuration independent.”A single set of ADF BC components can be deployed as local Java classes or as an EJB session bean,with no rewriting of code necessary. Applications using TopLink or standard EJB technology arelocked into a single deployment configuration.

ADF Business Components, XML, and JavaAs explained in Chapters 1 and 4, ADF is a Java framework, a set of Java class libraries that useXML metadata to provide most customization but are also extensible in Java. Using ADF technologiesoften does not involve writing much procedural code; instead, you can use wizards and visualtools to declaratively develop XML files that represent your components. The classes in thelibraries contain code that handles the XML files to produce application behavior. However, ifyou want your XML files handled in a way other than the default, you can extend many of theseclasses to provide further customization.

ADF BC technology follows this general model. Each ADF BC component is primarilyimplemented as an XML file, which you can edit using wizards and visual tools. Classes in theADF BC library read the information stored in these files and use it to provide application behavior.However, many business components can also have their own custom classes, which extend theclasses in the ADF BC library to further customize application behavior. These custom classes arefurther described in Chapters 10 and 13.

ADF Business Component GroupsADF BC components divide into two groups, business domain components and data modelcomponents, as shown next:





This section discusses the ADF business component groups and the components in them.

Business Domain ComponentsBusiness domain components are components that represent features of the database: tables andviews, constraints, and relationships. Business domain components are the most reusablebusiness components. They are designed based on the logical features of the data, rather thanany specific application needs, so they can be used by any application that needs to access thesame data. There are three kinds of business domain components: entity object definitions,associations, and domains.

Entity Object DefinitionsAn entity object definition typically represents a database table or database view. It handles all ofthe business rules for that table or view including validation, defaulting, and anything else thathappens when a row is created, deleted, or changed.

One of the chief functions of any business service technology—including ADF BC—is toprovide object/relational (O/R) mappings between Java objects that an application can use andentities in the database. A relational database consists of, among other objects, a set of tables,each of which contains columns. For example, consider the table DEPARTMENTS, with thefollowing columns:

Column Name SQL Datatype

DEPARTMENT_ID NUMBER

DEPARTMENT_NAME VARCHAR2

MANAGER_ID NUMBER

LOCATION_ID NUMBER

The ADF BC layer represents the database table as an entity object definition. An entityobject definition has entity attributes, which typically represent the table columns, although themapping is not always exactly one-to-one. (For more information about the mapping betweentable columns and entity attributes, see Chapter 9.)

The types of the attributes are Java classes that correspond to the SQL types of the columns.“Departments”, the entity object definition for this table, might have the following entityattributes:

Attribute Name Java Type

DepartmentId oracle.jbo.domain.Number

DepartmentName java.lang.String

ManagerId oracle.jbo.domain.Number

LocationId oracle.jbo.domain.Number

Java does not directly support SQL datatypes. However, each SQL datatype can be mapped to aJava type. Some of these Java types are classes in java.lang (such as java.lang.String), andothers are in the package oracle.jbo.domain (which is discussed later, in the section “Domains”).



As shown in Figure 8-1, an entity object definition is the template for entity object instances,which are single Java objects representing individual rows in a database table. For example, theentity object definition Departments provides a template for entity object instances that representindividual rows of the DEPARTMENTS table, such as the one with the following attribute values:

Attribute Name Value

DepartmentId A Number holding the value 10

DepartmentName The String “Administration”

ManagerId A Number holding the value 200

LocationId A Number holding the value 1700



FIGURE 8-1. ADF BC relationships





An entity object definition consists of an XML file, which provides metadata, and betweenzero and three custom Java classes, which extend classes in the ADF BC library to modify theirbehavior. You will see the XML file and one of the Java classes in the hands-on practice.

Chapters 9 and 10 explain how to design entity object definitions.

AssociationsJust as tables are often related to one another, entity object definitions are often related to oneanother. Relationships between entity object definitions are represented by associations, asshown in Figure 8-1. You can think of an association as the representation of a relationship suchas a foreign key relationship. In the most common case, an association matches one or moreattributes of one entity object definition with one or more attributes of another entity objectdefinition, just as a foreign key constraint matches one or more columns of a parent table withone or more columns of a child table. If you are creating associations like this, you can (but donot need to) base them on foreign key constraints in the database. Associations, however, canalso represent more complex table relationships than this. These relationships are explained inChapter 9.

An association is implemented as an XML file, which provides metadata about the specifictable relationship.

DomainsDomains are special Java classes that may be used by ADF BC as the types for entity and viewattributes. Earlier, you learned that the Departments entity object definition has some entityattributes of type oracle.jbo.domain.Number. Entity attributes must be objects, notprimitive Java types such as int.

For database columns of SQL datatype VARCHAR2, there is an obvious Java class for the entityattributes, namely java.lang.String. For other SQL types (such as NUMBER or BLOB), ADF BCprovides domains to wrap the SQL datatype. Some domains, like oracle.jbo.domain.Number,are basically object wrappers for scalar types. Others, like oracle.jbo.domain.BlobDomain, aremore complicated classes that store extensive data.

JDeveloper will also automatically create a domain for you if you base an entity objectdefinition on a table with an Oracle object type column in it. This domain represents the Oracleobject type, giving you Java wrappers for each of the object type’s fields and methods. Domainsthat represent Oracle object types are discussed further in Chapter 9.

Finally, you may create your own domains. Suppose you have many database columns,possibly in different tables, that are all very similar. Not only are they of the same SQLtype (for instance, VARCHAR2), but they all contain information in exactly the same form,such as a URL. You may have business logic that is simultaneously associated with multiplecolumns. For example, you may have validation logic that applies to any and all URLs—perhaps they must all begin with a protocol code, a colon, and two slashes. Rather thanputting this logic in every entity object definition that contains one of these columns, youcan create a URL domain that itself contains the validation code. Then you can apply thevalidation logic to all the relevant entity attributes by ensuring that the appropriate entityattributes are all instances of that domain rather than of type java.lang.String. Domainsthat enforce business logic will be discussed further in Chapter 10.





Data Model ComponentsData model components are business components that collect data and present it to the view andcontroller through the ADF model layer. Data model components are not as reusable as businessdomain components: Their design is based on the data needs of particular client applications, sothey can only be shared by applications with similar data needs. They are still independent of a userinterface. A web application for self-service purchasing, a Java GUI application that allows salesstaff to edit purchases, and a batch program to update purchases overnight could all use the samedata model components, so long as they need to retrieve and update similar data. There are threekinds of data model components: view object definitions, view link definitions, and applicationmodule definitions.

View Object DefinitionsAn entity object definition usually represents a table or view in the database. But you generallydo not present all of the information stored in a database object in one application interface.Also, you may want data taken from more than one database object. SQL has queries so that youcan select exactly the data that you need from one or more tables. This is also the reason whyADF BC has view object definitions, which correspond to SQL queries. A view object definitionactually stores a SQL SELECT statement. In this respect, it is much like a database view.

Just as an entity object definition has entity attributes, a view object definition has viewattributes, which correspond to columns of the query result. For example, consider the viewobject definition, DepartmentsView, for the following query:

SELECT Departments.DEPARTMENT_ID,Departments.DEPARTMENT_NAME,Employees.EMPLOYEE_ID,Employees.FIRST_NAME,Employees.LAST_NAME,Employees.HIRE_DATE

FROM DEPARTMENTS Departments, EMPLOYEES EmployeesWHERE Departments.MANAGER_ID=Employees.EMPLOYEE_ID;

This view object definition would have the following view attributes:

Attribute Name Java Type

DepartmentId oracle.jbo.domain.Number

DepartmentName java.lang.String

EmployeeId oracle.jbo.domain.Number

FirstName java.lang.String

LastName java.lang.String

HireDate oracle.jbo.domain.Date





As shown in Figure 8-1, view object definitions may (but need not) contain one or more entityobject usages, which are references to entity object definitions. View attributes can then bemapped to entity attributes within the entity usages. For example, the DepartmentsView view objectdefinition could contain a usage of the entity object Departments. Then DepartmentsView’sDepartmentId attribute could be mapped to Department’s DepartmentId attribute, and similarlyfor other attributes.

As shown in Figure 8-1, a view object definition is the template for view object instances,which are particular caches of retrieved data. Your application may use several instances definedby the same view object definition; this is explained further in the section “Application ModuleDefinitions” later in this chapter.

View Link DefinitionsAs shown in Figure 8-1, a view link definition represents a relationship, such as a master-detailrelationship, between the query result sets of two view object definitions. It associates one ormore attributes of one view object definition with one or more attributes of another view objectdefinition. For example, you could create the following:

■ A view object definition, DepartmentsView, containing the following query:

SELECT Departments.DEPARTMENT_ID,

Departments.DEPARTMENT_NAME

FROM DEPARTMENTS Departments

■ Another view object definition, EmployeesView, containing the following query:

SELECT Employees.EMPLOYEE_ID,

Employees.FIRST_NAME,

Employees.LAST_NAME,

Employees.DEPARTMENT_ID

FROM EMPLOYEES Employees

■ A view link definition, EmpDeptFkLink, that associates the DepartmentId attribute ofEmployeesView with the DepartmentId attribute of DepartmentsView

EmpDeptFkLink represents a master-detail relationship between the query result sets ofDepartmentsView and EmployeesView.

As shown in Figure 8-1, view link definitions between view object definitions can be, but donot need to be, based on associations between underlying entity objects.

A view link definition is a template for view link instances, which specify relationshipsbetween particular view object instances, as shown in Figure 8-1.

Application Module DefinitionsAn application module definition defines and aggregates all of the data and relationships that anapplication will need. As shown in Figure 8-1, application module definitions can contain view objectand view link instances. An application module definition contains all of the view object instances





that your application requires and the view link instances between them. This collection of viewobject instances in a hierarchical relationship is called an application module definition’s data model.For example, an application module definition might contain an instance of DepartmentsView, calledAllDepartments, and an instance of EmployeesView, called DepartmentEmployees, linked by aninstance of EmpDeptFkLink, called DepartmentsToEmployees. The application module definitionwould use the data model shown here:

Using this application module definition, the two view object instances are tied togetherby a link (EmpDeptFkLink) representing a master-detail relationship between them. Through thisapplication module definition, your application could select a row in AllDepartments, and ADFBC would immediately synchronize DepartmentEmployees so that it would only returnemployees from the selected department.

Alternatively, your application module definition could contain an instance of DepartmentsViewand an instance of EmployeesView without using any instances of EmpDeptFkLink, as in the datamodel shown here:

This application module definition provides instances of the same two view objectdefinitions, but the instances are not linked. Through this application module definition, yourapplication could select rows in AllDepartments and AllEmployees independently.





You could even include two instances of EmployeesView in your application moduledefinition: one a detail of an instance of DepartmentsView and one independent, as in the datamodel shown here.

Through this application module definition, an application could select rows inDepartmentEmployees and have them automatically synchronized with AllDepartments. Itcould also select rows in AllEmployees independently.

An application module definition is a template for application module instances, whichare individual copies of the data model used by particular instances of the application. Eachapplication module instance represents an individual database transaction. For example, if youhave five different users running the same application, there will generally be five differentapplication module instances for them to use, representing five different transactions. (Actually,there may well be more or fewer because of application module pooling. For more information,see the sidebar “Application Module Pooling.”)

Application Module PoolingCreating an application module instance takes time, and storing all of the data contained inits view object instances takes space. In addition, it is rare that all the applications that arerunning at one time will really need access to data simultaneously. For example, in a webapplication, data can be retrieved and displayed, and then is not needed again until the usercompletes his or her “think time” and requests an update or refresh. ADF BC uses objectscalled application module pools to help maintain scalability by allowing multiple clientsto share application module instances. The operation of the application module pool iscompletely transparent. The pool will write transaction logs to the database and refresh datawhenever necessary to give users a consistent view of the data within their transactions.



Application module definitions can also contain instances of other application moduledefinitions, as shown in Figure 8-1. For example, MasterDetailModule might contain an instance ofIndependentViewsModule. This would allow clients that use an instance of MasterDetailModule toaccess the data model of IndependentViewsModule.

Hands-on Practice:Examine a Default ADF BC LayerIn this practice, you will create and explore a default ADF BC layer based on the HR schema. Adefault ADF BC layer is one created entirely using the Create Business Components from Tableswizard. It is basically a prototype. For enterprise applications, you can start with some wizard-generated components (or default components generated by the Class Modeler, discussed inChapter 9), but you should design most of your business components by hand. A default ADF BClayer does not contain any business logic. However, the default ADF BC layer created in thispractice contains examples of most of the business components discussed in this chapter: entityobject definitions, associations, view object definitions, view link definitions, and an applicationmodule definition.

This practice steps you through the following phases:

I. Create an application workspace with a default ADF BC layer

■ Create an application workspace

■ Create a default ADF BC layer for the HR schema

II. Explore the business domain components

■ Create a diagram of the business domain components

■ Explore an entity object definition

■ Explore an association

III. Explore the data model components

■ Create a diagram of the data model components

■ Explore a view object definition

■ Explore a view link definition

■ Explore an application module definition

IV. Test the default Business Components

■ Open the Business Component Browser

■ Test an independent instance of DepartmentsView

■ Test two different instances of EmployeesView

■ Test an instance of EmpDeptFkLink







I. Create an Application Workspace witha Default ADF BC LayerThis phase creates an application workspace with a default ADF BC layer in the Model project.

Create an Application WorkspaceYou can create a new workspace with a model project prepared for ADF BC using thefollowing steps:

1. On the Applications node in the Application Navigator, select New ApplicationWorkspace from the right-click menu. The Create Application Workspace dialog opens.

2. Enter the following values:

Application Name as “DefaultBC”Application Package Prefix as “defaultbc”Application Template as “Web Application [Default]”

Additional Information: The Application Package Prefix tells JDeveloper that everypackage you create in this application should be a subpackage of defaultbc. Forexample, your ADF BC layer will be under the defaultbc.model package. TheApplication Template tells JDeveloper that you want to create an application usingADF BC as your business services, Struts as your controller, and JSP or UIX as yourview. In this practice, the view and controller types are not important, but it isimportant to choose an application template that uses ADF BC.

3. Click OK. A new application workspace, DefaultBC, appears in the Navigator. Thisworkspace contains two projects, Model and ViewController, as shown here:

Additional Information: The Model project will hold ADF BC components, and would alsohold custom files for the ADF model, if any were required. The ViewController projectwould hold Struts, JSP, and/or UIX files, if you were creating a complete application.

Create a Default ADF BC Layer for the HR SchemaYou can create a default ADF BC layer using the following steps:

1. On the Model node in the Navigator, select New from the right-click menu. The NewGallery opens.

2. In the Categories pane, select Business Tier\Business Components. In the Items pane,select Business Components from Tables.

3. Click OK. The Business Components Project Initialization dialog opens.

4. Select HR from the Connection Name dropdown and click OK. The Create BusinessComponents from Tables Wizard opens. If the Welcome page appears, click Next.



5. On the Entity Objects page, type “defaultbc.model.businessdomain” in the Package field.

Additional Information: This page will create business domain components. Byputting business domain components in a separate subpackage of defaultbc.model,you can increase their reusability. If you later create another application that workswith the same database schema but has different data needs, you can importdefaultbc.model.businessdomain into that application and create a new setof data model components that use it.

6. Select DEPARTMENTS and EMPLOYEES and click the right arrow. This will create entityobject definitions (“Departments” and “Employees”) from each of those tables and createassociations from each of the foreign keys between them.

7. Click Next. The View Objects page opens. Enter “defaultbc.model.datamodel” in thePackage field.

Additional Information: This page will create view object definitions and viewlink definitions. By putting these components in a subpackage distinct fromdefaultbc.model.businessdomain, you can reuse the business domaincomponents without importing the data model components.

8. Click the right double-arrow.

Additional Information: This will tell the wizard that you want to create default viewobject definitions (“DepartmentsView” and “EmployeesView”) from each of the entityobject definitions and one view link definition for each association. As you will see later,default view object definitions and view link definitions are not very useful for many realapplications. (They correspond to “SELECT *” single-table queries and foreign-key–basedmaster-detail relationships rather than the more complex queries and relationships thatmost applications need.) But they are useful for testing the functionality of the entityobject definitions.

9. Click Next. The Application Module page opens.

10. Enter “defaultbc.model.datamodel” in the Package field, if it is not already there.

Additional Information: This page specifies whether the wizard should create anapplication module definition. This will place the application module definition in thesame package as the other data model components.

11. Leave the Application Module checkbox checked, with the name “AppModule” filled in.

Additional Information: This will cause the wizard to create a default applicationmodule definition that contains the view object instances in every possible combination,both independent and joined by view link instances. Again, the default applicationmodule would not be that useful for developing a real application (it is generally too bigand inefficient), but it is useful for testing a business components project.

12. Click Next. The Finish page appears.

Additional Information: The Finish page lists the primary business components (entityobject definitions, view object definitions, and the application module definition) thatthe wizard will create, as shown next:





13. Click Finish.

14. Click Save All.

What Just Happened? You created a default ADF BC layer. JDeveloper creates businesscomponents (entity object definitions, associations, view object definitions, view link definitions,and an application module definition) based on the choices you made in the wizard. The businesscomponents are under the Application Sources node in the Application Navigator, as shown next:

The icons next to the business components indicate the type of component. You can hold themouse over an icon to display the object type and name.





II. Explore the Business Domain ComponentsThis phase looks at the entity object definitions and associations in the packagehr.model.businessdomain.

Create a Diagram of the Business Domain ComponentsYou can create a UML diagram that provides a visual representation of the business domaincomponents using the following steps:

1. In the Application Navigator, on the defaultbc.model.businessdomain node, select Newfrom the right-click menu. The New Gallery opens. In the Categories pane, selectGeneral\Diagrams. In the Items pane, select Business Components Diagram.

2. Click OK to open the Create Business Components Diagram dialog.

3. Name the diagram “Business Domain Diagram” and click OK. A new node, BusinessDomain Diagram, is added to the Application Navigator underdefaultbc.model.businessdomain, and an empty diagram window opens.

4. In the Application Navigator, group select (CTRL click) the following components anddrag them onto the diagram:

■ Departments

■ DeptMgrFkAssoc

■ EmpDeptFkAssoc

■ Employees

■ EmpManagerFkAssoc

Additional Information: JDeveloper creates a UML diagram of the business domaincomponents, as shown in Figure 8-2. Entity object definitions are represented as boxes,and associations are represented as arrows.

NOTEYou may need to resize the diagram and drag some diagram elementsaround slightly before your diagram exactly resembles Figure 8-2. Inaddition, for readability in print, Figure 8-2 and similar diagramsthroughout this book do not show JDeveloper’s default color scheme,which uses dark blue to represent entity object definitions.

TIPFor maximum control while dragging lines in a diagram, hold downthe SHIFT key and click and drag from any point on the line to bend it.

5. Click Save All.





Explore an Entity Object DefinitionYou can view an entity object definition’s entity attributes and their types directly in the diagram,learn more about them using the Entity Object Editor (which you would use to fine-tune an entityobject definition), and see the files that make up an entity object definition in the Structure window.

1. Find the Departments entity object definition on the UML diagram (in Figure 8-2, it isthe upper box).

Additional Information: Note that the entity attributes, with their Java types, are listed.DepartmentId, ManagerId, and LocationId are all of type Number, which is a domain.DepartmentName is of type String.



FIGURE 8-2. A UML diagram of the business domain components





2. Double click either the Departments element in the diagram or the Departments node inthe Application Navigator to open the Entity Object Editor.

3. With the Name node selected, note that Departments is based on the schema objectDEPARTMENTS, as shown here:

4. Expand the Attributes node, and select the DepartmentId attribute.

5. In the Database Column section, note that the DepartmentId attribute is mapped to theDEPARTMENT_ID column in the database, as shown here:





6. Click Cancel to close the editor without making any changes.

7. In the Application Navigator, select Departments.

Additional Information: The Structure window displays a tree describing manyfeatures of the Departments entity object definition. In particular, under Sources, youcan see two files, Departments.xml and DepartmentsImpl.java, as shown next:

These files constitute the Departments entity object definition. Departments.xml is thefile that defines Departments’ metadata, and DepartmentsImpl.java is a file that defines acustom class, the entity object class, that extends the ADF BC library’s behavior. Entityobject classes are discussed in Chapter 10.

Explore an AssociationYou can examine an association directly on the diagram, or in more detail using the AssociationEditor, which you would also use to fine-tune an association:

1. Find the EmpDeptFkAssoc association in the UML diagram (in Figure 8-2, it is the longarrow on the left).

Additional Information: Note that this is an association between the Departments andEmployees entity object definitions.

2. Double click either the arrow or the EmpDeptFkAssoc node in the Application Navigatorto open the Association Editor.

Additional Information: Note that the source entity object definition is Departments(which contains the primary key) and the destination entity object definition isEmployees (which contains the foreign key). The wizard page shows the primary key





attribute under the source entity object node and the foreign key attribute under thedestination entity object node, as shown here:

3. Click Cancel to close the wizard without making any changes.

What Just Happened? You created a graphical representation of the business domaincomponents and looked at an entity object definition and an association. You saw that the entityobject definition corresponds to a database table and that it has entity attributes, some of whichhave domain datatypes, that correspond to database columns. You also saw the files that madeup a particular entity object definition. Finally, you saw that the association links two entityobject definitions, just as foreign key relationships link two tables.

III. Explore the Data Model ComponentsThis phase looks at the view object definitions, view link definitions, and application moduledefinition in the package defaultbc.model.datamodel.

Create a Diagram of the Data Model ComponentsAs with the business domain components, you can create a UML diagram that provides a visualrepresentation of the data model components using the following steps:

1. In the Application Navigator, on the defaultbc.model.datamodel node, select New fromthe right-click menu. The New Gallery opens.

2. In the Categories pane, select General\Diagrams. In the Items pane, select BusinessComponents Diagram.



3. Click OK. The Create Business Components Diagram dialog opens.

4. Name the diagram “Data Model Diagram” and click OK. A new node, Data ModelDiagram, is added to the Application Navigator under defaultbc.model.datamodel, andan empty diagram window opens.

5. In the Application Navigator, group select the following components and drag themonto the diagram:

■ AppModule

■ DepartmentsView

■ DeptMgrFkLink

■ EmpDeptFkLink

■ EmployeesView

■ EmpManagerFkLink

Additional Information: JDeveloper creates a UML class diagram of the data modelcomponents. This diagram will probably take up two pages, as shown in Figures 8-3and 8-4. View object definitions are represented as boxes containing other boxes (entityobject usages), view link definitions are represented as arrows, and application moduledefinitions are represented as boxes containing other boxes (view object instances) andarrows (view link instances).

NOTEYou may need to drag some diagram elements around beforeyour diagram exactly resembles Figures 8-3 and 8-4. In addition,for readability in print, Figures 8-3 and 8-4, and similar diagramsthroughout this book, do not use JDeveloper’s default color scheme,which uses light blue to represent view object definitions, dark blue torepresent entity object usages, medium blue to represent applicationmodule definitions, and very light blue to represent view objectinstances.

6. Click Save All.

Explore a View Object DefinitionYou can examine a view object definition’s view attributes and entity usages directly in thediagram, view its query using the View Object Editor (which you would use to fine-tune a viewobject definition), and see the files that make up a view object definition in the Structure window.

1. Find the DepartmentsView view object definition on the UML diagram (in Figure 8-3, itis the upper box).

Additional Information: Note that the view attributes, with their Java types, are listed.Also note that the view object definition contains a usage of Departments.





TIPYou can navigate around a large diagram like this one using theThumbnail window. For example, if you manipulate the box in theThumbnail window so that it resembles the following illustration, youwill see the portion of the diagram containing Figure 8-3.



FIGURE 8-3. A UML class diagram of the data model components showing view object andview link definitions





FIGURE 8-4. A UML diagram of the data model components showing an application moduledefinition



2. Double-click the DepartmentsView element in the diagram to open the View ObjectEditor.

3. Select the Query node to see the view object definition’s query, as shown next:


5. In the Application Navigator, select DepartmentsView.

Additional Information: The Structure window displays a tree describing manyfeatures of the Departments view object definition. In particular, under Sources, you cansee two files, DepartmentsView.xml and DepartmentsViewImpl.java. These files constitutethe DepartmentsView view object definition. DepartmentsView.xml is the file that definesDepartmentsView’s metadata, and DepartmentsViewImpl.java is a file that defines acustom class, the view object class, that extends the ADF BC library’s behavior. Viewobject classes are discussed in Chapter 13.

Explore a View Link DefinitionYou can examine a view link definition directly on the diagram, or in more detail using the ViewLink Editor, which you would also use to fine-tune a view link definition:

1. Find the EmpDeptFkLink view link definition in the UML diagram (in Figure 8-3, it is thelong arrow on the left).

Additional Information: This is a view link definition representing a master-detailrelationship between the DepartmentsView and EmployeesView view object definitions.







2. Double-click the arrow to open the View Link Editor.

3. Click the View Link SQL node. In the Query Clauses box, you can see the WHERE clausethat the view link will use to join Departments data to Employees data, shown next:

Additional Information: The attribute DepartmentsId from a row of a master instanceof DepartmentsView will be substituted for the parameter :1 in the WHERE clause“WHERE :1=Employees.DEPARTMENT_ID” to limit the rows returned by a detailinstance of EmployeesView. This definition is the reason why you will only be able tosee employees for the selected department if you use this view link in your data model.


Explore an Application Module DefinitionYou can examine an application module definition’s data model directly in the diagram and seethe files that constitute it in the Structure pane:

1. Find the AppModule application module definition in the UML diagram, as shown inFigure 8-4.

Additional Information: Note that the application module definition contains five separateview object instances, linked by three separate view link instances. DepartmentsView1 andEmployeesView1 are independent instances of DepartmentsView and EmployeesView,respectively. The other view object instances are linked to those instances, via view link





instances, as details in master-detail relationships. The data model of a default applicationmodule contains all possible view objects in all possible combinations: both independentand joined by view links. When you create your own application modules, you probablywill not want to do this. Instead, you will use just the view object and view link instancesyour application needs in just the combinations it needs.

2. In the Application Navigator, select AppModule.

Additional Information: The Structure pane displays a tree describing many features ofthe AppModule application module definition. In particular, under Sources, you can seetwo files, AppModule.xml and AppModuleImpl.java. These files constitute the AppModuleapplication module definition. AppModule.xml is the file that defines AppModule’smetadata, and AppModuleImpl.java is a file that defines a custom class, the applicationmodule class, that extends the ADF BC library’s behavior. Application module classesare discussed in Chapter 12.

What Just Happened? You created a diagram of the data model and looked at a view objectdefinition’s entity object usages and query, a view link definition’s SQL code, and an applicationmodule’s data model. You also saw the XML and Java files that constitute the view objectdefinition and application module definition.

IV. Test the Default Business ComponentsNow that you have examined the business components, you can look at them in action. Businesscomponents do not have a user interface, so it is not really possible to see the businesscomponents working except through a user interface.

JDeveloper includes a user interface, the Oracle Business Component Browser, which can berun to test any application module definition. The browser will be used to test AppModule. BecauseAppModule contains instances of all view object definitions in all possible combinations, testingAppModule is really a way of testing the entire business components project.

NOTEAs mentioned earlier, default application module definitions are notgenerally suitable for production-quality enterprise applicationsbecause they are too big. They contain instances of every view objectdefinition, linked together in every possible combination based onforeign key constraints in the database, instead of just the data modelelements that the application needs. This leads to a needlessly largecache, which can degrade performance. However, they are excellentfor testing all of your business components at once.

Open the Business Component BrowserYou can open the Business Component Browser to test an application module definition and itsassociated business components using the following steps:





1. In the diagram, on the AppModule element, select Test from the right-click menu. TheBusiness Component Browser starts up, showing the Connect dialog.

2. The defaults in the Connect dialog are fine for the purposes of this practice, so clickConnect. The main dialog of the Business Component Browser appears. In the left-handpane, you can see the AppModule’s data model, as shown next:

Test an Independent Instance of DepartmentsViewYou can scroll through the query results for an independent view object instance using thefollowing steps:

1. Double click DepartmentsView1. In the right-hand pane, you can now see the data fromDepartmentsView’s query, one row at a time.

2. Click the blue right arrow to scroll forward to Department 30 as shown next:





Test Two Different Instances of EmployeesViewYou can contrast detail and independent view object instances using the following steps:

1. Be sure that Department 30 is displayed. Double click EmployeesView3 in the left-handpane. In the right-hand pane, you can now see data from EmployeesView’s query, onerow at a time.

2. Scroll forward through the data. Notice that all the employees listed have DepartmentId 30.This is because ADF BC uses EmpDeptFkLink1 to automatically synchronizeEmployeesView3 with DepartmentsView1. The current row of DepartmentsView1is 30, so only employees with that department will show in EmployeesView3.

3. Double click EmployeesView1. The same kind of single-row browser is displayed.

4. Scroll forward through the data. Notice that EmployeesView1 contains all of theemployees, not just those with DepartmentId 30. That is because the EmployeesView1instance, unlike EmployeesView3, is not a detail of DepartmentsView1.

5. Click the red X in the toolbar to close each open window in turn.

TIPIf you want to pull a window out of the Oracle Business ComponentBrowser’s frame, click the blue up arrow in the toolbar.



Test an Instance of EmpDeptFkLinkYou can view a split-screen display of view object instances in a master-detail relationship usingthe following steps:

1. Double click EmpDeptFkLink1. The right-hand pane is now split. In the top half, youcan see rows from DepartmentsView1 one at a time, and in the bottom half, you can seea table of all rows currently showing in EmployeesView3. This is just another way theOracle Business Component Browser lets you see view object instances in a master-detail relationship. Selecting a view link instance lets you view both view objectinstances at once, as shown next:

2. Scroll through the departments. The list of employees automatically synchronizes withthe department in the top pane.

3. Close the Oracle Business Component Browser.

What Just Happened? You used the Business Component Browser to test your businesscomponents. You saw a display of all the view object and view link instances in your datamodel, two ways of displaying data in the Oracle Business Component Browser, and how viewlink instances synchronize detail view object instances with their master view object instances.





blind folio oracle series tight / oracle jdeveloper ...€¦ · 12/08/2004 · chapter 8:...

Documents