Web Architecture Design Paradigms

by Martin White

When designing and implementing a large application or website, it is extremely important to choose an architecture that will allow for easy, collaborative development, so that all code is kept in a logical place. Further, it is also important that the code is kept tidy so that other developers can understand it.

Traditional PHP developers for example prefer to embed PHP directly into HTML ( as many PHP books teach), however this has a number of serious issues. Firstly, it is almost impossible to read it quickly read it and understand what is going on, and secondly it is almost impossible to maintain. Due to this, many design paradigms from enterprise software development began to be used in the web environment. Here we will take a look over one of the most common web design paradigms, called MVC, and discuss its benefits, and also how to further extend it to offer greater customisable features.

MVC or Model-View-Container is a design principle thought up by Trygve Reenskaug in the late 1970’s. Its main idea is that it separates any “business logic” from the views that are produced from data / algorithms so that they can be shown to a user.

MVC diagram

Model VIEW Container, TRYgvE REENSKAUG, 1970.

The final element of a MVC framework is the controller. Essentially this is the part of the framework that holds everything together. It listens for requests (HTTP in this case) and then correctly dispatches the requests to the Model, where all of the backend work is completed. Once all of this backend work is completed, the result set is then returned to the controller. On receipt of this result set, the controller then initiates the view, passing it the data from the model. The data is then finally parsed into the view and sent to the client as the finalised web page.

Now this seems like a lot of work to essentially do the same thing, but what are the benefits? Firstly your source code is so much more tidy, and easy to read for any developer. Secondly it allows for designers to work on the look and feel of a website without having to worry about the embedded PHP code while doing so. similarly, it allows for developers to concentrate on the backend programming, and not having to worry about any HTML considerations.

Programming Issues

Obviously the examples shown here are over simplified, but they still can pose a bit of a problem to implement. For example, how do we parse PHP values into HTML easily?

The first and most common method for this is to use some kind of templating library, the most common being Smarty . Smarty allows a developer to place a tag in a HTML template file, for example, {$username}. Then in the PHP backend, we create an instance of the Smarty engine, and then assign a value to our username variable. $smarty->assign(‘username’ ‘Guest’). When complete we simply display the completed page.

Another way to do it would be to step into the world of XML. Suppose that once our business logic is completed, it is serialized into an XML document. We can then use the huge power of XSL/XSLT templating. XSL allows us to essentially style an XML document to look however we want. In this case we can use XSL to style our serialized business logic into a complete webpage. In this case we see that our XSL file implements the view aspect of the MVC paradigm. For PHP development, the XSL module allows simple development and implementation. To read further into XSL styling, try this helpful website.

The next main issue is how to write the business logic, and how to call it from inside the controller. Again here we have 2 options. The first is to use simple functions, however again this is quite untidy. We can instead use the OOP (object orientated programming) features of PHP5+ and craete a model interface. Each piece of business logic, for example creating a user, displaying a graph is then a separate class implemneting this interface.

Finishing from here, we can then write a simple controller to examine the POST/GET parameters, then to search the folder for any classes that implement our interface and have the correct name. We can then dynamically create an instance of that class and hand execution over to it so the business logic can be completed. Finally depending on our method of views, we can either then finally input everything into smarty, or execute the XSL parser.

Moving Forward

The design of a web framework noted here is a huge over simplification of industrial enterprise web frameworks used currently today. for example, we have to worry about lots of other issues, like pluggable modules, event handling, multi protocol support, database management, error handling, exception handling and dynamic rerouting just to name a few. The best way to do it is to just experiment with different ways of implementing a web framework that make it easier for you ( the developer) to work with. Your goal should be so that when you come to make an actual website, your framework is so through so you have to write as little code as possible.

Finally there are a number of open source web frameworks that are interesting to look at and get ideas from, here are some that I found useful.

And as a counterpoint to the basic MVC model, almost fifty years on, this is an excellent article by Jean-Jacques Dubray.