NYSDOL Standards and Best Practices

Data Access Layer Architecture and Design

Prepared by

Enterprise Planning and Architecture Strategies Team

Data Access Layer Architecture & Design Page 1 of 7

Version: 1.0 Last Modified: 9/14/2010
NYSDOL Standards and Best Practices

Control Page:

Revision History:
Version No Revised Date Author Comments
10/15/2008 Anitha Ramakrishnan Initial Draft
12/12/2008 Anitha Ramakrishnan Applied new template
02/27/2008 Anitha Ramakrishnan Made format changes
09/08/2010 EPAS Draft status removed

Acknowledgements:

Data Access Layer Architecture & Design Page 2 of 7

Version: 1.0 Last Modified: 9/14/2010
NYSDOL Standards and Best Practices

Table of Contents:

1 Introduction: .......................................................................................................................... 4

1.1 Purpose: ......................................................................................................................... 4

2 Standards and Best Practices: ............................................................................................ 4

2.1 High level Architecture: .................................................................................................. 5

2.2 Exceptions: ..................................................................................................................... 6

3 Tips and Techniques: ........................................................................................................... 7

4 Appendix:............................................................................................................................... 7

4.1 Examples / Sample Diagrams: ....................................................................................... 7

4.2 Abbreviations Used: ....................................................................................................... 7
4.3 Acronyms Used: ............................................................................................................. 7

5 References: ........................................................................................................................... 7

5.1 Bibliography:................................................................................................................... 7

Data Access Layer Architecture & Design Page 3 of 7

Version: 1.0 Last Modified: 9/14/2010
NYSDOL Standards and Best Practices

1 Introduction:

In the DOL P&T SOA development environment, SDLC standards documents are developed
collaboratively by all parties impacted by and involved in the software development process. The
Architecture Group (EPAS) coordinates the process to develop the standards, and then publishes
the standards on their page of the P&T website. It is understood that given the ever-changing
environment of software development, these standards are to be viewed as living documents. In
addition, as experience evolves our best practices, it is expected that these standards documents
will evolve as well.

SDLC staff may initiate a change request to any of these standards documents by contacting (in
the form of an email), the manager of the Architecture Group.

1.1 Purpose:

The purpose of the document is to outline at a high level, the design & architecture of data access
layer (DAL) to be used in our SOA based applications. The data access layer encapsulates the
data access logic and data access technologies used. It also clearly separates the data access
logic from business logic.

This document is intended for Enterprise Architects, Technical leads and Developers.

2 Standards and Best Practices:

 Although at present most of our information resides in legacy systems, there has been an
ongoing effort from the database group to create an enterprise data model to represent our
data domain and to make Oracle our primary data store in the future.

 Our current standard is to use the Hibernate Object Relational mapping (ORM) framework in
the data access layer to transform objects to a relational representation. This may be revised
in the future to use Service Data Objects (SDOs) with a Data Access Service (DAS) or
Enterprise JavaBeans (EJB3). However, the dependency and use of Hibernate should not be
exposed to the end user of the data access layer.

 The data access layer should provide a generic interface for database operations, for all
services (mostly entity services / processes) to access / update the data stores. There should
not be any direct data access code in the services. This clear separation will keep services
transparent to any changes to data access technology in the future as long as the interface to
the data access layer remains the same.

Data Access Layer Architecture & Design Page 4 of 7

Version: 1.0 Last Modified: 9/14/2010
NYSDOL Standards and Best Practices

2.1 High level Architecture:

Business / XSD objects DTO Mapper

DAL Consumer
1 (Maps business objects to
(Entity services / Business Data Transfer Objects input DTOs)
services / Business processes)

Data Transfer Objects (Maps output DTOs to

3 business objects, if required)
Business / XSD objects

Input DTO Output DTO

Data Access Layer

DAOs extending from GenericDAO Interface

Hibernate layer (object mappings and Hibernate jar)

Oracle Database

DAL Consumer:

