Application Layers

Developers should take the time to understand the fundamentals of application layers to write well-organized applications that are easy to maintain. In this section, we take a look at how applications can logically be divided into layers, regardless of the physical architecture on which the application is loaded. At its most basic, the N-tier application architecture can be divided into the following tiers or layers:

• Presentation

• Business

• Data Interface

• Data

The layers of your application code can be separated by your physical file and directory structure. Figure 3.5 shows the ColdFusion Studio development interface. The directory structure is set up to mimic the division of application layers that we've been discussing.

Figure 3.5. Physical directory structure of our application as seen in ColdFusion Studio 5.

The Presentation Layer

The presentation layer is made up of all elements of the application with which the user sees and interacts. This list of elements can include colors, font faces and styles, images, form controls, navigational elements, and more. These elements together are often referred to as the graphical user interface (GUI) or the user interface (UI). These elements define the look and feel of the application and their consistency and flow can determine the disposition of the user experience.

Users generally interact with ColdFusion applications through the use of a web browser. I say "generally" because ColdFusion applications are client-independent. This means that the ColdFusion Server is not concerned with the presentation-layer method or with the application logic and processing. This enables ColdFusion to output data to different types of clients, including web browsers (HTML), Personal Data Assistants (PDAs) (cHTML, XHTML), cell-phones and other wireless client browsers (WML), and even voice browsers (VoiceXML).

The UI

It seems that a new technology pops up every day to enable designers and developers to produce more feature-rich UIs. In an N-tier application, the presentation code for the UI should never access the database directly. Likewise, the UI code should never handle business rules or process logic. It should merely provide for screen layout. Figure 3.6 shows a simple UI.

Figure 3.6. A simple UI for our application.

When discussing UI considerations, again the application architect and designer have to rely on the completeness of the requirements that have been gathered. These requirements should bring into better focus issues such as layout, colors, fonts, screen resolution, plug-ins, scripting, and browser compatibility that are necessary to deliver an application that meets the customer's needs.

Layout

I'm no artist or graphic designer and you might not be either, but paying close attention to layout of the screens throughout your application not only makes your application more aesthetically appealing to the user, but also it enhances the usability of the application itself. Consistency is one of the key elements that you need to remember about layout. You don't want your user hopping from page to page in your application and being forced to search for common elements such as navigation and form controls.

Correctly treating the unused spaces in the browser screen and having a balanced layout that utilizes all areas of the screen are important. Remember that you can say as much with a clean and professional layout as you can with lots of flashing banners, blinking text, and dancing cartoon characters.

Advertising and publishing companies employ experts in layout who provide ads with balanced and proportional layouts that mix typography, images, and text to convey a message. Each element is important to layout.

Online, layout is not quite as cut and dry. We have to worry about users' screen resolution settings and color-quality settings. Many web designers and developers use framed layouts for their sites. Some employ dynamic navigational elements. One thing is clear, however; consistency in your chosen layout method is key to making and keeping users comfortable with your application.

Colors

You should consider colors when planning the look and feel of your application. Colors can calm or can stir up emotions in users. Be careful with colors, however. Many times, designers or developers use too many colors or the wrong colors. This has the undesired effect of pulling the user's attention away from the content, and it distracts their focus.

Color on the web is quite different from color in print media. After the printed item is completed, the color cannot be changed and everyone sees the same color. It does not work this way online, however. There are many limitations to presenting color on the web. Some of the things that you should keep in mind include the following:

• Monitors that display your web site or application have a wide variety of depth settings.

• Color settings can be calibrated differently or use different gamma settings.

• OSs affect the way that color is displayed.

• Web browsers affect the way that color is displayed.

Color should be a big concern to anyone who is developing a UI. You should know that there are certain colors that are considered browser-safe. By working within the limits of those browser-safe colors, you can be more confident that your users are seeing the colors that you intended them to see.

Note

You can download the color-safe browser palette and find more tips regarding colors from Lynda Weinman's web site at www.lynda.com.

Screen Resolution

