Nowadays, many websites that use ASP do not use components at all. Today, the editor of Fooxin Technology Channel briefly describes the division services between ASP and components. I hope it will be helpful for you to learn this knowledge.
ASP and components division services
ASP is most commonly used to create HTML or XML files for use by clients on servers, so we mainly discuss this usage scenario. This brings up a common question: if ASP pages are on the server, do they belong to part of the business layer? In the component world, the answer is usually no. While ASP does run on the server and may be in the same space as the application server, this does not make it part of the business logic.
With user interface tools growing or as more business-to-business solutions are enabled, having this clear distinction will pay off a huge reward.
Having said that, let's look at some of the most important business layer and presentation layer division criteria:
Separate UI code from business logic. This includes writing code coupled to the UI, such as using an MTS object that uses an ASP internal component to separate it from the business logic code, as if it were in a different DLL.
Separate transactions from ASP pages. Transaction ASP is very good in some cases, but components and multi-tier applications change this. Components should not rely on the client layer to manage their transactions and business logic semantics.
Place the representing component (component that uses request and response) in the same machine and/or process as the web server. If an object using the ASP internal component object is placed on a remote machine, all calls to the internal component will occur in a callback form. The COM+ server that calls the IIS client is a COM+ server, which significantly reduces performance and complicates security configuration. These tweak objects can be placed in a COM+ application marked "Library Activation".
ASP exists on the server, so the ASP page must comply with resource sharing rules and keep in mind scalability. Please see the details below:
In a "session", management should try to avoid user-specific status.
Keep ASP stateless and allow resource pools where possible.
Operation method
When evaluating whether a code segment belongs to business logic or presentation layer, ask yourself, "If I have to replace my ASP page with a button-type phone application, is that code still useful?" If the answer is "Yes", you can try dividing it into business logic code or user interface helper code.
If the code cannot be used after changing the client, or if it is a helper for constructing the user interface, the code belongs to the representation service layer. It is in the ASP page, or in a component that uses the ASP internal components. It does not belong to the business object component.
Understand the difference between desktop and ASP client
ASP is a special client of components, unlike traditional single-threaded Win32 applications on the desktop. The main differences are summarized as follows.
Thread Management: ASP is a multi-threaded client. This means that there can be many concurrent activities running together, perhaps handling different ASP pages at the same time. This means that the object cannot be made to falsely claim that it is the only user to exclusively occupy the system. Doing this can cause unexpected reactions, for example, to develop a bad habit of storing objects in an ASP session or application variables.
Security environment: ASP is performed by Internet Information Services 5.0 in the Web site, with three isolation levels: low, medium and high. Even these Web sites can have different security settings, allow or deny anonymous access, authenticate customers, and more. All of these settings create a large number of schemes where different user accounts end up using your objects.
Easily Growth: This is not a technical issue, but a side effect of the facilities provided by web applications.
Traditionally, adding user base to desktop applications requires careful planning of transfers to known numbers of clients. ASP has changed the process. After up and running, the ASP-Visual Basic application can be easily opened for use by all employees, all business partners and all customers locally or worldwide.
It can be described in this way—a single email with a hyperlink can grow the user base tenfold. Is your application ready for this? The only way to know is to do strength testing on your web site to get the expected value of actual performance.
How should you use Visual Basic objects within ASP? Create and cancel your objects within the page scope.
That is, make the ASP page stateless as much as possible, and only depend on session or application variables in a temporary state. Do not store objects in session or application variables. This locks the ASP thread to your session, cancels all expected values for scalability. That is to say, the number of users processed by the web server will not exceed dozens of users. If you need to store content in a session or application, make it a data rather than an object.
There are many other guidelines to follow. We recommend that you read the column “Servin’ it Up” written by JD Meier on MSDN Voices. This column includes a wide range of techniques, practices and tips that help develop scalable, reliable ASP and component applications.
Do not store references in VB objects in session or application
All Visual Basic 6.0 components are "unit threads", which means they all run in STA units. This means that if an object is created in a thread, then all calls to that object must be served by the same thread. Many threads (from concurrent Web site users) use the same instance of the STA object, causing a series of activities that can become bottlenecks in the application.
In addition, storing STA objects created with Server.CreateObject within the session scope can effectively contact the execution thread to the current user, thus limiting the maximum number of concurrent users of the application to the default 20xN (N = number of processors).
Operation method
If you follow our recommendations to make objects stateless, you do not need to store references for client reuse and store them within the application scope. Clients will be able to create, use, and cancel their own objects independently. This reduces the need to keep session-specific objects because they do not retain session-specific state.
The recommended way is to make the object stateless, which accesses the database or other storage areas (such as cookies and LDAP) when needed.
If you need to use session or application-wide data, store the data, rather than the object that processes the data, here. You can create a class that encapsulates the processing of the desired value.
Learn new content in IIS 5.0
Internet Information Server 5.0 adds many new features. These improvements have been written into JD Meier's MSDN article: Use ASP in IIS 5.0 (English).
The above is a brief description of the division services between ASP and components shared by the editor of the False New Technology Channel. I hope you have more knowledge about this aspect, which will help the development of ASP.