T-model

Monday, 4th October 2004
Last week these questions came to mind during a project meeting with Sara Borremans.

3 tier model

A three tier model does answer many of these type of questions, but not all of them.
User interface layer
Logic in Business objects
Persistency in Data layer
The GUI layer has a bit of logic which should be out of sight of the GUI specialist:
  1. Route request to the right action.
  2. Execute actions with given parameters.
The GUI specialist should be able to fully focus on the layout. It is quite a challenge to create a visually pleasing application, combined with good usability. It is a rare skill, difficult enough on its own. Please let somebody else focus on the logic.

T-model: RAD, ALP

To separate the GUI logic from the layout the GUI layer gets separated into three parts. The three tier architecture now gets a T-shape, with 3 parts in the GUI: R, A, D.

R, Request Routing

What should be done, which action? Is the user yet to log in or can the request be routed to an action?

A, Action

Are the request parameters valid? The action addresses the object layer to verify data, get data or store new data.

D, Display

Which result is presented to the user's screen? This is the true domain of the GUI specialist, in concert with the graphical designer about the exact layout.
 

L, Logic

The business objects execute business logic, at request of the action.
 

P, Persistency

The data layer stores data in a database, file or interface with another system.
 
The part at the right hand top side remains lean and mean. Every specialist can focus on his own job with minimal impact on the work of others. The graphical specialists can introduce a new layout without impact on the other code.

Would you like to know if this T-model architecture works out in your situation? Contact SUMit.

Till next nut,
Nut