|
|
Chapter 20 - Implementation
Class Diagram, Entity Relationship Diagram and Database can be used to generate the persistent code. This chapter shows you how to generate the persistent code and describes how the Object Model maps to ORM-Persistent Class.
In this chapter:
Persistent code is the object that exposes the ability to store and retrieve data in relational databases permanently. An instance of the persistence class represents a row of a database table. As the persistent code is generated based on the object models, a mapping between object models and relational models is automatically built, which in turn supports your software development in database applications in an easier way.
You are provided with three ways to generate persistent code.
As persistent code is generated based on the object model, and it will be used to manipulate the relational database which is the data model, if the object and data models were not synchronized, the generated persistent code may become malfunction.
Hence, there is a prerequisite of using Database Code Generation dialog box to generate persistent code, which is the synchronization between object and data models. The persistent code will be generated successfully as if the object and data models are synchronized in advance. For information on synchronization from data model to object model, refer to Synchronizing from a Data Model to an Object Model in the Object Model chapter.
To generate the persistent code from data model, synchronize the data model to object model before performing the following steps.
 |
|---|
| Figure 20.1 - To generate code |
The Database Code Generation dialog box is displayed.
 |
|---|
| Figure 20.2 - Database Code Generation dialog |
 |
|---|
| Figure 20.3 - Select programming code for generate |
 |
|---|
| Figure 20.4 - Generate ORM Code/Database dialog |
The persistent code is generated.
By specifying the settings of code generation for Java, the Java persistence class will be generated accordingly.
 |
|---|
| Figure 20.5 - Generate code setting for Java |
Select the type of ordered collection to be used in handling the multiple cardinality relationship, either List or Map.
Select the type of un-ordered collection to be used in handling the multiple cardinality relationship, either Set or Bag.
Select the way that you want to override the toString method of the object. There are three options provided to override the toString method as follows:
"Entity[<column1_name>=<column1_value><column2_name>=<column2_value>...]"
Select the way to handle errors when they occur.
 |
|---|
| Figure 20.6 - Error Handling options |
Check the option to avoid the associated objects from being loaded when the main object is loaded. Uncheck the option will result in loading the associated objects when the main object is loaded.
Select the type of association handling to be used, either Smart, or Standard.
With smart association handling, when you update one end of a bi-directional association, the generated persistent code is able to update the other end automatically. Besides, you do not need to cast the retrieved object(s) into its corresponding persistence class when retrieving object(s) from the collection.
With standard association handling, you must update both ends of a bi-directional association manually to maintain the consistency of association. Besides, casting of object(s) to its corresponding persistence class is required when retrieving object(s) from the collection.
 |
|---|
| Figure 20.7 - Association Handling options |
Select the type of persistent code to be generated, either Static Methods, Factory Class, DAO or POJO.
 |
|---|
| Figure 20.8 - Persistent API options |
You can check the option for Generate Criteria to generate the criteria class for each ORM Persistable class. The criteria class supports querying the database by specifying the searching criteria. For information on using the criteria, refer to the description of Using Criteria Class in the Manipulating Persistent Data with Java chapter.
You are allowed to select the libraries and JDBC driver to be included in the generation of the orm.jar file. Click on the Select Optional Jar button, the Select Optional Jar dialog box is displayed. Check the desired libraries to be included in the orm.jar which will be built at runtime.
 |
|---|
| Figure 20.9 - Select optional Jar dialog |
Sample files, including Java application sample, servlet sample and Java Server Page (JSP) sample are available for generation. The generated sample files guide you through the usage of the Java persistence class. You can check the options to generate the sample files for reference.
 |
|---|
| Figure 20.10 - Generate samples options |
Scripts, including Ant File, Batch and Shell Script are available for generation. You can execute the generated scripts directly.
 |
|---|
| Figure 20.11 - Generate scripts options |
By specifying the settings of code generation for C#, the C# persistence class will be generated accordingly.
 |
