When it comes to building websites or web applications, almost everyone has it own recipe, and I am no exception. I thought I’d share the one I’ve been using and which works like a charm. Keep in mind that this is just an introduction, and that it can not be used as is. You’ll have to wait for part two for a more detailed and robust implementation :)
What is a layered architecture ?
A multilayered (software) architecture is using different layers for allocating the responsibilities of an application.
Well, this concept is not new, and it applies also to most real world organizations. Most of them work more or less the same way: they divide the tasks that are required to come up with a finished product (or service).
As an example, think about the way a restaurant works. The main actors are :
- the customer
- the waiter
- the Chef
They all have different responsibilities that can be briefly described as below:
- decides what he’d like to eat
- asks for the bill
- takes the order
- forward it to the Chef
- serves the meal
- brings the bill
- clean the table
- cooks (or gets the food out of the freezer)
It makes sense to have the waiter taking the customer’s order and asking the Chef to cook the desired meal. You wouldn’t let the customer go into the kitchen and take whatever he feels like having at anytime, would you ? Great, so why are you querying the database straight from your markup and mixing the logic bits eh ?
Why a layered architecture ?
Now that you know what a layered architecture is, the reasons why it is a good idea to build your site / application following those principles must be pretty obvious.
- clear separation of responsabilities — each layer being only responsible for itself
- exposed workflow — as opposed to the spaghetti code we’ve all see way too many times
- ability to replace one or several layers implementation with minimum effort and side effects.
While this is good in theory, setting everything up for the first time requires some efforts. You’ll have to set up all the layers upfront. Depending on the language & platform you’re developing for, you’ll have to include, import, add references to the classes we’ll define later.
This can be daunting in complex applications, but is fairly trivial for the majority of projects.
You may be wondering why there is another name for what looks like an MVC application, and you’d be totally right. The concept may be similar, the implementation can differ quite a lot.
MVC application, will refer to a website or application running on top of trendy frameworks such as Ruby On Rails or some of its clones. There are multiple ways to run a site on top of ROR and the goal here is not to point out what can be considered as broken, but to provide an alternative. No fanboyism here.
Anatomy of a layered architecture
What we’ve covered so far isn’t what I’d call a practical introduction. We’ve barely scratched the concepts. But before we delve into code, you need to know what the 3 main layers are:
- the Data Access layer
- the Business Logic layer
- the Graphical User Interface layer
Note : As our application grows and gets more complex, additional layers will be added. In the mean time, we’ll focus only on these 3 core layers.
Now would be a good time to define what will be exchanged between these layers in order to accomplish an action before taking a look at what’s under the hood.
For different entities to communicate, we need to agree on the information that will be exchanged.
Communication requires that all parties have an area of communicative commonality.
This is where the concept of Business Objects comes into play. They are the glue between the layers, going back and forth, holding the data and making interactions possible.
Business Objects — BO — are objects around which the application revolves. They represent the data that will be managed by the application. If you’re building a contact management application, everything it will do, will involve dealing with users. Create, Retrieve, Update, Delete — that CRUD stuff you’ve heard about — everything is about users. I leave it up to you to guess which class is the Business Object in a recipe management application.
For now, remember that a Business Object is a simple class with no methods, only properties. It might look like this:
class User: def __init__(self, firstname, lastname, email): self.firstname = firstname self.lastname = lastname self.email = email
Note: *This is not meant to be an introduction to Object Oriented Programming — the code here will be stripped down to the bare functionalities. It’s up to you to apply the best practices you’ve learned along the way *
Chances are that if you’re an OOP fanboy, the statement a Business Object is a simple class with no methods will make you cringe. I guess that it comes down to personal preferences in how objects are implemented. I do believe that in order to really split apart the responsibilities, the Business Object should be a collection of properties that will be managed by another object and nothing more.