The success of ASP applications usually depends on the trade-off between architecture and design. Considering the wide range of ASP technology and the inherent complexity of current applications, this trade-off is very difficult. Here is a brief introduction to the principles and usage of ASP in the Wrong New Technology Channel.
Establishing naming conventions and standardizing the directory structure can help you greatly improve the readability and maintainability of your ASP applications. Although there are currently no formal standards for ASP applications, many developers have established some common ways. Here, I will share with you some more general ways.
Because ASP technology relies on script engines to work, and scripts have a nature of being not strict in type, the naming conventions are also vague. In languages with very strict types, variables will be declared according to their actual type. When using ASP technology, variables are usually declared in ASP code in the way they process variables, rather than their actual data type. For example, when using "Visual Basic(R) Scripting Edition (VBScript)", although all VBScript variables are Variant, you declare the success flag as bSuccess (b for boolean) instead of vSuccess (v for Variant).
The following table is some common naming conventions.
Variable prefix:
| Prefix | Variables used | Variable 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 objects:
| Prefix | Variables used | Variable example |
|---|---|---|
| cnn | Connection | cnnPubs |
| rst | Recordset | rsstAuthors |
| cmd | Command | cmdEmployee |
| fld | Field | fldLastName |
Use of range and prefix:
| Prefix | illustrate |
|---|---|
| g_ | Created in Global.asa. |
| m_ | For ASP pages or in Include files, it is local. |
| (No prefix) | Non-static variables, prefixes are local to the process |
A post in Knowledge Base (KB) "Q110264 INFO: Microsoft Consulting Services Naming Conventions for Visual Basic" (in English) provides insights into naming conventions.
Use directory structures where possible to provide a consistent location for your various application components. 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 in separate directories. The following is an example of a simple ASP application directory structure.
Example directory structure:
/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 reference the include file top.asp in the Includes directory from the default.asp page located in the SimpleAspApp directory:
./includes/top.asp
Note that the extension of my include file is .asp, not .inc. This is done for security reasons, and uses the .asp extension (rather than .inc), and also enables color encoding in Visual InterDev(R).
For some other tips and tips on structured ASP applications, see the article "ASP Conventions" (in English).
The ASP will run under the service. When designing an ASP application, you will immediately face security environments and threading issues that you will not encounter in your desktop application. In a desktop environment, only single-threaded execution run as an interactive user is usually handled and has access to the current desktop system. In Internet Information Services (IIS), multiple client threads in different user environments are simulated to call your application, and your application is limited to the "system" desktop.
What does this mean to you? Please learn the safety mode of IIS. Also remind you: Just because something can run properly under the Visual Basic IDE does not mean it can run safely in ASP technology. The Visual Basic IDE does not accurately simulate the runtime environment. Common design errors include using .OCX controls that require user interfaces in ASP technology, using components that are not safe for threads, and using components that require special user contexts. One of the easiest issues to avoid is trying to access the HKEY_CURRENT_USER (HKCU) registry key from the application (for example, do not call Visual Basic's GetSetting and SaveSetting functions, both of which depend on HKCU). Similarly, do not appear message boxes or other dialog boxes that require the user to interact with human-computer.
The following articles are pretty good introductory books on security and verification issues in ASP technology:
ASP technology provides a representation service by generating HTML output. In short, it generates a user interface. You need to separate business logic from the ASP representation script. Even if you do not use COM components to separate business logic from ASP code, at least separate business logic into functions and include files for improved maintainability, readability, and reusability. You can also appreciate the benefits of modular design methods when troubleshooting and isolation issues are needed.
Calling functions and methods inside the script can avoid messing up the code and add structures to ASP applications. The following example shows how to separate logic into method calls from ASP code:
lt;% Main() MyBizMethod() ... Sub Main() GetData() DisplayData() End Sub%>
This principle can be applied when using techniques that include ASP functionality. Here is an example of how to use this principle when using Visual Basic WebClass:
A common problem is the transition from desktop system to server. Many developers with desktop systems background have never been worried about some server problems and resource sharing. In traditional desktop applications, connecting to a server is a time-consuming process. To improve the user experience, it is usually used to acquire resources early and delay the release of resources. For example, many applications will always be connected to the database throughout its run time.
This method works properly in traditional desktop applications. The reason is that the number of users is very clear, easy to control, and the backend and the frontend are closely connected. However, for current web applications, this approach is no longer feasible because limited server resources will face more and more users. In order for your application to cope with the increase in users, you need to obtain resources as late as possible and release resources as early as possible.
Sharing helps increase the effectiveness of this approach. Through sharing, multiple users can share resources, with the minimum waiting time and minimal impact on the server. For example, when working with a database, ODBC connection sharing and OLEDB resource sharing can enable selecting connections from a shared pool, minimizing the overhead of connecting to the database.
For more information about sharing ADO, see "Pooling in Microsoft Data Access Components".
Although the HTTP protocol is stateless, ASP developers often use the state-holding mechanism built into ASP functions. For example, using the Application object built into ASP technology, the resources saved by developers can be shared by all users of the application. By using ASP's built-in Session objects, developers save resources only for a single user.
Although it sounds like saving information in a Session object of ASP technology is a very convenient way to keep state, this approach is too expensive and it can also be one of the biggest limiting factors on scalability. The scalability of an application is essentially the ability to continue to maintain its performance as the number of users increases. For each user, the Session object consumes the server's resources before the session timed out or was abandoned. Sessions also bind you to a server, limiting your ability to take advantage of the web cluster. Please do not use ASP Session objects for state management as much as possible. If you are not using a session at all, you can disable the Session status of your web application (see the IIS documentation). Otherwise, you can disable Session status for each page using the following statement:
<%@ENABLESESSIONSTATE=False %>
For some simple data, you can use the QueryString cookie or a hidden form domain to maintain the state between ASP requests. Then, for more complex information, it is usually recommended that you use a database. The general approach is to generate a unique identifier, then send it to each requesting client, and save it as a hidden form field. In subsequent requests, this unique identifier is used to look up status information related to the user in the database. This approach provides higher scalability and more concise and clear code.
For more information on using QueryString cookies and hidden form fields, see "Q175167 HOWTO: Persisting Values Without Sessions".
When creating an ASP technology object, you can choose
Here is a possible exception: When you make a call through a firewall, you may need to call CreateObject instead of Server.CreateObject . For more information, see "Q193230 - PRB: Server.CreateObject Fails when Object is Behind Firewall" (English).
Make sure that error handling is included in all your ASP applications. And, make sure you provide useful diagnostic information. I haven't encountered anyone complaining that the error message is too explanatory. Make sure to include the following information in the error log:
Because it will run under ASP, you may want to write this information to a file or NT's event log. You can also create application event logs that log critical application events for use when diagnosing application errors.
The following article provides detailed information on error handling techniques:
A browser is not the exact way to test it, it can only show you the possible uses of the application. Please set specific performance goals for your application and use load tools such as Web Application Stress Tool for stress testing. You need to decide for yourself what your environment can accept, and here are some common guidelines to help you start your testing process:
Match the test environment with the actual running environment, and even the firewall is no exception. This sounds expensive, but I've heard developers lose their jobs because they don't take the firewall into consideration.
For more information on testing an ASP application using the Web Application Stress Tool, see "I Can't Stress It Enough -- Load Test Your ASP Application".
Protecting your application process with isolation can greatly enhance server stability. When it comes to Internet applications, the consequences of using isolation can vary greatly: one is the application crash and the other is the server crash. Protecting the primary IIS process (InetInfo.exe) is usually at a higher priority list. This is particularly prominent when you use components.
The commonly used technique to protect the main ISS process is to enable web applications to run in their respective memory spaces. In Internet Services Manager, you can set this option for each web. Although system resources that are overwhelmed by marshalling processes will have a slight impact on performance, the protection effect on applications is worth the cost. Under IIS 4.0, you can run your application in-process and out-of-process (OOP). The OOP application runs in the new Mtx.exe instance. Under IIS 5.0, you can use other isolation options. The isolation level can be set to "low" (in-process application for Inetinfo.exe), "medium" (DllHost.exe shared instance), or "high" (non-shared instance of Dllhost.exe).
In addition to isolating web applications in their own memory space, you may also want to isolate untrusted components. Components that are not trusted are usually components that do 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.
Generally speaking, if you want to take a moderate approach between performance and protection, the following is the way: Run the web application in a "high" isolation state and run the components in the library package. This approach minimizes marshalling expenses while providing the strongest protection between processes.
For more information, see the article "Server Reliability Through Process Isolation".
Under IIS 4.0, the default common group of ASP is 10 threads for each MTS-managed processor. 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 blocking methods that may occur, such as making large database calls. If you have a job to do this, it will prevent the ASP application from returning the response to the client quickly, consider using the queueing feature. For example, in NT 4.0, MSMQ can be used. In Windows 2000, Queued Components can be used.
One common drawback of not storing Single-threaded Apartment (STA) components in the session is that they fill up the Visual Basic objects in the session scope. It will lock the user to a thread, which will run contrary to the purpose of sharing a group by threads. Potential users will be blocked behind other users, waiting for the threads that create their components to become valid. You should use other ways to design stateless components that can be created and destroyed based on each page.
Quick Tips: Make sure the ASP Script Debugging feature is disabled on the server (using Internet Services Manager). If ASP Script Debugging is enabled, the execution of ASP will be locked to a thread.
For more information, please refer to the following article:
Creating an ASP application requires a considerable range of knowledge. One challenge for ASP applications is that there are currently no common rules (which is part of the fun too). Another problem is that many developers have been engaged in desktop system development before they came into contact with Internet development. By applying the above rules in your ASP development efforts, you have the hope to avoid costly mistakes and be able to develop pretty good ASP applications.
JD Meier was born and raised on the East Coast of the United States. Following Horace Greeley's advice, he became a developer support engineer, focusing on server-side components including MTS and ASP technologies as well as Windows DNA applications.
Through the content introduced by the editor of the 未分New Technology Channel, I believe everyone has a certain understanding. If you want to know more technical content, please continue to pay attention to the 未分New Technology Channel!