|---|
| Figure 20.12 - Generate Code options for C# |
Select the type of ordered collection to be used in handling the multiple cardinality relationship, either List or Map.
Select the type of un-ordered collection to be used in handling the multiple cardinality relationship, either Set or Bag.
Select the way that you want to override the toString method of the object. There are three options provided to override the toString method as follows:
"Entity[<column1_name>=<column1_value><column2_name>=(column2_value>...]"
Select the way to handle errors when they occur.
 |
|---|
| Figure 20.13 - Error Handling options |
Check the option to avoid the associated objects from being loaded when the main object is loaded. Uncheck the option will result in loading the associated objects when the main object is loaded.
Select the type of association handling to be used, either Smart, or Standard.
With smart association handling, updating one end of a bi-directional association will update the other end automatically. Besides, casting of object(s) is not needed when retrieving object(s) from the collection.
With standard association handling, both ends of a bi-directional association must be updated manually to maintain the consistency of association. Besides, casting of object(s) is required when retrieving object(s) from the collection.
 |
|---|
| Figure 20.14 - Association Handling options |
Select the type of persistent code to be generated, either Static Methods, Factory Class, DAO or POJO.
 |
|---|
| Figure 20.15 - Persistent API |
You can check the option for Generate Criteria to generate the criteria class for each ORM Persistable class. The criteria class supports querying the database by specifying the searching criteria. For information on using the criteria, refer to the description of Using Criteria Class in the Manipulating Persistent Data with .NET chapter.
Specify the name of the assembly for the .NET application which holds the assembly metadata.
By checking the option of Compile to DLL, the DLL files will be generated, which can be referenced by .NET projects of language other than C# source.
 |
|---|
| Figure 20.16 - Select the location of .NET Framework |
Sample files, C# project file are available for generation for reference. The generated sample files guide you through the usage of the .NET persistence class. You can check the options to generate the sample files.
 |
|---|
| Figure 20.17 - Generate samples options |
For information on generating persistent code from data model by using wizard, refer to the descriptions of Generating Code and Database from ERD in the Using ORM Wizard chapter.
You can generate the persistent code from object model in one of the two ways:
Persistent code is designed to manipulate the relational database. The persistent code maps to object model; and meanwhile, data model maps to relational database. Thus, synchronization between object model and data model is important such that the object-relational mapping environment can be built successfully.
Hence, synchronizing the object model to data model is the prerequisite of using Database Code Generation dialog box. For more information, refer to Synchronizing from an Object Model to a Data Model in the Data Model chapter.
For information about using Database Code Generation dialog box, refer to Using Database Code Generation Dialog Box section.
For information on generating persistent code from object model by using wizard, refer to the descriptions of Generating Code and Database from Class Diagram in the Using ORM Wizard chapter.
You can generate the persistent code from database by using Wizard. For more information, refer to the descriptions of Generating Code from Database in the Using ORM Wizard chapter.
The persistent code can be generated with the support on mapping from Object Model to Persistent Code. In this section, examples will be given to show the mapping between object model and Java persistence class.
For each class element which may have attributes and methods in the object model, a corresponding Java class will be generated. The generated ORM persistable Java class will have the name as same as the name of the class element for identification. As if the class element has attributes with specified data types, all the attributes and data types will map to the Java class as well.
Example:
 |
