Understanding Structured Development - macromedia COLDFUSION MX 7 Web Application Construction Kit [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

macromedia COLDFUSION MX 7 Web Application Construction Kit [Electronic resources] - نسخه متنی

Ben Forta, Raymond Camden, Leon Chalnick, Angela Buraglia

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید











  • Understanding Structured Development


    The best way to understand structured developmentwhat it does and the problems it solvesis to look at an example. 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>
    <!--- Creat260 page --->
    &l275>
    <head>
    <title>Orange Whip Studios - Movie List</title>
    </head>
    <body>
    <h2>Movie List</h2>
    <!--- 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 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 Applications


    The problem with the code in Chapter 9, "CFML Basics," is an example of 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.

    The security issues to be aware of when using <cfquery> and dynamically constructed SQL will be explained in Chapter 30, "More on SQL and Queries."

    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 Applications


    As 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 Chapter 10). That code could be broken up as follows:

    • Data is stored in the database.

    • All database access queries are stored in a special file. This file does no data presentation (it doesn't generat260, for example) and all database access is via this file.

    • All presentation (th260 and <cfoutput> blocks) goes in another file. This file doesn't contain any database interaction, rather, it relies on the previous file for that.


    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:

    • If you made changes to a back-end database, only code in the data access layer would need to change; presentation code would not.

    • As the same data access code can be used by multiple presentation files, any changes made once will be applied to all uses of that code.

    • You're free to change the presentation at will, be it colors, tables, adding alternative client technologies (like Macromedia Flash), or more. These changes are presentation-tier changes, so the database access code will remain as is.


    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.


  • / 281