Modularizing the Data-Access Layer

I've been giving it some thought, and I think the Data-Access Layer(DAL) should refer to more than accessing data within databases. Data can come in many other formats such as XML, CSV, and SOAP(as a client only). So how do we change the DAL to incorporate different data types?

1. We set up a DAL interface object, insuring each type of data has a common set of operations. (Read, Write, Insert, Update, Delete).

2. We implement each type of DA as a Data-Access Provider (DAP). Most languages provide utilities for accessing different types of data. You can leverage those utilities within your DAPs.

3. Each DAP communicates with the Business Logic (BL) with Entities. For example, I need to retrieve data via SOAP and insert it into the database. The BL asks the SOAP DAP for a list of Entities. The BL then processes and filters the Entities. Finally, it asks the database DAP to insert the processed Entities into the database.

Resulting Structure


Standardizing the way we access and move data has many advantages. It simplifies the way we structure our code and project. It allows for optimal code reuse. It's modular, meaning you can add new DAPs as the need arises. Finally, configuration can allow you to change DAPs without re-compiling code.

Hybrid MultiTier MVC Architecture

How do we leverage the advantages of both MVC and Multitier architecture?

I. About Entities
As the data moves between software components, it is packaged in an object we will call an Entity. Entities do not contain logic, they only hold data. Keeping data within entities ensures that every component of the application has a common way of accessing data.

Imagine a baseball team. Each player represents a program component, while the ball represents the data. The players rely on assumptions about the ball, mainly size and weight. Imagine if a softball player were to join the team. He normally uses a larger ball. When a baseball is thrown/hit in his direction, he will have a hard time catching it until he adjusts to the differences in the way the ball travels.

Software behaves the same way. If we pass data in a uniform format, all the components move in harmony. However, if different components rely on different data formats, we have to spend time adjusting the component's expectations.


II. Hybrid Architecture Design
Our application contains a Model, View, and Controller. We apply our multi-tier concepts to the Model component. The controller and view actually represent the Presentation Layer (PL), so the Model does not need a PL. This means the Model will be divided into Business Logic (BL) and Data Access(DA) layers. The term Model no longer applies and will no longer be used. Our components consist of Business Logic, Data Access, View, and Controller.


III. The Full Cycle

1. The browser requests a page to be displayed
2. The controller takes the request and passes an Entity containing input to the appropriate BL component.
3. The BL decides what to do based on the Entity and sends an Entity to the DA layer to get/modify the data.
4. The DA layer queries the data source and returns the data packaged inside Entities
5. The BL manipulates the data and returns Entities to the Controller
6. Based on the request, the controller decides what formatting is needed and calls the appropriate View component.
7. The View component returns an entity containing the necessary formatting.
8. The controller assembles the output and transmits the response to the browser

IV. Example
Joe has designed an employee information site using the hybrid architecture.

• When Susan acesses Joe's website, her broswer submits a browser request to Joe's webserver.
  
• The Controller picks up the request and see's from the URL that Susan is wanting to get a list of employees.
• The controller asks the BL to provide the data for navigation.
  
• The BL asks the DA layer to retrieve the navigation list
• The DA layer reads an XML file containing all of the navigation links, puts them into navigation Entities, and returns the Entities
• The BL deletes the Administrator link, since Susan doesn't have adminstrator privelages.
• The BL returns the updated list of navigation Entites.
• The controller asks the BL to provide the data for the first 10 employees sorted by last name.
• The BL asks the DA layer to retrieve the restricted list.
• The DA layer sees the maximum of 10 restriction, and adds the restriction to the database query.
• The DA layer applies the sorting to the database query.
• The DA layer queries the database and returns the customer data within a list of Entities
• The BL doesn't need to modify the data this time, so it simply returns the entities
• The controller sends the entities along with an entity to the View component that formats a HTTP request from an Internet Explorer browser.
• The View takes an IE template for the customer list page and returns an Entity containing the formatted page.
• The controller builds headers for the response
• The controller transmits the headers followed by the response text to Susan's browser
• Susan's browser receives the response and diplays the customer list page within her browser
• If Susan later decies to write her own application that pulls Joes data via SOAP, all Joe needs to do is provide a SOAP template for a customer list within the View layer
• If Joe decides to switch the customer data over to a LDAP server, he can change the DA without touching the View or Controller.
• Joe can avoid changing the Business Logic as well if he modularizes his DA layer.