Technologist Career Management System

The Data Services Layers

As a review of the last TCMS installment:

“Showcase TCMS … The Data Services Stories”

The TCMS consists of two domains:

1. Services Domain – The Info Services for Database and Cloud Service Data

2. The Application Domain – The MVC Design Pattern that Consumes Info Services

The Application Domain is an MVC 4 Web Application. It Uses the MVC Architecture to manage Interactive State Data.

The Services Domain manages the information from a Data Repository and Cloud Services.

This information is formatted into Complex Composite Data Transfer Objects (DTOs) that contain the Data DTOs and its Error and Exception Handling object.

The TCMS Sub-domains

This section will introduce you to the “Sub-domains”:

1. The Services Data– A Relational 3^rd Normal Form Data Model in a SQL 2012 Database sub-domain

2. The Data DAL – The Object Relational Mapping (ORM) Data Abstraction Layer (DAL) for the Services Data sub-domain using Entity Framework 5 as its ORM

3. The Data Ops – The Anti-corruption Data Operations Layer (DOL) that consumes the Data DAL sub-domain.

   This sub-domain is providing all the Information Data Transfer Objects (DTOs) for Client Consumption with their Error and Exception Handling Object.

   The Data Ops sub-domain abstracts the SQL Database from the Data Ops sub-domain

These three sub-domains create the Services Information Data Services Component:

The Services Data Sub-domain

The Data Model is organized into a database relational representation of the Domain Driven Design (DDD) Business Entities.

There are Four Relational Data Models in the TCMS Data Model:

1. The Assessment Data Model– Holds the assessment results as the Highest level Domain Entity

2. The People Data Model– Holds the Candidates information for the Assessment results

3. The Skills Data Model– Holds the Technology Skills that a Candidate is being assessed

4. The Questions Data Model – Holds the Skills and Assessment questions used to assess Candidates

There are three types of Data Tables in the diagram

1. Entity Tables – These are the primary information data tables. They provide an Identity for the DDD Entities

2. Look-up Tables – These tables provide the information for the DDD Value Objects. The Look-up tables hold all the related information without any identities to and Entity

3. Bridge Tables – These tables, sometimes referred to as “Link” or “Join” tables, create the ability for the Entities to create Collections of Value table information. They create a “One-To-Many” Data Model relationship

Each of the Four Data Model Entities and their supporting Aggregate Value tables are displayed below: 

The Data DAL Sub-domain

This layer is the Object Relational Mapping component. Using Entity Framework, the Data Abstraction Layer manages all the database operations.

The Domain Entity Class Object Model:

The Entity Class Model creates classes that represent the Relational Data Model within the SQL database.

It simplifies the Class Object Model for consumption through its own evaluation of the SQL Data Model when it creates the Class Object Model.

Notice that simple Bridge Tables within the SQL Data Model do not exist within the Class Object Model. The ORM understands the Many-To-Many Relationships and can manage all of the required operations without the consuming client‘s understanding of the Bridge Tables.

More complex Bridge Tables, such as the Triple Keys Tables are represented as they have “Forking” options that do need Client consumption understanding.

Color coding in Entity Framework 5 clearly identifies the Domain Entities as defined in the Domain Driven Design.

This sub-domain delivers clean access to the Domain Business Objects for consumption in the next higher sub-domain: Data Ops.

The Data Ops Sub-domain

The Data Ops sub-domain is the Transformation Layer for the raw ORM data to the ResponseDTO data.

Direct data access to the ORM class objects provide the raw source data for the domain business objects.

The Data Transfer Objects (DTOs) that carry the “Data Payload” to the requesting Client is transformed from the Raw ORM data.

These ResponseDTO objects are far more complex than the simple class objects returned from the Data DAL sub-domain ORM.

The Business Services Component services processes the RequestDTO from the consuming Client application and responds with a ResponseDTO state object as a single “Big Box” data payload package.

The Composite Request DTO “Big Box” Contains:

1. RequestCommon – This is a base Class State DTO that holds all common properties. These are properties that consumed the Cross Cutting Concerns of Info Services: Logging and Messages

2. RequestDTO – Data Ops receives the RequestDTO as a derived class of RequestCommon that contains the parameter object of primitives and Collection Aggregate DTOs required for the Data DAL ORM call

Data Ops transforms the Raw ORM Class Object Data into the Complex Composite DTO: ResponseDTO

The Composite Response DTO “Big Box” Contains:

1. ErrorCommon – This is a base Class State DTO that holds the Error Handling Object and Interface Extension Methods. Interface Inheritance, Composition, is employed to access the Behavior methods for Error and Exception handling

2. ResponseDTO – Data Ops returns the ResponseDTO as a derived class of ErrorCommon. This Return Complex Composite DTO is the Container for all Primitives, Collections and the Base Class Error Object that holds all Error and Exception information

The Request and Response DTO Details

The major advantage of the “Big Box” paradigm is the Error Object.

It contains Interface Extension Methods that create “Bubble Up” Error and Exception Messages in a Collection that can be iterated using its Index.

The index zero is the lowest abstraction module layer and the Error List count minus one is the highest or last error received.

This creates a valuable resource for User Interface displays and Architecture Logging and Troubleshooting.

The Highest Level Messages can be Designed as Meaningful User Interface Informational Notices

These possibilities only exists because of the Complex Composite DTO design.

This paradigm does not exist within the Entity Framework ORM when data is called directly

The Big Box Paradigm with its Error Object

… Is Why The Modern Developer

…… Uses a Complex DTO Transformations

The Next Installment of the TCMS Solution

Showcase TCMS

…… The Messaging Module