|---|
| Figure 20.18 - Mapping the class model to code |
In the above example, an ORM-Persistable Java class, Product was generated according to the class Product in the object model. There are three types of mapping shown above:
The name of the class, Product maps to the name of the Java class, Product. (It is illustrated by the red line in the diagram.)
The attributes of the class map to the attributes of the Java class. (It is illustrated by the green line in the diagram.) Besides, a pair of getter and setter methods for the corresponding attribute is generated to the Java class.
The data type of the class maps to the data type of the Java Class. (It is illustrated by the blue line in the diagram.)
The following table shows the data type mapping between object model and Java persistent code.
| Object Model | Java Persistent Code |
|---|---|
| Boolean | boolean |
| Byte | byte |
| Byte[] | byte[] |
| Blob | java.sql.Blob |
| Char | char |
| Character | character |
| String | String |
| Int | int |
| Integer | Integer |
| Double | int |
| Bigdecimal | BigDecimal |
| Float | float |
| Long | long |
| Short | short |
| Date | java.util.Date |
| Time | java.sql.Time |
| Timestamp | java.sql.Timestamp |
As object model maps to data model bridging the environment between object model and relational database, primary key is mapped. As the object model maps to persistent code, primary key is in turn mapped.
Example:
 |
|---|
| Figure 20.19 - Mapping primary key |
In the above example, the primary key of Product entity, ProductID maps to an attribute, ProductID of class element, Product, which in turn becomes an attribute of the Java class.
In the ORM-Persistable class, a pair of getter and setter methods for the attribute is generated for accessing its value. Besides, the ORM-Persistable class has a method named as getORMID which returns the primary key value of the class.
In the above example, the getORMID() method returns the value by calling the method getProductID() which returns the value of ProductID. It thus signifies ProductID is the primary key of the class.
Generalization distributes the commonalities from the superclass among a group of subclasses. The subclass is consistent with the superclass and it may contain additional attributes and methods to make it specific.
Mapping generalization hierarchy to persistent code, the superclass and its subclasses are generated to individual Java class while the subclasses inherit all the superclass attributes and methods.
Example:
 |
|---|
| Figure 20.20 - Mapping generalization |
In the above example, the generalization hierarchy of BankAccount, CheckingAccount and SavingAccount maps to three ORM-Persistable Java classes where the subclasses, CheckingAccount and SavingAccount extend their superclass, BankAccoount so as to inherit the BankAccount's attributes and methods.
An association specifies the semantic relationship between two classes in the object model with a role attached at one end. The role specifies the detailed behavior of a class associated in the association, including its role name, which indicates how the class acts in the association; and multiplicity, which specifies the number of links between each instance of the associated classes.
The role name of the association maps to an attribute which specifies how the class associates with its associated supplier class with respect to multiplicity. If a class has a multiplicity of many in an association, the class maps not only to an ORM persistent Java class, but also to a collection class which supports manipulating the objects within a collection.
 |
You are allowed to define the type of collection class for code generation. Meanwhile, List and Set are the default types for ordered and un-ordered collection respectively. |
Example:
 |
|---|
| Figure 20.21 - Classes with one-to-many association |
In the above object model, there is a one-to-many association between Customer class and PurchaseOrder class; defining that a customer can place many purchase order meanwhile a purchase order is placed by one customer. As object model maps to persistent code, three ORM-Persistable classes will be generated, including Customer, PurchaseOrder and PurchaseOrderSetCollection classes.
 |
|---|
| Figure 20.22 - Mapping class with multiplicity of one |
From the above diagram, PurchaseOrder class has the role of "PlacedBy" in the association and it is associated with the Customer class with multiplicity of one. The role, "PlacedBy" maps as an attribute to the PurchaseOrder class which is defined as the data type of Customer class; it implies that the attribute "PlacedBy" stores a customer object which places the particular purchase order.
 |
|---|
| Figure 20.23 - Mapping class has the multiplicity of many |
From the above diagram, Customer has the role of "Places" in the association which associates with many PurchaseOrder instances. As the PurchaseOrder class has the multiplicity of many in the association, a collection class is generated so as to manipulate the multiple instances of PurchaseOrder. The role, "Places" maps as an attribute to the Customer class with the data type of PurchaseOrderSetCollection class; it implies that the attribute "Places" represents a collection of PurchaseOrder objects which was placed by a particular customer.
An association, which specifies a semantic relationship occurring between typed instances, has at least two ends represented by properties. When a property at an end of the association is owned by an end class, it represents the association is navigable from the opposite ends. On the contrary, when a property does not appear in the namespace of any associated class, it represents a non-navigable end of the association.
An open arrowhead on the end of an association indicates the end is navigable. Meanwhile, a small cross (x) on the end of an association indicates the end is not navigable. If an association has two navigable ends, it is considered as bi-directional associations.As the role name of the association maps to an attribute which specifies how the class associates with its associated class, however if the association has a non-navigable end, the corresponding role name will not map to an attribute, suppressing the ownership of the class.
Example:
 |
