DAL(4)

Data Access Component

The Data Access component is a group oftypes (i.e., interfaces and classes) that DAL uses to perform object torelational mapping and to service applications' requests for data. Strictlyspeaking the Data Access component is a component of an application, but it isdiscussed here because DAL is impossible to understand or use without it.

 

Some of the Data Access component's types arerequired, and are generated for an application by DEDE, a development tooldescribed below. Others are optional, and must be hand-coded if they areneeded.

 

The Data Accesscomponent's types are summarized in the following table.

Type	Class interface	Requiredoptional	Customary type name (dsname represents datasource name)
Data Object (DO), or entity	interface	required	dsname
Data Object implementation (DO implementation)	class	required	dsnameCodeGenDoImpl
Data Object extension (DO extension)	class	optional	dsnameDoImpl
Data Access Object (DAO)	class	required	dsnameDAO
Map	class	required	GenericMap

 

The datasource mentioned above is anabstraction, which increases DAL's flexibility. A datasource represents aparticular collection of data, such as information from registered users'profiles. DAL maps each datasource to a particular table (or, in some cases, aparticular set of tables) that contains the data. DAL may map the samedatasource to different tables (or sets of tables), transparently to theapplication. For example, DAL might map a datasource to different tables forapplications running in different datacenters, or for applications running inQA and production.

 

Datasources are discussed in more detail in 4. DAL, Data Dependent Routing (DDR).

Each Data Access type except the map iscustomarily named after the datasource, with a suffix that indicates the typeof component the file defines. For example, if an application uses a datasourcenamed ExTable,the DO for that datasource is named ExTable (with a null suffix); the DO implementationis named ExTableCodeGenDoImpl; and the data access object is named ExTableDAO. DEDE allows you to specify a different typename root in cases where the datasource name is pre-empted or confusing.

 

For every datasource an application uses thereis one DO, one DAO, and one map. That is not true of the DO implementation andthe DO extension, though. The Query Engine typically returns an instance of theDO implementation (and the DO extension, if any) for each row it reads. Theapplication may define additional instances for its own purposes, such asspecifying selection criteria for a read operation.

 

The Data Object and the Data ObjectImplementation

A Data Object (DO)is an interface that represents a row in a table, with data propertiescorresponding to the fields in the row. A Data Object implementation (DOimplementation) is a class that implements the DO interface. A Data Objectmay also be referred to as an entity, a term borrowed from the JavaPersistence API (JPA). Note. "Data Object" (the interface) isa different term than "data object" (the persistent layer modelequivalent of a row in a table). To reduce the risk of confusion, "DataObject" (the interface) is always capitalized; "data object"(equivalent of a row) is not.

 

DEDE can generate a DO from the table, or itcan generate a table from a hand-coded DO. In either case, DEDE ensures that the DO and the table are consistentlydefined, and it generates the DO implementation from the DO.  You can change the table's structure by handand use DEDE to regenerate the DO from it. Conversely, you can change the DO byhand, and use DEDE to modify the table's structure. In either case, DEDEregenerates the DO implementation.

 

A DO defines dataproperties and get and set methods that represent the fields in thecorresponding table row.  Annotations specify how the dataproperties in the DO will be used.  Thecorresponding DO implements the methods defined in the DO, tracks the state ofDO attributes (i.e., null, loaded, or dirty) and sub-object references controls the mechanics of lazy fetch(loading rarely used fields only when they are referenced). You should neveradd hand-written extensions to a DO implementation, because your work will belost the next time DEDE regenerates the class. If you need to modify thebehavior of the class you can do so by hand-coding a separate DO extensionclass. When the DO implementation is regenerated, the DO extension will not beaffected.

 

A data access object (DAO) is a class that manages create, read, update, and delete(CRUD) operations for a table. DEDE generates a DAO from the correspondingDO.  A DAO defines CRUD methods whichread and modify data in ways that are appropriate for the table's mode of usedefines read sets, update sets, and SQL statements to read data into a DOimplementation and to update the table from a DO implementation registerselements of the DO and DAO with the map object. The DAO, unlike the DO, may safely be extended with hand-written code.DEDE will not regenerate the DAO unless you explicitly ask it to do so.

 

A map holdsinformation that DAL needs to read and write a table, such as the ORM rules,SQL statements, and the read sets and update sets registered by the DAO.

Unlike the other objects described in thissection, the map does not have a customized class for each table.  Every table's map is an instance of the classGenericMap. Thisis possible because the map is entirely populated at run time.