Understanding Structured Development
| The best way to understand structured developmentwhat it does and the problems it solvesis to look at an example. Listing 11.1 should be familiar; it's the first data-driven example we looked at in Chapter 10, "Creating Data-Driven Pages." Listing 11.1. movies1.cfmThe Basic Movie List<!--- Name: movies1.cfm Author: Ben Forta (ben@forta.com) Description: First data-driven Web page Created: 12/15/04 ---> <!--- Get movie list from database ---> <cfquery name="movies" datasource="ows"> SELECT MovieTitle FROM Films ORDER BY MovieTitle </cfquery> <!--- Create HTML page ---> <html> <head> <title>Orange Whip Studios - Movie List</title> </head> <body> <h1>Movie List</h1> <!--- Display movie list ---> <cfoutput query="movies"> #MovieTitle#<br> </cfoutput> </body> </html> As explained in Chapter 10, this code first retrieves data from a database, then loops through the returned results, outputting one movie at a time. #MovieTitle# in the <cfoutput> loop refers to the MovieTitle column in the Films database table, the column retrieved in the <cfquery> tag. Simple, right? Maybe not. As innocent as Listing 11.1 looks, the makings of a developer's nightmare lurk in its depths. Let me explain. Consider what would happen if the database table changed. Maybe you had to rename a column; or maybe you were rethinking your table layout and needed to split a table into multiple tables; or maybe your field name was Movie Title (with a space, which will work in some databases, but is a really bad practice) and you needed to change it to a legal name; or... You get the idea. If the table field name changed, any and all SQL that referred to that field would have to change too. As we saw in Chapter 10, when you build applications you end up with references to database tables in lot of different files very quickly. If a table changes, each file that referred to that table would need to change. Failure to do so would generate errors because the SQL would be invalid. "No problem," you think. "A quick find-and-replace will locate all those queries." And you may be right; locating every <cfquery> in your application isn't that difficult. Dreamweaverand just about any editor out therewill allow searching across multiple files and folders. But that won't be enough. Why? Because if MovieTitle were changed you'd need to update your SQL and any CFML code that refers to that column. That #MovieTitle# in the <cfoutput> block would need updating too. "Okay," you think, "I can do a search for #MovieTitle# as well, and do another find-and-replace." But that won't work, because you'd also need to find code like this: <cfoutput>#UCase(MovieTitle)#</cfoutput> and this <cfset display="Title: " & MovieTitle> and more. Single-Tier ApplicationsThe problem with the code in Listing 11.1 (and indeed, all of the code written in the last chapter) is that the presentation code is closely tied to the data access code. Developers refer to this type of application as being single tiered. Basically there is one layer or tier to the application, and it contains everything from database code to application logic.
For simple applications, this may not be a problem. But as applications grow in complexity and size, so does the likelihood of something breaking later when you least expect it. Too many applications have been broken by simple changes in one part of an application that had unforeseen implications elsewhere. And the problem isn't just the risk of something breaking. Take a look at the SQL code used in the various <cfquery> tags in the listing in Chapter 10. You'll notice that they are all similar and many are exactly the same, copied from file to file. That isn't efficient use of code. If you were to tweak a queryperhaps to improve performanceyou'd need to do so for lots of queries. If you were to make security-related changes to your queries you'd need to do those all over the place too, and more.
So we have two different but related problems: presentation and content are too closely coupled; and code is repeated multiple times in multiple files. Fortunately, there is a single solution to both problems. Multi-Tier ApplicationsAs we said, a single-tiered application is just that, with everything thrown into a single tier. A multi-tiered application (or an n-tier application) is an application that is broken into different layers, each responsible for just part of the complete application. This may sound complex, bit it needn't be. Consider the code in Listing 11.1 (and all of the data-driven code in Chapter 10). That code could be broken up as follows:
Breaking applications into tiers forces developers to think about data and application logic differently than presentation, and this is a good thing. Consider the following:
I know this sounds a little abstract, but bear with me. It will all make sense in a moment. The key is a special type of file called a ColdFusion Component. |
The processing of the guessing game in Chapter 9, "CFML Basics," is an example of application logic.
EAN: N/A
Pages: 282