ASP Guide
Author: j.d. Meier
Release date: December 27, 1999
Brief Introduction
The success of an Active Server Page (ASP) application often depends on trade-offs between architecture and design. This trade-off is very difficult, given the breadth of the ASP technology and the inherent complexity of the current application. In this article, I will provide you with specific guidelines to help you successfully develop an ASP-based application. From the past successful development model experience, we have summed up the following principles.
I have organized the guidelines into a set of development principles. When evaluating solutions and technologies, you can apply the following guidelines to help you make decisions. The following principles are the cumulative experience I have gained from a successful development model for a long time.
Principle 1: Adopting a standard approach
Establishing naming conventions and standardizing the directory structure can help you significantly improve the readability and maintainability of your ASP applications. Although there is no formal standard for ASP applications, many developers have established some common approaches. Here, I'll share some more general ways with you.
Because the ASP technology relies on the scripting engine for its work, and the script is of a less-than-rigorous nature, the naming convention is also vague. In a very strict type of language, a variable is declared according to its actual type. When using ASP technology, you typically declare variables in ASP code in terms of how variables are processed, rather than their actual data types. For example, when using Visual Basic (R) scripting Edition (VBScript), even though all VBScript variables are variants, you will still declare the success flag as bsuccess (b for Boolean) instead of Vsuccess (v represents a Variant).
The following table is a list of common naming conventions.
variable prefix:Variable variables for prefix use example B or bln Boolean bsuccess C or cur Currency camount D or dbl Double dblquantity dt or dat Date and time dtdate F or Flt Float fratio L or LNG Long lmilliseconds i or int Integer icounter s or str String sname A or arr Array ausers () O or obj COM Object opipeline
variable prefix for database object:Examples of variable variables used by prefixes CNN Connection cnnpubs rst Recordset rstauthors cmd Command cmdemployee fld Field fldlastname
scope and prefix usage:Prefix Description G_ is created in Global.asa. M_ is local to ASP pages or in Include files. (no prefix) non-static variable, prefix is local to procedure
An article in Knowledge Base (KB) "Q110264 info:microsoft Consulting Services naming conventions for Visual Basic" (English) (Http://sup port.microsoft.com/support/kb/articles/q110/2/64.asp) provides insights into naming conventions.
Use the directory structure wherever possible to provide a consistent location for your individual application parts. The actual directory structure of your application is, of course, up to you, but it is usually to place images, documents, include files, and components separately in separate directories. The following is an example of a simple ASP application directory structure.
directory Structure Example:
\simpleaspapp
\docs
\images
\includes
A good directory structure allows you to selectively apply NTFS permissions. You can also use relative paths from within an ASP application. For example, you can use the following code to refer to the include file in the Includes directory from the Default.asp page located in the Simpleaspapp directory top.asp:
./includes/top.asp
Note that the extension of my include file is. asp instead of. Inc. This is done for security reasons, and it is possible to use the. asp extension (instead of. Inc), and it can also be used for color encoding in Visual InterDev (R).
For additional tips and tricks on structured ASP applications, see the article "ASP Conventions" (http://msdn.microsoft.com/workshop/server/asp/aspconv.asp).
Principle 2: Designed to run under the service
The ASP will run under the service. When designing an ASP application, you immediately face security and threading problems that you will not encounter in your desktop application. In a desktop environment, only single-threaded execution, which runs as an interactive user, is typically handled, and access to the current desktop system is granted. In Internet Information Services (IIS), multiple client threads that simulate different user environments call your application, and your application is limited to the system desktop.
What does this mean for you? Learn about IIS security mode. Also remind you that just because something works correctly under the Visual Basic IDE does not mean it can run safely in ASP technology. The Visual Basic IDE does not accurately simulate the run-time environment. Common design errors include the use of the user interface in ASP technology. OCX control, using threads to say unsafe components, and using components that require special user contexts. One of the simplest things to avoid is trying to access HKEY_CURRENT_USER (HKCU) registry entries from your application (for example, do not call Visual Basic's
GetSettingAnd
SaveSettingFunctions, they all depend on HKCU). Also, do not show message boxes or other dialog boxes that require user interaction.
The following article is a pretty good primer on security and validation issues in ASP technology:
- "Authentication and security for Internet Developers" (English) (http://msdn.microsoft.com/workshop/server/feature/security.asp)
- "Q172925 info:security Issues with Objects in ASP and ISAPI Extensions" (English) (http://support.microsoft.com/support/kb/ articles/q172/9/25.asp)
Principle 3: Encapsulating business logic
ASP technology provides a representation service by generating HTML output. In short, it generates a user interface. You need to separate the business logic from the ASP presentation script. Even if you do not use COM components to separate business logic from ASP code, you should at least separate business logic into functions and include files to improve maintainability, readability, and reusability. You can also appreciate the benefits of modular design methods when troubleshooting and isolation issues are required.
Calling functions and methods inside of a script avoids code whack and adds structure to an ASP application. The following example illustrates the separation of logic into a method call from ASP code:
lt;% Main () Mybizmethod () ... Sub Main () GetData () Displaydata () End sub%>
This principle can be applied when using a technology that contains ASP features. Here's an example of using Visual Basic WebClass to illustrate how to use this principle:
- Because WebClass itself generates HTML by referencing ASP code, you do not place the business logic directly within WebClass. Because this is your presentation layer, do not run WebClass directly under mts/com+.
- From WebClass, you can invoke a separate business component that can run in mts/com+.
- You can decide to create your own COM components that have references to ASP, rather than relying on the WebClass framework structure and additional WebClass runtime overhead-You can also automate business components using ASP scripts.
principle 4: Get the resources as late as possible and release the resources
A common problem is the transition from a desktop system to a server. Many developers with desktop system backgrounds have never been worried about server issues and resource sharing. In a traditional desktop application, connecting to a server is a time-consuming process. To improve the user experience, it is common to use early access to resources and postpone the release of resources. For example, many applications will always be connected to the database throughout its run time.
This approach works well in traditional desktop applications because the number of users is clear, easy to control, and the back end is tightly connected to the front end. However, this is not a good way for the current WEB application, because limited server resources will face an increasing number of users. In order for your application to be able to cope with the increase in the number of users, you need to get resources as late as possible to release resources.
Sharing helps to increase the effectiveness of this approach. By sharing, multiple users have the ability to share resources, with minimal latency and minimal impact on the server. For example, when working with a database, the sharing of ODBC connections and OLE DB resources enables you to select connections from the pooled pool and minimize the cost of connecting to the database.
For more information about sharing ADO, see "Pooling in Microsoft Data Access components" (English) (http://msdn.microsoft.com/library/techart/ pooling2.htm).
principle 5: Use database to maintain complex state
Although the HTTP protocol is stateless, ASP developers often use the state retention mechanism built into ASP functionality. For example, using ASP technology built in
Applicationobject, the resources saved by the developer can be shared by all users of the application. By using ASP built in
SessionObject, the developer saves resources only for individual users.
Although it sounds as if the ASP technology
SessionSaving information in an object is a very convenient way to keep the state, but the cost is too great, and it can be one of the biggest constraints on scalability. The scalability of an application is essentially the ability to continue to maintain its performance as the number of users grows. And for each user, before the session times out or is discarded,
SessionObjects consume the resources of the server. Sessions also bind you to a single server, limiting your ability to take advantage of Web clustering. If possible, do not use ASP
SessionObject for state management. If you do not use sessions at all, you can disable the session state of the WEB application (see the IIS documentation). Otherwise, you can use the following statement
