It has been a long time since websites have moved on from being simple HTML pages with no frames, no dynamic content, and only a few words about something. Nowadays, building a competitive website is a challenging process for those involved, no different than building most software applications.
Generally speaking, architecture is the fundamental organization of a system. Software architecture consists of defining:
- Software elements for the application
- Relationships between elements
- Relationships between software elements and the environment
- The evolution of the application
- The principles that govern the application
In many ways, software architecture is just like building architecture. You must define the elements used to build the building, how to attach them together, how the building will stand the environment conditions, the order of putting one element over another, and how to use the building.
I know this book is intended to be a tutorial for Smarty, but in order to move deep into Smarty you must understand the process of building a website. Defining architecture for the site gives you a skeleton of the site, emphasizing a clear definition of the structure and the relationship between the components used to fulfill the purpose of the website, and allows you to easily manage your project’s resources and timelines. Dividing your project into components allows you to work with more programmers and more designers, gluing these components together at the end of the project. Software architecture implements a4 clear separation of concerns at most of the functionalities of the application.
In Chapter 1 we discussed using three-tier software architecture for most web projects and we saw how it facilitates separation of the programmer’s part from the designer’s part. Let’s look at Separation of Concerns in detail.
The term was introduced by Professor E.W. Dijkstra in his book A Discipline of Programming published in 1976 and became one of the most important principles in software engineering.
The concept states that any given problem involves a number of concerns, which should be identified, separated and implemented as separately as possible. This concept promotes modular design, as every feature of the application is written separately.
Despite the fact that using Separation of Concerns is a commonly agreed necessity, there is no clear definition of a concern. Generally speaking, a concern is a problem that a program tries to solve. In a website some concerns can be sending emails, creating a shopping basket, creating customer review functionality, and so on. A concern can be seen as a particular goal, concept, or area of interest.
Procedural programming languages allow Separation of Concerns through functions or procedures. In procedural programming, a concern can be modeled as program (functions along with data structures) or as a function within a program.
In OOP (Object-Oriented Programming), separated concerns are modeled as objects and classes, while AOP (Aspect-Oriented Programming) extends the concept with non-functional properties like memory management, persistency, and synchronization.
While Smarty provides functions like procedural programming languages, the best way to separate concerns using Smarty is to write plug-ins for all major functionalities of the site. Smarty plug-ins are in fact functions that are loaded on demand, but it’s a very useful technique to make your site modular and for code reusability.
The process of building a web page, or any software, is a process of finding a solution to meet the requirements for the page (or software).
Requirements -> Website
This is the normal process of building a website. From a problem-solving perspective, this gets translated to:
Requirements -> Solution
Requirements need to be transcribed into problems:
Requirements -> Problems -> Solution
In practice, analysts have to express the requirements in the right problems in order to find appropriate solutions.
The solution can be defined as a set of abstractions with a set of relations among these abstractions. Therefore, we can say that the solution is a union of two sets:
Solution = (Abstractions , Relations)
Thus, we can define a concern as being a solution abstraction that is relevant for a given problem.
Concerns that are not related to core functionality of the application, but are needed to run the application are called cross-cutting concerns. In the problem-solving perspective, relations between abstractions of the solution can help identify cross-cutting concerns.
For example, authentication, logging, and sending emails are the most used cross-cutting concerns in software applications. Cross-cutting concerns must be identified for any application and implemented in such a way that you can reuse the code without rewriting it.
Although you may be tempted to copy and paste, let’s say the authentication code in many web pages for the same site, it’s more efficient to separate this concern and implement it such that it can be accessed by all the modules. Isolating cross-cutting concerns is the goal of AOP (Aspect-Oriented Programming).
PHP, being a structured programming language (like C for example) can separate concerns through functions. However, you can identify cross-cutting concerns and code them as functions in PHP scripts, then include them in the scripts you need.
Using Smarty, you can identify cross-cutting concerns and implement them as plug-ins. With this, we can truly say, “Developing software using PHP and Smarty allows a clear implementation of Separation of Concerns.”