|---|
| Figure 20.24 - Classes with Navigable Association |
In the above object model, it shows a binary association with one end navigable and the other non-navigable. It indicates that Product is owned by OrderLine while Product cannot own OrderLine. As the object model maps to persistent code, the ownership of OrderLine instance in Product class will not be generated in the persistent code.
 |
|---|
| Figure 20.25 - Mapping Navigable Association |
From the above diagram, OrderLine class has the role of "Orders" in the association and associated with the one Product instance. The role, "Orders" maps as an attribute to OrderLine class which defines as the data type of Product; it implies that the attribute "Orders" stores a product instance.
On the other hand, Product class has the role of "OrderedBy" associated with many OrderLine instances in a non-navigable association; that is, Product class does not have the ownership of OrderLine. Even though the OrderLine class has the multiplicity of many in the association, the corresponding collection class of OrderLine for the Product class is not generated to manipulate it.
As the .NET persistence class can be generated with the support on mapping from Object Model to Persistent Code. In this section, examples will be given to show the mapping between object model and .Net persistence class.
For each class element which may have attributes and methods in the object model, a corresponding persistence class of C# will be generated. The generated ORM persistable .NET class will have the name as same as the name of the class element for identification. As if the class element has attributes with specified data types, all the attributes and data types will map to the .NET persistence class as well.
Example:
 |
|---|
| Figure 20.26 - Mapping Classes, Attributes and Data Types |
In the above example, an ORM-Persistable .NET class, Product was generated according to the class Product in the object model. There are three types of mapping shown above:
The name of the class, Product maps to the name of the .NET persistence class, Product. (It is illustrated by the red line in the diagram.)
The attributes of the class map to the attributes of the .NET persistence class. (It is illustrated by the green line in the diagram.) Besides, a pair of getter and setter methods for the corresponding attribute is generated to the persistence class.
The data type of the class maps to the data type of the .NET persistence class. (It is illustrated by the blue line in the diagram.)
The following table shows the data type mapping between object model and .NET persistent code.
| Object Model | .NET Persistent Code |
|---|---|
| Boolean | bool |
| Byte | byte |
| Byte[] | byte[] |
| Blob | byte[] |
| Char | char |
| Character | char |
| String | string |
| Int | int |
| Integer | int |
| Double | double |
| Decimal | Decimal |
| Float | float |
| Long | long |
| Short | short |
| Date | DateTime |
| Time | DateTime |
| Timestamp | DateTime |
As object model maps to data model bridging the environment between object model and relational database, primary key is mapped. As the object model maps to persistent code, primary key is in turn mapped.
Example:
 |
|---|
| Figure 20.27 - Mapping primary key |
In the above example, the primary key of Product entity, ProductID maps to an attribute, ProductID of class element, Product, which in turn becomes an attribute of the .NET persistence class.
In the ORM-Persistable .NET class, a pair of getter and setter methods for the attribute is generated for accessing its value. Besides, the ORM-Persistable .NET class has a method of getting the ORMID which returns the primary key value of the class.
In the above example, the getter method of ORMID returns the value by calling the getter method of ProductID which returns the value of __ProductID. It thus signifies ProductID is the primary key of the class.
Generalization distributes the commonalities from the superclass among a group of subclasses. The subclass is consistent with the superclass and it may contain additional attributes and methods to make it specific.
Mapping generalization hierarchy to persistent code, the superclass and its subclasses are generated to individual .NET persistence class while the subclasses inherit all the superclass attributes and methods.
Example:
 |
