ASP Guide _ Application Tips

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:

prefix	variables to use	variable Examples
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:

prefix	variables to use	variable Examples
Cnn	Connection	Cnnpubs
Rst	Recordset	Rstauthors
Cmd	Command	Cmdemployee
Fld	Field	Fldlastname

Scope and Prefix usage:

prefix	Description
G_	Created in Global.asa.
M_	is local to ASP pages or in Include files.
(No prefix)	Non-static variables, for procedures, prefixes are local

An article in Knowledge Base (KB) "Q110264 info:microsoft Consulting Services naming conventions for Visual Basic" provides genuine insight into naming conventions See.

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".

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 getsetting and savesetting functions, 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)
• "Q172925 info:security Issues with Objects in ASP and ISAPI Extensions" (English)

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 business logic directly within WebClass. Because this is your presentation layer, do not run WebClass directly under mts/com+.
• From WebClass, you can invoke individual business components 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).

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 the application object built into ASP technology, the resources that a developer holds can be shared by all users of the application. By using ASP's built-in Session object, developers save resources only for individual users.

While it sounds easy to keep the information in the session object of ASP technology, the cost of this approach 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. For each user, the session object consumes the resources of the server before it times out or is discarded. Sessions also bind you to a single server, limiting your ability to take advantage of Web clustering. Do not use ASP session objects for state management, if possible. 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 disable session state for each page by using the following statement:

<% @ENABLESESSIONSTATE =false%>

For some simple data, you can use a QueryString cookie or a hidden form field to keep the status between ASP requests. Then, for more complex information, it is often recommended that you use a database. The general approach is to generate a specific identifier and then send it to each client that makes the request and save as a hidden form field. In a subsequent request, this unique identifier is used to find state information related to the user in the database. This approach provides higher scalability and simpler and clearer code.

For more information about using querystring cookies and hidden form fields, see "Q175167 howto:persisting Values without Sessions" (English).

Principle 6: Create objects using Server.CreateObject

When creating an object for ASP technology, you can choose the <OBJECT> tags,server.createobject , and CreateObject three ways. The behavior of each technique is slightly different. Although using <OBJECT> tag or CreateObject is a slightly more performance advantage than Server.CreateObject in IIS 4.0, we generally recommend using Server.CreateObject, so that you can recognize your object in an ASP application. (Note that in IIS 5.0, the first two items have no performance advantage compared to Server.CreateObject .) ）

<OBJECT> tags Create components only when the first method is called, so you can save resources. Server.CreateObject uses the ASP technology's built-in Server object to create components. In essence, it only executes the CoCreateInstance, but the ASP is able to recognize the object. At the same time, the traditional onstartpage and onendpageof ASP technology will also be invoked. (Note that ObjectContextis best used in IIS 4.0 or later.) If you are just using createobject, you will use the scripting engine directly over ASP technology.

Here is a possible exception: when you call through a firewall, you may need to invoke CreateObject instead of Server.CreateObject. For more information, see "Q193230-prb:server.createobject fails when Object is behind Firewall" (English).

Principle 7: Provide rich troubleshooting information

Make sure that the error handling process is included in all of your ASP applications. Also, make sure that you provide useful diagnostic information. I have not met anyone who complains that the error message is too descriptive. Make sure that you include the following information in the error log:

• User context (if you are using components, you can call getusername)
• Thread ID (in the component, you can call GetCurrentThreadID) <
• Time
• Complete error message (including number, source, and description)
• Parameter values

Because it will run under ASP, you may want to write this information to a file or NT event log. You can also create an application event log that records critical application events for use when diagnosing application errors.

The following articles provide more information about error-handling techniques:

• "BulletProofing Your ASP Components" (English), Charles Alexander
• "Fitch & Mather Stocks:web Application" (English)
• "Handling and avoiding Web Page Errors, part 1:the Basics" (English)
• "Handling and avoiding Web Page Errors, part 2:run-time Errors" (English)
• "Handling and avoiding Web Page Errors, part 3:an ounce of prevention" (English)

Principle 8: Test performance, scalability, and reliability

Browsers are not an accurate way to test, they can only show you what the application might be used for. Set specific performance targets for your application and use load tools such as WEB application Stress Tool for stress testing. You need to decide for yourself what conditions your environment can accept, and here are some common guidelines to help you start the test process:

