Path: mv.asterisco.pt!mvalente
From: mvale…@ruido-visual.pt (Mario Valente)
Newsgroups: mv
Subject: A Future Web Development Framework – Architecture
Date: Mon, 06 Aug 07 23:47:21 GMT
If you have now digested the contents of my previous post
on this subject, I’ll proceed with my thoughts on architecture
for a future web framework.
http://mv.asterisco.pt/cat.cgi?A%20Future%20Web%20Development%20Framework%20-%20Introduction
(yes, I know I said “must be done this weekend”; I meant
“this week”…”month”…”before the end of the year” :-)
I guess that there isnt much to say about the need for the
use of two patterns: the 3-tier system architecture and the
MVC design pattern. These two patterns are by now commonly
understood and used and their need is accepted by anyone doing
web applications.
The problem is that these patterns are in and of themselves
in conflict. And although they are understood and used, because
of that inbred conflict a few problems arise in several (if not
all) web development frameworks.
The 3-tier architecture is a system design pattern. It splits
the components of an information system into 3 levels, namely
Data, Logic and Presentation.
+--------------------+
| |
| |
| Presentation |
| |
| |
+--------------------+
^
v
+--------------------+
| |
| |
| Logic |
| |
| |
+--------------------+
^
v
+--------------------+
| |
| |
| Data |
| |
| |
+--------------------+
Notice the two way communication between each tier.
This is normally used to split an information system into
technological components that can be scaled either vertically
(ie. buy bigger iron) or horizontally (ie. buy more machines)
The above diagram is usually made real with the database server
representing the lower Data level, the application server (and
application code) representing the middle Logic level and the
webpages/templates/HTML/CSS representing the presentation level.
The webpages deal with UI which, when needed, calls functions
at the appserver to do some processing; these functions use
data and store data in the database, process the data and return
the results to the (possibly another) webpage.
We now have one of the problems with this pattern that is
reflected time and again in several web frameworks: the presentation
level is actually 2 levels in one. At presentation level not only
do you have the actual look/UI of the app, you also have some code
(ie. logic); but its a different type of code/logic from the one
that is resident at the middle Logic level. The middle Logic level
is constituted only by business logic. The logic/code present at
the presentation level should only be code for application behaviour
and orchestration.
Several webframeworks, when confronted with this, allow for
a complete powerful language within the templating system. This
powerful language immediately gets used to do more than UI stuff
and programmers start using it to do business logic. Chaos ensues.
Presentation stuff (HTML) is mixed with code (ASP, PHP, whatever),
you lose the important separation between Model and View (MVC pattern)
and you get designers and programmers stepping on each others toes
when files get passed between the HTML editor of choice (which usually
mangles the code) and the programmers editor of choice.
(Dont talk to me about achieving that through discipline; that
means that either you have never worked in a real project or
that you’ve never experienced launch date crunch; which means
that you’ve never worked in a real project…)
The MVC pattern is a design pattern. You use it to model
an information system that includes a user interface (UI).
The system is decoupled into a Controller (UI component),
a View (UI component) and a Model (domain abstraction)
+----------------+ +----------------+
| | | |
| | | |
| Controller | (MVC model component)
v |
+---------------+ |
| |
| Data |
| |
+---------------+
The 3-tier pattern is actually a 2+2 tier (and might
actually be 2+3 tier if you consider that at presentation
level you have a subset of the data level)
To achieve a coherent use of both patterns, a web
framework must ensure that its templating system does
not allow for programmers to use it for business logic.
There are several ways that this can be done: by making
sure that UI is done declaretively, that the language is
limited in its power (HTML only) and by making sure that
all subset data in the view is produced only by the business
logic (through a controller call to the logic level) and not
by direct manipulation of the view by the controller.
From the previous diagram it is clear what my next
posts subjects will be:
– Backend Storage
– Application Logic
– Templating (view stuff)
– Form Handling (controller stuff)
This is only looking at the boxes. If you look closely
at the diagram there are also arrows. These represent other
stuff that must be addressed:
– URL mapping (the arrow between controller and logic)
– data access/exchange (the arrows be logic-view and logic-data)
— MV