When planning your application, keep in mind the screen resolution settings of your users' video adapters. Most computers are shipped with video settings defaulted to 800x600 pixels. However, newer flat-panel monitors often have a lowest resolution setting of 1024x768.

Many developers forget that the actual usable screen real estate is less than what the resolution setting would lead you to believe. Check out the popular resolution settings and corresponding browser window sizes shown in Table 3.1 to help you keep your layout on target.

Table 3.1. Screen Resolutions and Browser Window Sizes

Screen Resolution Setting	Browser Window Size
640x480	600x300
800x600	760x420
1024x768	955x600

It's always a good idea to design your application so that the lowest resolution monitors can view and interact with your application without any formatting problems or excessive scrolling. Don't guess at what your users' resolution settings are. If at all possible, this information should be provided as part of your requirements-gathering process.

Fonts

We communicate user instructions with text on our screens, so, of course, we need to make sure that we pick fonts that are going to be easy for the user to read. The most commonly used fonts are Arial and Times New Roman. However, most web presentations look better with a font from the sans-serif font family. These fonts include Arial, Helvetica, or Verdana. The reason for using these standard fonts is that the user must have the specified font on his or her system, or you must push that font to the user along with your code.

By varying font sizes, styles, and colors, you can convey not only information, but also the importance of that information. Keep in mind that it's not a good idea to use more than one or two fonts in your application. In addition, remaining consistent with font sizes and styles when calling out headings or identifying notes throughout your application is an important factor in maintaining continuity.

Images

As we move through the development of our application, we are adding more and more content and are developing web graphics to support that content. As they say, a picture is worth a thousand words, and if you have the choice of reading all those words or checking out a cool graphic, I'm sure you'd choose the graphic.

There are, however, drawbacks to stuffing your application with graphics and photos. One of the largest drawbacks is the effect that overloading your web pages with references to images can cause. The reason for this is that the user must wait for all images to download before the requested page is fully viewable. Thus, if you're downloading lots of images on every page, you can slow down your page response times.

Another thing to keep in mind when you're planning your graphical presentation and considering photos, graphics, and other graphical elements (such as Flash or Shockwave files) is that the bandwidth of the end user likely is not as fast as your access to your development server (often local).

Client-Side Scripting

Many web applications use client-side scripting languages such as JavaScript and VBScript to enhance the user experience. Developers often utilize client-side scripting for form validation, user alerts and confirmation, and new windows.

VBScript is a scaled-down version of Microsoft's Visual Basic (VB) language. Support for VBScript is built in to Microsoft's Internet Explorer (IE). However, if your user is accessing your application using a Netscape or other web browser, he or she might need to download special plug-ins to support the code.

JavaScript was originally a creation of Netscape. It was called LiveScript, but the name was changed when Netscape and Sun Microsystems struck up a partnership and developed the language jointly. JavaScript shares some of the same structures and syntax with Java, but the languages are totally separate. JavaScript is most often the client-side scripting language of choice for most developers because of its cross-browser compatibility.

Browser Compatibility

Speaking of browser compatibility, developers need to be wary of problems with the compatibility of their code with various browsers. Such compatibility often affects the placement of elements on the screen.

The key to avoiding problems with browser compatibility is to find out what browser and browser version your users are using. Of course, unless your application will be viewed within a closed environment such as an intranet, this task is next to impossible. What you must do is build a profile of your typical user and build the application to support that profile.

Even after determining your typical user profile and building your application, you still have to test for compatibility. In your user's preferred browser and its nearest competitor, test your application for proper placement and alignment of screen elements. In other words, if the typical user's browser is IE 5.5, test with it, but also test with a comparable version of Netscape Navigator.

You also need to be aware that the user might have disabled support for client-side scripting languages such as JavaScript. If the user's browser does not support your code, you should plan ahead for how to that user.

The Business Layer

As we continue to break out the layers or tiers of N-tier application architectures, let's pause for a moment to get a general understanding of the business logic layer and the role it plays.