• Test the performance by testing the number of requests per second of ASP and establish a minimum threshold value. In general, a simple ASP page that does not perform database access should return at least 30 pages per second. The page that calls the component or accesses the database returns at least 25 pages per second.
• Continually append users to the application until the number of requests per second is lower than the preset thresholds, testing scalability in this way.
• Remove the machine from the Web cluster and check for errors and failures to test for reliability.

Match the test environment to the actual running environment, even firewalls are no exception. That sounds expensive, but I've heard that developers lose their jobs because they don't think about firewalls.

For more information about testing an ASP application using the WEB application Stress Tool, see "I Can ' t Stress It enough--Load Test Your ASP Application" (English).

Principle 9: Increase segregation

Using isolation to protect your application processes can greatly enhance server stability. When it comes to Internet applications, the consequences of using the quarantine feature can vary greatly: one is the application crashes and the other is the server. Securing the primary IIS process (InetInfo.exe) is usually ranked higher in the priority list. This is especially true when you are working with components.

Typically, the technology used to protect the primary ISS process is to make the WEB application run in its own memory space. In Internet Services Manager, you can set this option for each Web. Although system resources that are overhead because of the grouping of processes can have a little impact on performance, the protection of the application is worth the cost. Under IIS 4.0, you can run applications in both in-process (in-process) and out-of-process (Out-of-process,oop) ways. The OOP application runs in the new Mtx.exe instance. Under IIS 5.0, you can also use other isolation options. The isolation level can be set to low (in-process applications for Inetinfo.exe), medium (DllHost.exe shared instances) or "high" (unshared instances of Dllhost.exe).

In addition to isolating WEB applications in their own memory space, you may also want to isolate untrusted components. A component that is not trusted is usually a component that does not pass the test time in the actual environment. You can run these components in the Server package so that they run in the new Dllhost.exe instance.

In general, if you want to take a golden mean between performance and protection, you run the WEB application in the high quarantine state and run the component in the library package. This approach minimizes the cost of marshalling, while providing the strongest protection between processes.

For more information, see the article "Server Reliability through Process isolation" (English).

Principle 10: Do not misuse thread-sharing groups

Under IIS 4.0, for each processor that is managed by MTS, the default common group for ASP is 10 threads. In IIS 5.0, the default value is 20. This means that each thread is a potentially valuable resource that can handle multiple client requests. You also need to avoid calling a blocking method, such as making a large database call. If you have work to do this, it will prevent the ASP application from returning the response to the client quickly, consider using the queue feature. For example, in NT 4.0, MSMQ can be used. In Windows 2000, you can use the Queued components (Queued Components).

Instead of storing single-threaded Apartment (STA) components in a session, a common flaw in this approach is that it fills up the Visual Basic objects in the session scope. Locks the user to a thread, which runs counter to the purpose of the threading common group. Potential users are blocked behind other users, and the thread that waits to create their components becomes effective. You should design a stateless component that can be created and broken on a per-page basis in a different way.

Quick tip: Make sure that the ASP Script debugging feature is disabled on the server (using Internet Services Manager). If ASP Script debugging is enabled, the ASP's execution process is locked to a thread.

For more information, see the following articles:

• "Q243544 info:component Threading Model Summary Under Active Server Page" (English)
• "Q191979 prb:vb Component not Marked Apartment produces ASP 0115 Error" (English)
• "Q243548 info:design Guidelines for VB components Under ASP" (English)
• "Q243543 info:do not Store STA Objects in Session or application" (English)
• "Tuning Internet Information Server performance" (English)

Summary

Creating an ASP application requires a fairly broad range of knowledge. One of the challenges facing ASP applications is that there are no common rules at the moment (which is also part of the fun). Another problem is that many developers are working on desktop systems before they reach Internet development. By applying these rules to your ASP development work, you have the hope of avoiding costly mistakes and developing fairly good ASP applications.

-->

J.D Meier was born and grew up on the east coast of the United States. Following Horace Greeley's advice, he became a developer support engineer focused on server-side components, including MTS and ASP technologies, as well as on Windows DNA applications.