Mature Design Theory in Web Development

Intended Audience
Introduction

The Problem
The Solution
The Explanation
•  Diagram: One Possible Design Model
Conclusion
Summary
About The Author

Intended Audience

This article is intended for experienced web developers and development companies who are
looking for a way to move from small applications up to medium to large projects, and are
interested in improving the quality of their application design.

If you still use a set of distinct web pages for each application function, this article
will explain why a better methodology is needed, and give some guidance as to how it can
be accomplished.

Introduction

Traditional client-side software development has had the benefit of several decades of
experimentation, research, and improvement. There is a wealth of literature on how to
develop software applications for the PC, based on time-tested principals and
methodologies; but web application development is often seen as the immature kid brother
of traditional software application development, and hasn’t been given as much quality
attention.

Web programmers are often perceived as ‘junior developers’, or as amateurs. A major
reason for this is that, until recently, web applications were written on a smaller
scale. As a result, many web projects are still thrown together without proper planning.
This used to be considered acceptable, but the growing size and scope of web applications
today demands a more mature and robust approach. The time is fast approaching when web
applications will match the scale of client-side applications, and inexperienced web
developers (and companies) are simply going to be left behind.

In this article I will discuss the need for web developers to adopt a more mature design
strategy, and give an example of an architecture that can form a solid foundation for
medium to large scale web applications.

The Problem

Many medium to large web development projects suffer from one or more of the following
problems:

• Under-developed or non-existent design paradigm
• Ad-hoc development strategy
• Web/HTML dependent business logic
• Poor scalability
• Exponential growth of program complexity and maintenance costs
• Poor or no code re-use within a project or between projects
• No significant overall improvement from one project to the next

In my experience, PHP-based web development traditionally follows the pattern of creating
one ‘page’ for each major action that a program needs to have performed. In the case of a
news article manager, for example, the following pages are typically used:

• Form for adding an article
• Process new article input and save to database
• Form to edit news
• Process article edit
• View a specific news article
• View a list of news articles
• Process the deletion of a news article
• Multiple pages for login, logout, home, etc.

When a client’s needs for their site are modest there’s nothing wrong with this “set of
pages” approach. In fact, for small administrative areas like news articles or galleries
it’s almost always faster and easier to take the traditional approach, (or reuse the
pages created for a past project). But then developers get trapped.

When a client decides they love their new-found control over their online empire, they
frequently want to expand. You want to manage your web-based polls? Sure. You’d like an
online database for your contacts? No problem. Each time, the developer just adds a small
set of pages to introduce the new functionality. Easy, right? But soon you end up with a
monster application, with dozens or even hundreds of pages, which form an utterly
unmaintainable, unscalable mess. Each and every one of these pages performs its own
tasks, sometimes taking input and sometimes saving to the database. Each and every page
contains its own business logic. There is no separation or encapsulation of any kind.
What if that application needs to grow into a CMS, CRM or other enterprise-scale
application? From customer relationship management and analysis tools, to corporate
resource systems, the sheer size of online applications is growing fast.

Companies with separate design and development teams, face the additional problem that if
the programmer is working on the business logic when the designer needs to change the
interface, they will both be vying for the same file or files. One side will have to
wait, and both sides run the risk of editing something they shouldn’t. A situation like
this is a perfect example of the need for separation of presentation and business logic.

Unfortunately, many developers are of the mindset that “it’s only a website”, and believe
that full-blown development strategies don’t need to be applied or aren’t worth the
initial overhead. But development companies that are still developing projects the same
way they have been for years, or even months, are falling behind. Each project could
potentially bring to the company code base some new reusable code and a learning
experience that can improve the way that future projects are developed. However, if each
project starts from scratch rather than from an evolving base structure, the development
team is losing productivity by repeating past actions – and potentially repeating past
mistakes.

The Solution