|---|
| Figure 20.28 - Mapping generalization |
In the above example, the generalization hierarchy of BankAccount, CheckingAccount and SavingAccount maps to three ORM-Persistable .NET classes where the subclasses, CheckingAccount and SavingAccount extend their superclass, BankAccoount so as to inherit the BankAccount's attributes and methods.
An association specifies the semantic relationship between two classes in the object model with a role attached at one end. The role specifies the detailed behavior of a class associated in the association, including its role name, which indicates how the class acts in the association; and multiplicity, which specifies the number of links between each instance of the associated classes.
The role name of the association maps to an attribute which specifies how the class associates with its associated supplier class with respect to multiplicity. If a class has a multiplicity of many in an association, the class maps not only to an ORM persistent .NET class, but also to a collection class which supports manipulating the objects within a collection.
|
You are allowed to define the type of collection class for code generation. Meanwhile, List and Set are the default types for ordered and un-ordered collection respectively. |
Example:
 |
|---|
| Figure 20.29 - Classes with one-to-many relationship |
In the above object model, there is a one-to-many association between Customer class and PurchaseOrder class; defining that a customer can place many purchase order meanwhile a purchase order is placed by one customer. As object model maps to persistent code, three ORM-Persistable .NET classes will be generated, including Customer, PurchaseOrder and PurchaseOrderSetCollection classes.
 |
|---|
| Figure 20.30 - Mapping class with multiplicity of one |
From the above diagram, PurchaseOrder class has the role of "PlacedBy" in the association and it is associated with the Customer class with multiplicity of one. The role, "PlacedBy" maps as an attribute to the PurchaseOrder class which is defined as the data type of Customer class; it implies that the attribute "PlacedBy" stores a customer object which places the particular purchase order.
 |
|---|
| Figure 20.31 - Mapping class has the multiplicity of many in the association |
From the above diagram, Customer has the role of "Places" in the association which associates with many PurchaseOrder instances. As the PurchaseOrder class has the multiplicity of many in the association, a collection class is generated so as to manipulate the multiple instances of PurchaseOrder. The role, "Places" maps as an attribute to the Customer class with the data type of PurchaseOrderSetCollection class; it implies that the attribute "Places" represents a collection of PurchaseOrder objects which was placed by a particular customer.
An association, which specifies a semantic relationship occurring between typed instances, has at least two ends represented by properties. When a property at an end of the association is owned by an end class, it represents the association is navigable from the opposite ends. On the contrary, when a property does not appear in the namespace of any associated class, it represents a non-navigable end of the association.
An open arrowhead on the end of an association indicates the end is navigable. Meanwhile, a small cross (x) on the end of an association indicates the end is not navigable. If an association has two navigable ends, it is considered as bi-directional associations.
As the role name of the association maps to an attribute which specifies how the class associates with its associated class, however if the association has a non-navigable end, the corresponding role name will not map to an attribute, suppressing the ownership of the class.
Example:
 |
|---|
| Figure 20.32 - Classes with Navigable Association |
In the above object model, it shows a binary association with one end navigable and the other non-navigable. It indicates that Product is owned by OrderLine while Product cannot own OrderLine. As the object model maps to persistent code, the ownership of OrderLine instance in Product class will not be generated in the persistent code.
 |
|---|
From the above diagram, OrderLine class has the role of "Orders" in the association and associated with the one Product instance. The role, "Orders" maps as an attribute to OrderLine class which defines as the data type of Product; it implies that the attribute "Orders" stores a product instance.
On the other hand, Product class has the role of "OrderedBy" associated with many OrderLine instances in a non-navigable association; that is, Product class does not have the ownership of OrderLine. Even though the OrderLine class has the multiplicity of many in the association, the corresponding collection class of OrderLine for the Product class is not generated to manipulate it.
|
|
|||||||