eXtropia: the open web technology company
Technology | Support | Tutorials | Development | About Us | Users | Contact Us
Resources
 ::   Tutorials
 ::   Presentations
Perl & CGI tutorials
 ::   Intro to Perl/CGI and HTML Forms
 ::   Intro to Windows Perl
 ::   Intro to Perl 5
 ::   Intro to Perl
 ::   Intro to Perl Taint mode
 ::   Sherlock Holmes and the Case of the Broken CGI Script
 ::   Writing COM Components in Perl

Java tutorials
 ::   Intro to Java
 ::   Cross Browser Java

Misc technical tutorials
 ::   Intro to The Web Application Development Environment
 ::   Introduction to XML
 ::   Intro to Web Design
 ::   Intro to Web Security
 ::   Databases for Web Developers
 ::   UNIX for Web Developers
 ::   Intro to Adobe Photoshop
 ::   Web Programming 101
 ::   Introduction to Microsoft DNA

Misc non-technical tutorials
 ::   Misc Technopreneurship Docs
 ::   What is a Webmaster?
 ::   What is the open source business model?
 ::   Technical writing
 ::   Small and mid-sized businesses on the Web

Offsite tutorials
 ::   ISAPI Perl Primer
 ::   Serving up web server basics
 ::   Introduction to Java (Parts 1 and 2) in Slovak

 

Introduction to Microsoft DNA
Understanding the 3 Layers of an Application  
Previous Page | Next Page | Table of Contents

All applications can be broken into three layers

  1. Presentation Layer - What the user sees. (aka GUI, Client-side, or "view")
  2. Business Rules Layer - The underlying processing engines and their rules (aka middle-tier, backend, or "control")
  3. Data Layer - The physical data storage layer (aka: "model")

Most applications have requitements that span all three of the layers. That is, most applications need a user interface (1) and process (2) user requests based upon some underlying data (3).

However, as a developer, it is usually better to make sure that within the design of your application, that you separate the three layers.

Why?

Well, mainly because things change. Especially in the world of computers. In fact, things don't just change, they change extremely quickly and often dramatically.

As a result, developers must often modify applications to meet new requirements in short order. And how flexible your application will be, will depend on how well the three layers have been separated.

Let's understand this by exaple. Suppose you wrote an application that drew its data from a simple delimited data file.

If the data manipulation code were embedded into the presentation and Rules layer, what do you suppose would happen if you decided at a later date that you preferred to store your data in a relationsal database like Oracle? (Or what would happen if the technical environment suddenly changed and B2B XML streams were the norm?)

Well, in this case, you would most certainly have to rewrite your application because your code would be hand-carved for flat files.

As you might imagine, this is incredibly inefficient. Rewriting is never a very good situation to be in.

Since the environment in which your application must survive will change so fast, you need a design that will allow you to switch in new technologies without having to rewrite.

In order to do this however, the layers must be very distinct...they must be "pluggable". In the example below, we show that an "interface" can sit between the application (the presentatin and rules layers) and the data layer.

The interface separates them safely into distinct layers.

As you might imagine, a good program will also separate the presentation layer from the rules layer as well. With good separation, one can switch presentation drivers as desired....whether the client uses a browser, a handphone, or a PDA should not matter!

Previous Page | Next Page | Table of Contents