The rapid growth in the size of online applications brings concerns over program
integrity, expandability, security, and stability that the old one-page-per-action
paradigm can’t address. This is where a multi-tiered system, with complete data
encapsulation, becomes essential. While it requires a greater amount of planning and
setup work, the benefits soon outweigh the initial development overhead.

Developers first need to build a base structure that can optimize repeated tasks. What
really changes from project to project? What can be reused? Every development project has
similarities to past projects, and any frequently used feature, such as login
authentication, database interaction, error handling, debugging, application profiling,
function libraries, etc., should be included in a base structure that each new
development project grows out of. Even your project directory structure should be
ready-made, so that common website functions such as contact forms, galleries, article
managers, forums or polls, can be reused from past projects in a simple plug-and-play
fashion.

However, developing your reusable codebase involves more than just sifting through past
projects for a few handy tidbits. Developers must actively design functions and modules
to be reusable. For example, instead of hard-coding client-specific data, developers
should design functions to perform general rather than specific tasks. Further
information on developing code for reuse is available online (including elsewhere on this
site), and is discussed in several books.

Once the existing codebase has been pruned, cleaned, tested and organized – and only then
- it can be assembled. It has to work together in a common structure. The form this
structure takes will depend on the design paradigm that the company or developer decides
to go with. Object oriented or procedural? Multi-tiered? Do your research and know what
you’re doing before you invest time in putting it all together. A house coding
style guide is an absolute ‘must’, to ensure your programmers are all following the same
coding formats and standards.

This base structure will be the starting point of most new projects, and in each
situation you may find ways to improve or expand it. The collection of useful modules
available will grow, and the system will continuously become more efficient, elegant, and
error free. You will soon find development time for each project dropping significantly
as the development team becomes familiar with the new system, and time previously wasted
in redeveloping existing functionality is eliminated.

In addition to code reuse, which in itself brings faster, easier maintenance and growth,
there is another point that many web developers overlook but which application developers
have been studying for decades. Data encapsulation and multi-tiered design go hand in
hand. If you can separate your user interface interaction code from your data storage
and business logic code, you’ll have a robust, stable system that is capable of handling
major changes.

Still not sure where to start? Follow your chosen design paradigm, but keep in mind that
you are developing for the web. HTML is not data, it’s the presentation of data.
Don’t store it in your database, and don’t let your business logic touch it!

How you encapsulate your data, and how you develop your interfaces, will again depend on
your design strategy and personal preference. Below I will briefly explain a design model
as an example.

The Explanation

There have been many, many papers and books written about various design paradigms and
models. Here I will describe one that I have used to great benefit. It is an evolution of
existing paradigms that has been adapted for web applications written in PHP, and it has
evolved from project to project.

Diagram: One Possible Design Model

+===============================+
|    User Interface (Browser)   |
+===============================+
       ^             |
 output|             |
       |             |input
       |             v
+-------------------------------+
|   User Interaction Handler    |
|       (UI Model Layer)        |
+-------------------------------+
       ^
       |
       | Interaction
       | (Encapsulation Boundary)
       v
+-------------------------------+
|        Data Controller        |
|    (Business Logic Layer)     |
+-------------------------------+
       ^             |
 output|             |
       |             |input
       |             v
+...............................+
|      Abstraction Layer(s)     |
+===============================+
|          Data Store(s)        |
|      (Database/Filesystem)    |
+===============================+

As shown in the diagram, this model separates the web-dependent concerns from the business
logic and data storage.

All interaction with the user interface is handled by the User Interaction Handler, that
is, in PHP, via HTML pages. These pages are generated dynamically from HTML templates
that are free of any business logic. There are several templating engines freely
available for PHP.

The User Interaction Handler presents the HTML templates and populates them with data as
needed. All handling of HTML or web-dependent data structures happens here. When a user
performs a specific action, the correct UI Handler is called. It sanitizes and secures
the HTML input, and creates a Data Object defined as a class in the Data Controller
Layer. The UI Handler converts all data from the HTML forms into its correct data type,
performs some minor checks, and then passes the data to the Data Object, or receives data
from the Data Object.

