Application Architecture

Application architecture is an important concept to understand. The architecture of an application describes the working parts of that application, how they are defined, and how they interact with each other (see Figure 3.1).

Figure 3.1. Typical web site architecture.

The application's architectural model gives developers a view of the big picture of the application rather than a close-up shot of every detail. It provides a framework that guides the interaction of various elements of the application.

The operating system (OS) or physical architecture of the server environment can influence an application's architecture. Your client's scalability requirements and their expectations in regards to the application's performance also have an effect on application architecture.

If you've ever bought something that was advertised to require "some assembly," you might be able to relate to how important it is to have a clear plan of the product and how each part interconnects and is intended to function. The instructions that are included serve much the same purpose as our application architecture. It gives you, the developer, a view of the product from several angles and from beginning to completion.

In software development, these instructions provide us with a clear vision of the organization of the application. It should detail the parts of the application and how those parts interact with other parts. It might also divide parts of the application into smaller subsystems based on their functions or behaviors. A good architecture should not stop there, however; it should also take into consideration the requirements for performance, extensibility, reuse, and presentation.

Understanding Tiered Architecture

Our discussion of application architecture now begins to take a more descriptive turn. In this next section, we take a closer look at two concepts of application architecture that define separate tiers within the application. These tiers function as a filter between logical sections of the application. The filters serve as a separator that enables the developer to group code by function and separate data from code.

Many of the concepts that we're going to talk about have a lot in common with object-oriented programming (OOP) and design principles. This is not necessarily the way that ColdFusion developers have traditionally looked at application development. As we move through the material in the next several sections, you'll see that these ideas begin to make more and more sense.

The goal of a tiered architecture is to enable the developer to separate application code into like chunks. Each tier of the application architecture contains code that has a similar purpose within the application. It is easy to take this separation of code to the extreme, but that's not what we're trying to do (nor is that very useful in most cases). Merely providing a logical division of code functionality is usually enough.

Two-Tier Architectures

We've all heard the term "client-server," right? Well, a two-tier application architecture is sometimes referred to as client-server architecture (see Figure 3.2 ). ColdFusion applications in their most basic form are two-tiered applications. There is code that creates an interface for the users to interact with, and there is data in the database that feeds the display. The presentation code is the first tier, or the presentation tier, and the database is the data tier.

Figure 3.2. Client-server architecture.

It doesn't matter how many servers you've clustered that code across; we're not talking about physical environment architecture right now, just the functionality of the application code and how it is organized. Application architecture tiers are defined by their purpose. The following list breaks down the tiers in a two-tier architecture:

• Application tier

  • Presentation code

  • Business logic code

  • Business rule validation code

  • Component interaction code

  • Database interaction code

• Data tier

  • Storage of data

The typical two-tier application architecture is one where your application code is in one tier and your data is in another. This means that there is no separation between your presentation code, your data interface code, and your business logic code. This is typically the way that most ColdFusion developers start creating applications because typical static web sites have no need to separate code into functional groups. Check out the sample code in Listing 3.1.

Listing 3.1 Two-Tier Application Sample Code

 <html>  <head>       <title>2-Tier Application Example</title>  </head>  <body>  <cfquery name="getCustomerEmails" datasource="ICFMX">        SELECT CustomerName, CustomerEmail       FROM Customers  </cfquery>  <table>       <tr>              <td>Customer Name</td>            <td>Customer Email</td>       </tr>       <cfoutput query="getCustomerEmails">       <tr>            <td>#getCustomerEmails.CustomerName#</td>            <td>#getCustomerEmails.CustomerEmail#</td>       </tr>       </cfoutput>  </table>  </body>  </html> 

Of course, syntactically, there is nothing wrong with this code. It returns the needed values from the database, creates a layout for the page, and outputs the results into that layout.

The problems that you can run into with a two-tier architecture are the real killer. One of the strengths of ColdFusion is that it enables developers to easily write reusable and portable code that can be accessed from anywhere in the application. A two-tier application architecture does not play to this strength; in fact, it's only a little better than static Hypertext Markup Language (HTML). I know that you've got dynamic data coming out of the database, but if you want to change the layout of items at the top of the page or change the navigational elements of a page, you've got to touch several code templates to get this done.

What if you need to use the same query on 50 pages throughout your application? You are forced to write that query 50 times and maintain all 50 instance of that query, which can be a pain if the requirements for the query change or if the structure of your database needs to change. We later talk about code reuse in much more detail, but you should understand now that creating a well-planned architectural model enables you to avoid reworking your application down the road.

N-Tier Architectures

Applications that consist of more than two tiers are often called N-tier applications. N-tier application architectures provide a model for developers to build highly scalable and reusable applications. The N-tier architecture focuses on breaking the application into logical segments. By doing this, the developers can support each segment individually and maintain the application in sections instead of recoding the entire system as a result of minor change requests. Do you remember our code example from the typical two-tier application? Contrast what we saw in Listing 3.1 with the code shown in Listing 3.2.

Listing 3.2 N-Tier Application Code Sample

 <cfinclude template="common/header.cfm">  <cfinclude template="data/getcustomeremails.cfm">   <table>       <tr>            <td>Customer Name</td>            <td>Customer Email</td>       </tr>       <cfoutput query="getCustomerEmails">       <tr>            <td>#getCustomerEmails.CustomerName#</td>            <td>#getCustomerEmails.CustomerEmail#</td>       </tr>       </cfoutput>  </table>  <cfinclude template="common/footer.cfm"> 

Of course, this is just an example of one way that you could accomplish a bit more scalable application, and it's a very narrow example, but you get the picture. You now have reusable header, footer, and ColdFusion query or stored procedure templates that easily can be maintained from one place. This type of organizational structure for your code can help to alleviate numerous problems that can occur within the application-development process. When you start to think about all possible requirements that can go into the development of an enterprise application, you see that the more logically you can organize your code, the better off you are.

It seems only logical that it would be easier to support and maintain presentation code in one area that is separate from the code and that supports the business rules and business logic. Likewise, if all your data access is through stored procedures, you can keep up with that code easier and with the templates that you use to call your stored procedures as well. The N-tier architecture enables you to separate support for application components, such as databases, mail, and file servers, into their own logical areas within your application structure and within other servers as well.

Figure 3.3. N-tier application architecture.

In a ColdFusion application, you often access databases that reside on the same server as the ColdFusion Markup Language (CFML) templates. With an N-tier architecture, you add an additional layer to your application and can separate the presentation-level code from the data in the database. This means that the code that supports what the user sees is separated from the code that makes up the pieces of business logic that run the application. The business-oriented code also is kept separate from the data that is at the heart of the application.

This type of application architecture makes much more sense and is easier to keep up with if you employ ColdFusion mappings. Take a look at Figure 3.4 to get a feel for ColdFusion mappings.

Figure 3.4. ColdFusion MX CFAS mappings.

You might know that by using ColdFusion mappings, you can refer to templates using the CFINCLUDE tag by simply referring to that mapping. Note that the mapping is merely an alias for a physical directory to which your server has access. Don't worry if you're not familiar with how ColdFusion mappings are set up or even how they work. We discuss them thoroughly in Chapter 25, "Administering the ColdFusion Server."

For your application to perform specific functions or to conduct certain transactions, the various layers of the application interact with each other. One of the advantages of separating your application into a layered architecture is to minimize the interaction of the client or presentation layer with the backend data. The reason for this is that all your business logic code is wrapped into the business layer and only this layer interacts directly with the data. In OOP approaches, these different layers are sometimes referred to as the interface and the implementation.