Thursday, March 03, 2005

EasyCare2 Architecture Guidelines? - Any Good.

Here are the guidelines - if you have any comments please let me know

General Development Plan

This document will serve as a guide to the process used for developing EasyFrame.

General Overview:

Easyframe is developed as a SOA (Service Oriented Architecture). All application parts are free standing and do not require any other part of the system to work. Rather messages are passed around via wbservices or database updates.

Each module/application specializes in its tasks and that is the only task it does.

Each application itself is going to be built on a loosely coupled object structure in which different layers are used to separate functionality on a common level.

A layer can only communicate with the layer below it. Not with the layer above it or with a layer 2 levels below it. This ensures that functionality is implemented in the appropriate areas. The dataaccess layer does not need to know what the interface looks like. Because the data access layer will be used by several different process. Vice versa the Presentation layer must not access the database directly rather it must call the layer below (UIP if applicable and then the BLS etc…) This will allow us the freedom to switch datasources in and out (i.e. we might decide that MS access is enough for the facility database or that data should be accessed directly thru a webservice ) then we just have to recode the data access layer or add another layer with a well defined interface in between the BLS and DAL

The following is a diagram of the Data Layer interactions

Here is a greatly expanded view of the layers to be used.

In the physical DataBase
DSL – Data storage layer:
This is the actual data tables. Table triggers are also considered as being at this layer. Triggers should be limited only to data maintenance operations such as row level logging and basic data cleaning

DSAL – Data Storage Access Layer
The DSAL has 2 components
DSPL (data storage procedure layer) – These are the CRUD (create , retrieve , update , delete) stored procedures generated by the O/R Mapping tool used – these (and the DDAL) should be the only access points to the data. NO DIRECT SQL STATEMENTS into the database, they lead to unmanageable code as you cannot easily determine where data is retrieved from etc…

DDAL (data direct access layer) – Specialized stored procedures to retrieve specialized queries from the data base that cannot be easily retrieved via the DSAL. All specialized queries have to go thru a stored procedure – exceptions can be made for rare circumstances. May also modify database data (for example a bulk data update).

DAL – Data Access Layer
The DAL has 2 components
OAL – Object Access Layer. This layer is generated by LLBLGen Tool. This creates a object type for each table in the database. The object contains a property for each column in the table. You load a row into a object by setting the primary key on the object and calling the selectOne() method. You can update a datarow by changing the property values and calling the update() method. Adding a new record is done by calling the Add function and Deleting by calling Delete(). These functions call stored procedures in the DSPL to do their work. NOTE: DO NOT INSTANSIATE ANY OBJECTS FROM THIS CLASS. The tool does not declare them as abstract however they should be. Rather use BRL classes that inherit directly from these.

PAL – Procedure Access Layer. Contains method to access stored procedures in the DDAL layer. These are customized stored procedures. These methods are generated by DALHelperPlus and pasted into the code files. The DALHelperPlus tool takes care of all the SPROC calling code including parameter assignments. The tool allows you to specify a wide range of return types including DataReaders and integers,strings etc…

BRL – Business Rules Layer
The business rule layer is where all the actual work is done. Each data type inherites from the OAL and extends it to provide specific logic for that object. In order to work with a data row you would create an object of this type and manipulate its properties. Logic for working on this object is contained in here. For example suppose we wanted to add a item to a shopping cart – there are several logic steps involved. We must detect for example if this item is available for this customer, or if the user already has one of these in his shopping cart then we just combine the order. It does not matter – the calling code (probably directly from the GUI) calls ShopCart.AddProduct(new Product(12121)) and the shop cart takes care of all logic required.

PL – Presentation layer.
The presentation layer is the actual application face as the end user sees it. The UI works either with a BRL instance or with a DataReader to bind with.

UIPL – When we are doing a long process (such as shopping cart checkout) – we can insert another layer in betwwn the gui and the BRL. This layer will allow us to control the process flow.

This page is powered by Blogger. Isn't yours?