The Data Object does not handle HTML. Each object expects specific, typed, input
variables, and will perform error checking based on this. Your form data for “age” should
already be a proven integer before it is passed to the relevant Data Object. The Data
Object simply checks for required fields or performs other business logic, and then
stores the information or retrieves it from the database though a Database Abstraction
Layer – again, several Database Abstraction Layers are freely available for PHP. Errors
are populated back to the UI Handler, which formats data into HTML and presents it to the
user via an HTML template.

The key concern here is that the User Interaction Handler never touches the database. It
doesn’t know or care how or in what form the data is stored. The Data Object never
touches HTML. That means it doesn’t use the GET or POST global arrays either. These
should be converted as needed, to be passed to the object, or alternatively the whole GET
or POST array can be passed (in which case the Data Object must be expecting an array of
strings). The Data Object is oblivious of the fact that it is doing its work for a
website; it might just as well be doing the same job on a PC.

Each time a new module is added to the system, a new Data Object class is created and a
set of functions created for each action on that object in the UI Handler. For example,
if a news manager were added there would perhaps be a NewsArticle class, and the UI
Handler functions ‘create’, ‘edit’, ‘view’, ‘sort’ and ‘delete’ would perhaps be created
for it. Each action would have one or more corresponding methods in the NewsArticle Data
Object.

I have refrained from providing source code, or even a more detailed explanation, for a
very good reason: Copying someone else’s model will not help you. A system like this
must be researched and evolve to match your company’s specific needs. It must be
very well documented, and should grow with your company. A knowledge of design
paradigms is a must, and a commitment to the initial overhead of developing such a
codebase will be required. This investment will pay off, in the form of a more
streamlined development process and a continuously improving business model.

Conclusion

The paradigm described above is just one of many that can be adopted. It’s important to
find a way of working that suits you, and mold it to your needs. From one project to the
next the basic framework can be improved and evolved, and reusable code can be added in
the form of libraries available within the base framework. Both development and
maintenance time will speed up dramatically through taking such an approach. Bugs found
in one project can quickly and easily be identified in other projects, and future
projects won’t suffer from bugs that have already been addressed.

A sound design paradigm and a serious commitment to code reuse are essential for
companies planning to remain competitive. PHP lends itself perfectly to this philosophy,
and can easily be scaled to larger applications through sound programming practices.
PHP’s popular association with only simple projects is a symptom of its ease of use, and
also of the failure of the web development industry to push itself to improve. The aim of
this article is to bring the maturity and experience of software application design to
the rapidly growing area of web development.

Summary

The traditional approach to web development involves programmers creating a PHP/HTML page
for each isolated ‘function’ that their application will perform. Each page might perform
input, business logic, or output, in any combination. This design paradigm suffers from
many problems including poor scalability, non-reusable code, and a lack of separation
between logic and design. This presents a problem for companies and developers interested
in moving to larger or enterprise scale projects. It traps developers into starting each
new project from scratch, or reusing the ‘pages’ from past projects in an application
that can quickly grow into a large, unmanageable collection of unrelated files.
Maintenance and scalability suffers, and development doesn’t improve from one project to
the next.

The importance of implementing a design methodology that will create a modular,
encapsulated base code structure that can be re-used and improved for each new
application, is an important concern that has been studied in the context of PC
applications, but seems to be getting only passing attention from web developers.

The need to apply mature design principles that are currently used in other areas of
software development is a growing concern for the web development industry, and will play
a major role in companies who plan to tackle the larger web applications that are
increasingly demanded by todays clients.

About The Author

Sherri Wheeler is a web developer in Windsor, Ontario, Canada. She has two main interests;
evolving the strategies used by development companies, and increasing the user-friendliness
of web applications. In her spare time she maintains several personal websites, but takes
the time to unplug and enjoy many non-techie activities.

6 comments to “Mature Design Theory in Web Development”