The Data Access Layer Consumer in the above diagram represents the consumers of the data
access layer, which usually is the business layer and could be a service (mainly an entity service)
or even a business process. The services usually have XML inputs and outputs. These XML
objects could have other business elements along with the elements required to access the data
access layer. Hence, these XSD objects will have to be mapped to Data Transfer Objects (DTOs)
to pass as a parameter to the Data Access Objects (DAOs) in the data access layer. Data
Consumers use the DTO Mapper to do the mapping to DTOs and then call the DAOs in data
access layer to access the data store. The data access objects also map the DTOs to internal
representations for data access. The current mapping is done with Hibernate ORM library and its

Data Access Layer Architecture & Design Page 5 of 7

Version: 1.0 Last Modified: 9/14/2010
NYSDOL Standards and Best Practices

related tools. Our standard is to map primary keys IDs (usually defined as numeric(20) and auto
incremented sequentially) in database to a long data type in java. Other columns are mapped
based on their data type and length to a corresponding data types in java.

Data Access Layer Consumers reference the DTO Mapper and data access layer as external
jars.

DTO Mapper:

Data Transfer Object Mapper maps the XSD objects to Data Transfer Objects. These Data
Transfer Objects could either be the Hibernate generated objects or Plain Old Java Objects
(POJOs) created to represent a data domain subset according to the business requirement.

The DTO Mapper also maps the output Data Transfer Objects from the data access layer to XSD
objects (if they are not the same).

The DTO Mapper is separated from consumers, so that the objects could be reused across
multiple services or service operations, or could be reused to form composite objects across the
domain. Also, the changes to DTOs could be made transparent to the service implementation,
provided the service contract itself changes, in which case the services will have to be modified.

Data Access Layer:

The data access layer has a generic DAO Interface with basic create, retrieve, update and delete
(CRUD) operations and some specialized lookup operations that are implemented by the specific
DAOs like EmployerDAO, EmployerTaxRatingDAO etc. The generic DAO accepts request DTOs
and return the response DTO defined for the specific DAO. The interface takes DTOs as
parameters to the CRUD operations.

The data access objects also map the DTOs to relational representation using the Hibernate
ORM tool.

Note:

At present, the data access layer and DTO mapper are deployed as Jar files.

The document is based on discussions with the TAA and UI Tax Rating teams. The teams have
implemented the data access layer slightly differently, but within the acceptable parameters of
these standards.

2.2 Exceptions:

Any internal problems within the data access library are returned through a DOLCustomException
object thrown by the DAO. Refer to our standards document on exception handling to learn more
on the DOLCustomException which is a custom error of defined structure that is raised by all
components in our SOA environment. Exceptions may arise from validations (input and output),
database access problems, and system problems. Handling of the exception is the responsibility
of the DAL Consumer.

Data Access Layer Architecture & Design Page 6 of 7

Version: 1.0 Last Modified: 9/14/2010
NYSDOL Standards and Best Practices

3 Tips and Techniques:

None.

4 Appendix:

4.1 Examples / Sample Diagrams:

None.

4.2 Abbreviations Used:

None.

4.3 Acronyms Used:

CRUD Create, Retrieve, Update, Delete

DAL Data Access Layer
DAO Data Access Object
DAS Data Access Service
DTO Data Transfer Object
EJB3 Enterprise Java Beans
ORM Object Relational Mapping
POJO Plain Old Java Object
SDO Service Data Objects
SDLC Service Development Life Cycle
EPAS Enterprise Planning and Architecture Strategies
SOA Service Oriented Architecture
TAA Trade Adjustment Assistance
UI Unemployment Insurance

5 References:
There is also DAL Technical specification document prepared by UI team and is available in
ClearCase at

/UISIM/DALCORE001/EnterpriseDataModel/DataAccessLib/doc/DataAccessLibrary_Tech_Spec.
doc

5.1 Bibliography:

None.

Data Access Layer Architecture & Design Page 7 of 7

Version: 1.0 Last Modified: 9/14/2010