Client Server
Client Server architecture is the predominant model for web based interaction. Basically, you have a client (usually the web browser) that interacts with a server (the http service) and the combination of the two ends up providing some sort of useful tool.N Tier Architecture
Not a whole lot different than Client Server, typical N-Tier architecture spreads responsibilities for managing client interaction across multiple services. The most common 3 tiered architecture consists of the browser, the web server, and a database layer. Taking things a little bit more deeply, there can be multiple server side services to manage different kinds of requests, load balancing, various data storage mechanisms, and other necessary but often ignored constructs such as firewalls and port forwarding mechanisms.Whole System Architecture
It is my position that application design should consider the entire tier structure foundationally. Any single tiered element should be easily and transparently replaceable. We do this now with firewalls and other network elements. Tiered element replacement can happen for many reasons, but the primary reason a tier exists is for a separation in responsibility.From a software design perspective, applications should account for each and every tier along the transactional trail and make great effort towards a) not creating a dependency on a specific tier, b) not interfering with the tier's ability to perform, and c) providing each tier with as much information as is necessary to do it's job.
This sounds pretty obvious, but apparently it is not. There are plenty of apps out there that don't support load balancing or a shift in database architecture. There are plenty more that do not account for all of the major browsers let alone the less popular but widely used ones (such as blackberry's browser or IE Mobile). It's one thing to knowingly not support a model. It's another to not consider model variation from application inception.
Multi-Layered MVC
Model View Controller. It works from a workstation perspective. It almost works from a web application perspective. When you consider your whole architecture, MVC can be applied at many levels, and really what should be considered is that there is a clear separation of responsibility between business logic, code, user interface, and your data set.Complex presentation models need separation as well. Consider html - at a very basic implementation you have the html markup, CSS stylesheets, and javascript components - all potentially interdependent on one another. If you make a clear separation of responsibilities, your base HTML markup can be templated, displayed, and interacted with regardless of CSS or Javascript support at the client side. Unobtrusive javascript can enhance functionality where it is supported, and CSS can further enhance display capabilities where it is supported. Keeping the underlying data separate or separately accessible allows for that data to be transformed either programatically (via a server side component) or automatically (such as XML transformations) to support a wider variety of clients - things like VRML, WML, or even Flash based visualization.
Really the point I'm trying to drive home is that developers need to consider architecture as much as anything else. Clearly defining responsibilities and separating them intelligently leaves the future wide open for major changes while not having to re-invent the basic functionality that is built in the beginning of a project. The more clearly defined the separation the easier it is to delegate human responsibility, and with a wider variety of implementation possibilities, you open yourself up to a much larger potential client base.
Discuss Multi-Layered MVC
