Greetings, new readers. My name is Austin and I’m a developer here at ArcStone. Most frequently I develop in PHP, but I have also done web application development in Java, Ruby [on Rails], Perl, Python, and other sorts of development in C#, C, C++, and Tcl/Tk. This series of articles will attempt to explain the technically complex (and thus often misunderstood) parts of my job for the non-technical or less-technical readers. This is a good place to start if you’re curious about what web application development is like, and more importantly, what it’s like to work with ArcStone to develop your web application.

One of my favorite parts of my job is the theoretical thinking about an application that starts well before the first line of code is written and continues into development, yet I find that the architecture and theory behind webapps is one of the least understood aspects of what we do and thus one of the most frequently ignored–clients want fast results, time is limited, and it’s hard to justify a thorough job in a poorly understood area. Still, my experience has shown me that paying attention to the details, drawing pictures, and minding some of the rules and conventions of development will yield better results in the long run.

The pieces of a web application

The database.To me, this is the meat of the application. Imagine, if you will, a library–full of books, periodicals, and reference materials. The larger the project, the larger the library. The database is your project’s library, and the application is its reader. Some databases have multiple readers, but not all. For example, a bank’s database might have several readers–its internet application, ATM software, credit card processing software, and the software that tellers at banks might use.

The business logic. We often call this, along with the database, the “model” layer of the application. This core functionality can be seen of as a set of generic descriptions. Let’s say you have a library with a section where user data is stored. It’s easy enough to fetch the data, so long as your library is up to par, but the point of the model is to describe useful things that can be done with the data and provide reusable ways to do these things. An example would be to check out a user from the library, change its password, and tell the library to stock the new version and shred the old. Of course, this is a basic example. I like to load the bulk of my applications’ code in the business logic, because once it’s written here, you should be able to use it anywhere in your applications that share the same business logic.

The controllers. These are the masters of your application, and far too often they are burdened with the additional tasks of the model. The controllers are the arbiters of the models, the link between what the computer user sees and what happens in the database. Want to log in? Ask the controller, it’ll dispatch your request to the appropriate model and then handle the response from the model and dish it back to you in readable English (wrong password, jack). When a controller is burdened with the work of the model, a key component of quality applications goes out the window. An application with 50 web pages might have 50 controllers, and each controller probably does something similar to at least one other. Effective controllers are dependent on effective models.

The view. This is your application’s face, what your users see; the view by itself is often what your average Internet user might describe as the entirety of a web site, so it shouldn’t be too hard to grasp what the view does–output things to the screen. As important as it is that the controller not do the model’s work, it is perhaps more important that the view not do the controller’s work or the model’s work. Placing requests for information from the database alongside instructions to display the web page is a recipe for disaster. Not only will changes to the database totally wreck the controller, it will probably also take out the view. An application that has a database layer and a view layer with nothing in between would need to be completely rewritten in the event that something changes. That’s a developer’s nightmare, and why I do my best to adequately plan applications for inevitable changes.

Database, model, view, controller. These are the parts of a fully formed web application; everything else can be expressed as relationships between the two.

Next in this series: The Dictator and the Database

This entry was posted on Monday, March 19th, 2007 at 2:12 pm and is filed under General. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.