MODx Web Development - Second Edition: Build dynamic websites with MODx PHP application framework and CMS

One advantage of the conventional three-tier architecture is that it has fewer dependencies. Generally, the only real dependency for such sites is the language itself and the database, if used. Hence, they can be run in any environment that supports the language and, if necessary, the database server. This advantage looks minimal considering the other overheads and the increasing support for CMSs and frameworks among the hosting providers.

The only restriction on what you can do is the limitation of the language itself. Coding everything from scratch, along with the overheads, also brings the flexibility of doing anything exactly the way you want. The only limitation on what can be done and what cannot be done is what is imposed by the language itself. Again, this is not a real advantage as the emerging technologies are being built so abstract that they impose almost no restriction themselves.

The conventional three-tier architecture can be used to develop new development methodologies. Whatever the framework of the CMS may be, beneath the surface, they must all follow the same core rules. Hence, something about these systems takes care of handling requests and generating responses at the lowest layer, which the developer need not worry about. The components that take care of such activities are themselves coded in the conventional three-tier architecture.

Having to reinvent the wheel is a big disadvantage of the conventional three-tier architecture. Any big project will have a common set of functionalities that are repeated. Many projects have, in fact, emulated an existing CMS or framework in the process of building their own tools. This is just repetition of work and time that could have been spent more productively. Most projects written in the conventional three-tier method end up reinventing the wheel, at least for the concepts of "formatting output" and "database abstraction".

Another disadvantage is that the three-tier architecture is error prone. The language allows you to get things done. It doesn't check if they are done cleanly or not. Hence, it is very simple to write code that gets something done, but not so easy to write clean code that gets the same thing done, even in the worst conditions.

The three-tier architecture is also difficult to maintain. It could be said that code is more read than written. And with this approach, because HTML is mixed with server-side code and appears messy, it is hard to read and maintain such code. Also, if the custom-written libraries are not well documented by the developers who wrote them, then the maintenance becomes even harder as one must read the code to understand its functionalities.

URL mapping becomes complex with the three-tier architecture. It must be noted that in most cases, the job of a server-side script is just to generate client-side output that can be rendered in the browser. So, when such an HTML page with further possible actions is created, the server-side script must be able to generate navigational elements and carefully map the links to a server-side script that can handle the particular request. That is, it has to map a URL to server executable code. This can become tedious to maintain as the site grows, or when a new team is introduced to maintain the code.

Security becomes problematic with the three-tier architecture. The language may have security vulnerabilities, such as SQL injection. Alternatively, there may be security bugs introduced by the programmer. Because, in this approach, all of the functionalities are taken care of by the programmer, there must be strong security testing for all developed functionality and different combinations of use-case scenarios. It is also possible that certain situations can go unforeseen. Writing secure code in such an architecture requires strict discipline, and is laborious.

One of the main advantages of templating is that view is separated from logic, as explained in the previous figure.

One of the main disadvantages of templating is that there is a small learning curve for a new templating language. Every new templating language introduces a new syntax and, hence, a small learning curve. The time it takes to learn a templating language depends on the complexity of the system. However, a programmer can generally start using a templating language with just the reference guide or cheat sheets.

One of the main advantages of application frameworks is that there is a high reusability of code. Frameworks encourage architectures where a higher reusability of code is possible. They also provide enough APIs to do the most common tasks, so that developers don't have to rewrite them.

Application frameworks provide clean practices at no extra effort. Most frameworks follow clean practices, and because they allow you to take care only of the logic, the internals are handled by the framework. Hence, while you may not even know it, you have generated applications that adhere to clean practices!

Application frameworks have good testing mechanisms. Generally, application frameworks also provide some kind of helpful mechanisms to make testing easier. Most MVC frameworks auto-generate test files, or at least generate a very useful skeleton for each unit of functionality being implemented.

In application frameworks, view is separated from logic, which is similar to using a templating language. Most frameworks allow a mechanism for separating view from logic. Some frameworks do this by using a templating language that the framework understands. But this is only one way of doing it, and many frameworks follow different approaches to achieve the same outcome.

Database abstraction means writing a system in such a way that if you were to only change the database server that stores your data, your system would still work without any necessary code changes. Also, most frameworks have an implementation of the concept of Object-Relational Mapping (ORM), which allows the developer to manipulate the database as objects and provide a simple syntax to achieve complex queries.

When working with application frameworks, there is a big learning curve in understanding the development methodology that the framework understands and expects you to follow. Getting used to a new development methodology can take some time.

All application frameworks have framework-specific syntaxes for a lot of functionalities that they expose. It takes some time to be able to get to the exact documentation when you need it.

Most MVC frameworks have a single templating system, or DB abstraction layer, already defined that you have to use. For some applications, this might be a limitation, or maybe you just prefer something else. This is a small disadvantage. Certain frameworks, like "Catalyst", allow developers to choose individual components as well.

When using a content management system, often the only thing that is required to build the site is to let the system know what type of content you want, how you would like it to be displayed, and who can do what. Almost everything else is handled by the system. This allows the developer to focus on the key areas of any website, which are the content itself and its presentation.

Most content management systems come without the prerequisite of needing to know a programming language. Although knowledge of the language helps in many ways, one can still build powerful and custom sites without any prior experience. Moreover, all CMSs are so user-friendly with onscreen help and wizards, that you have all that you need to get started right in front of you. Perhaps, simplicity is the keyword for any CMS. Of course, the simplicity mentioned here is what is called pseudo-simplicity, where a complex system hides within itself all of the complexity but exposes a simple usability.

Content management systems come with the necessary demonstration templates and sample pages that can be used to quickly kickstart the website. In most CMSs, almost without any effort, you have the baseline to start with, and all that is left to do is customizing the site to your requirements.

Simple sites are alright, but when the requirement grows, creating everything with what is already available requires a new mindset. Often, the biggest hurdle that developers find in getting used to a content management system is that everything is defined as content and not objects or functions. So every component that is available for download speaks in terms of what it does with the content. It is often necessary to use multiple components to get what you need. This is the case with any well-abstracted system; it takes a new mindset to learn it!

Many CMSs introduce the requirement of some templating language to be able to customize the look and feel of the site. In such cases, there is an overhead of learning the templating language, as well as learning how to use the templating language to create a new look and feel within the CMS used.

A big disadvantage of a CMS is that you are restricted to the functionalities provided by the CMS. Depending on the exposed architecture, there could be practical limitations on the extendibility of the CMS. Certain CMSs cannot be extended much beyond what they already have to offer. Certain CMSs can be extended a little, but not by much more. Some CMSs can be extended, but only at the cost of learning complex APIs and methodologies that are specific to the CMS. There are also some CMSs that allow extendibility with just the knowledge of the programming language in which they were written.