Just as every business is run on operating procedures or business rules, every application operates under a similar set of criteria. These criteria are what we call the business rules of the application. These business rules are strung together in business process logic. These business processes enable developers to create complete transactions that users will be guided through during their interaction with the application.

The business layer should provide us with an area in which we can write and store the code that interprets our business rules. It should also provide for a way to follow the logical flow of the business, or the business process logic.

Business Rules

As stated earlier, every business runs on rules, and business rules in a ColdFusion application define how the application enables users to interact with your data. For example, if a business rule states that the user must provide a valid email address to log in to the application, the application must enforce this rule. One way to enforce such a rule is to enable a user to register by providing his or her email address. We then can generate a password and email it to the email address that the user provided.

Because business rules are defined to help maintain the integrity of your data, the business rules are not defined by the application architecture. Just the opposite is true: The application architecture is defined to help support the business rules, the business processes, and the process logic.

The example that we just mentioned might use one or more specialized pieces of code to make the application adhere to the business rule that the user must provide a valid email address. One piece of code might check whether the email address provided is in the proper format. Because it is up to you how and where you enforce these rules, you might choose to enforce them using client-side scripting (using, for example, JavaScript or VBScript). This can also be accomplished using a user-defined functions (UDF) or regular expression.

Business Process Logic

Compliance with business rules usually means that your application transactions have to follow some sort of defined business-process logic. A process is an action that the user might take that requires multiple steps. Business processes enable users to move through complicated procedures in a way that breaks the process into logical steps. The user continues interacting with the application along the way until the application has gathered all the information that it needs to complete the process.

Figure 3.7. Step-by-step process logic.

Each step of a transaction should lead the user step-by-step through the process and should enforce the defined business rules along the way.

For example, many shopping cart applications require new users to register, providing personal information and ordering information along the way. They often require users to not only provide their mailing address, but also to provide billing and shipping addresses as well. A user would be overwhelmed if he or she were presented with all these requirements on the same screen.

A business process would break these requirements into chunks that are easy for the user to deal with and easy for the developer to manage. Not only do you do a service to your users, but also you do a service to your developers.

Data Interface Layer

The data interface layer provides access to the data in your backend database. It does not include any business logic or constraints on how we interact with the database. The data interface layer merely enables us to do things like SELECT, INSERT, UPDATE, and DELETE data from our database. The data interface tier should not contain code that defines any business rules or business processes, nor should it contain any code that comprises any presentation-level elements.

In your ColdFusion application, the data interface layer could be made up of templates that contain the CFSTOREDPROC calls for the stored procedures that you've written in the data layer. It could also contain CFQUERY tag calls that you've separated into functional groups or individual templates.

If you think about it, it makes sense to keep the data requests separate from the code that controls the presentation. The structure of the data itself seldom changes. The presentation-layer code, however, changes more often than anything else in the application. If you keep your CFQUERY tag calls in the same template with your presentation code, you run the risk of inadvertently messing up that code. It is better to separate the database calls into separate templates that are accessed much less frequently and that are less prone to programmers' fat fingers.

Data Layer

The data layer is responsible for the storage of your data. This is your database. The data layer is where you can tune and optimize data storage and data access and provide direct access to the data in your backend database. The data layer exists whether you employ a two-tier or N-tier architecture with the business logic layer as a buffer to ensure the integrity of your data through the business rules that are enforced.

The data layer is where you create stored procedures to perform queries against the data in the database. These might be very basic functions or might consist of advanced filtering and joining techniques (to be discussed later). Your stored procedures should not care about the business rules of the application, only the input and output parameters that they'll be handling. The business rules serve as a buffer to make sure that the only values that get to your stored procedures are the ones that are valid.

It is within the data layer that you optimize the performance of your database. Performance enhancements such as table indexes enable you to access data faster within the database, which speeds the query process. In turn, this improves the performance to the end user through the presentation layer.

Summary

The architectural model for any application is critical to the application's success. Whether the application is scalable, easy-to-maintain, and easy-to-extend depends on the quality of its architecture. An application's architecture is intended to give a better picture of how the entire system works. It shows how the parts work, and it enables us to see this picture from several different perspectives.