
C# ПІДРУЧНИКИ / c# / Hungry Minds - ASP.NET Bible VB.NET & C#
.pdf§timeout: Specifies the number of minutes after which a new worker process will be launched to take the place of the current one. The default value is set to infinite.
§idleTimeout: Specifies the number of minutes of inactivity after which the worker process automatically gets shut down. The default value is set to infinite.
§shutdownTimeout: Specifies the time, in hh:mm:ss format, the worker process is given to shut down by itself. When the timeout expires, the ASP.NET runtime will kill the worker process automatically. The default value is set to 5 seconds.
§requestLimit: Specifies the number of requests after which a new worker process will be launched to take the place of the current one. The default value is set to infinite.
§requestQueueLimit: Specifies the maximum allowed number of requests in the queue after which the worker process is considered to be in a "hung" state. Once the requestQueueLimit is reached, a new process will be launched and the requests will get reassigned. Then, no further requests will be directed toward the "hung" worker process. The default value is set to 5000.
§memoryLimit: Specifies a maximum allowed memory size for a worker process. The value is set as a percentage of the total system memory that the worker process consumes before it is considered as a misbehaving process. After this limit is crossed, a new process will be launched and the requests will get reassigned. The default value is set to 40 percent.
§cpuMask: Specifies the processors on which the ASP.NET worker processes will execute. This attribute is used when the webGarden attribute is set to True, which indicates that ASP.NET worker processes will not use all the processors on the system. When the webGarden attribute is set to False, it means that all eligible CPUs will be used.
§webGarden: This attribute controls the CPU affinity in conjunction with the cpuMask attribute. The default value is True, which indicates that the processes should be allocated CPUs by the operating system; there is no preferential allotment of processors to the worker processes.
The following is an example:
<processModel
enable="true"
timeout="15"
idleTimeout="25"
shutdownTimeout="0:01:00"
requestLimit="1000"
requestQueueLimit="500"
memoryLimit="20"
webGarden="true"
/>
The processModel is enabled for the Web server. After every 15 minutes, the server will launch a new worker thread. After every 25 minutes of idle time, the worker process will automatically get shut down. The worker process is given 1 minute for a graceful shutdown before it is terminated. After every 1,000 requests, a new worker thread will be launched to handle further Web requests. The maximum limit for the worker thread, after which it will be treated as a misbehaving thread, is set to 500 requests in the queue. The memory limit is set to 20 percent of the available memory on the system, and the CPU affinity is set to True.
<sessionState> section
The <sessionState> section provides a means to configure the session state HttpModule of the ASP.NET application. The syntax is as follows:
<sessionstate
mode = "mode="Off|Inproc|StateServer|SqlServer"
cookieless="true|false"
timeout="number of minutes"
connectionString="server name:port number"
sqlConnectionString="sql connection string"/>
The <sessionState> section uses five attributes, which are described as follows:
§Mode: Indicates where the session state is stored. These are the
possible settings:
oOff: Indicates the session state is disabled for the Web application.
oInproc: Indicates that session state is stored by the worker process itself. In case of a crash, the
session state is lost. Also, this model does not work well in a Web farm due to redirection of client requests to other Web servers.
oStateServer: Indicates that the session state information is stored in a separate ASP.NET State Service that runs out of process from the Web server. This model is safe from any crashes that might occur in the Web server. The session state will be available no matter what happens to the Web server. This is an out -of-process state management model. The Session State service can be hosted on the same server as the Web server or it can be configured on a separate physical machine. In case it is hosted on the same machine as the Web server, if a serious failure occurs, such as in the disk subsystem or CPU or power supply, it will cause the server to switch off or reboot. In such a case, the session state is lost. If this service is configured on a separate physical machine, then this problem can be avoided. But, there is no way to cluster this service to protect against failure of the state server machine.
oSqlServer: The most reliable model for storing session state information across Web server crashes and machine reboots. To improve the availability of session state information across a Web farm, the session information can be stored on a SQL Server database, which itself can be placed on a cluster.
§Cookieless: Takes one of the values True or False. A True value indicates that the cookieless sessions should be used to identify client sessions. On the other hand, a False value indicates that the cookie-enabled sessions should be used. The default value for the tag is set to False.
§Timeout: Defines the number of minutes a session can remain idle. Once this limit has passed, the session is abandoned automatically. The default value for this attribute is set to 20.
§ConnectionString: Specifies the server name of the remote session state store for the application, as well as the port on which the Session State service is listening. The default value is
set to localhost. This attribute is used when the mode is set to StateServer (the out-of-process state service).
§sqlConnectionString: Specifies the connection string used to connect to the SQL Server that is running the session state database.
If you wish to have a remote session state store, you must set the
Note inproc attribute to False and specify the server name and port number (using the server and port attributes) of the machine on which state services are running.
The following is an example:
<sessionState mode = "InProc"
stateConnectionString = "tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;user id=sa;password="
cookieless="true"
timeout="5"/>
This states that the application session is managed by using cookieless sessions. The URL will be encoded by the ASP.NET runtime to include a character string, which is unique for every client. The session timeout is 5 minutes. Here is a sample Web page that uses session state to record some information:
<%@ Page Language="vb"%>
<HTML>
<HEAD>
<title></title>
</HEAD>
<script runat="server">
sub Page_Load()
Session("Var1")="This is the value stored in Variable 1"
end sub
Sub Display(Src As Object, E As EventArgs)
lblResult.Text = Session("Var1")
end sub
</script>
<body>
<form id="Form1" method="post" runat="server">
<P>
<asp:Button id="cmdDisplay" runat="server" Text="Call
Display" onclick="Display" />
</P>
<P>
<asp:Label id="lblResult" runat="server" Width="270px"
Height="31px"></asp:Label>
</P>
</form>

</body>
</HTML>
Figure 14-2 shows the output of this page.
Figure 14-2: Output of the page displaying value of a Session variable
<trace> section
The <trace> section allows the configuration of the ASP.NET trace service. The syntax is as follows:
<trace
enabled="[true/false]"
requestLimit="[Integer]"
pageOutput="[true/false]"
/>
The <trace> section can be configured using the following attributes:
§enabled: Indicates the status of the trace feature specified for the application. The default value is set to False.
§requestLimit: Specifies the number of trace requests to store on the server for the application. The default value for the attribute is set to 10.
§pageOutput: Indicates whether the trace information for the application should be displayed at the end of each page or be accessible only via the trace utility.
An example is as follows:
<trace
enabled="true" requestlimit="20" pageoutput="true"
/>
The section sets the application-level trace to True and the number of trace requests to be stored to 20. The trace output is set to be displayed on the page.
<webServices> section
The <webServices> section is used to control the settings of the ASP.NET Web Services. An example is as follows:
<configuration>
<system.web>
<webServices>
<protocolTypes>
<add type="System.Web.Services.Protocols. SoapServerProtocol" />
<add type="System.Web.Services.Protocols. HttpServerProtocol" />
<add type="System.Web.Services.Protocols. DiscoveryServerProtocol" />
</protocolTypes>
<returnWriterTypes>
<add type="System.Web.Services.Protocols. XmlReturnWriter"
/>
</returnWriterTypes>
<parameterReaderTypes>
<add type="System.Web.Services.Protocols. HtmlFormParameterReader" />
<add type="System.Web.Services.Protocols. UrlParameterReader" />
</parameterReaderTypes>
<protocolReflectorTypes>
<add type="System.Web.Services.Description. SoapProtocolInfoReflector" />
<add type="System.Web.Services.Description. HttpPostProtocolInfoReflector" />
<add type="System.Web.Services.Description. HttpGetProtocolInfoReflector" />
</protocolReflectorTypes>
<mimeReflectorTypes>
<add type="System.Web.Services.Description. XmlMimeInfoReflector" />
<add type="System.Web.Services.Description. FormInfoReflector" />
</mimeReflectorTypes>
<protocolImporterTypes>
<add type="System.Web.Services.Description. SoapProtocolInfoImporter" />
<add type="System.Web.Services.Description. HttpPostProtocolInfoImporter" />
<add type="System.Web.Services.Description. HttpGetProtocolInfoImporter" />
</protocolImporterTypes>
<mimeImporterTypes>
<add type="System.Web.Services.Description. XmlMimeInfoImporter" />
<add type="System.Web.Services.Description. FormInfoImporter" />
</mimeImporterTypes>
<protocolInfoTypes>
<add type="System.Web.Services.Description. SoapProtocolInfo" />
<add type="System.Web.Services.Description. HttpGetProtocolInfo" />
<add type="System.Web.Services.Description. HttpPostProtocolInfo" />
</protocolInfoTypes>
<mimeInfoTypes>
<add type="System.Web.Services.Description. HtmlFormInfo"/>
<add type="System.Web.Services.Description. XmlMimeInfo"/>
<add type="System.Web.Services.Description. AnyMimeInfo"/>
</mimeInfoTypes>
<referenceResolverTypes>
<add type="System.Web.Services.Discovery. DiscoveryResolver" />
<add type="System.Web.Services.Discovery. ServiceResolver"
/>
<add type="System.Web.Services.Discovery. SchemaResolver"
/>
</referenceResolverTypes>
<discoverySearchPatternTypes>
<add type="System.Web.Services.Discovery.
ServiceSearchPattern" />
</discoverySearchPatternTypes>
<soapExtensionTypes>
</soapExtensionTypes>
<soapExtensionReflectorTypes>
</soapExtensionReflectorTypes>
<soapExtensionImporterTypes>
</soapExtensionImporterTypes>
<sdlHelpGenerator href=
"DefaultSdlHelpGenerator.aspx" />
</webServices>
</system.web>
</configuration>
The preceding example used different elements of the <webServices> section to set the configuration settings for the ASP.NET Web Services. Some of the settings involve setting the protocol, return type for the application, help file for the application, and the search patterns supported by the application.
Summary
This chapter explored the ASP.NET configuration concepts and the Web.config configuration files used by the ASP.NET configuration system. First, you learned the advantages offered by the ASP.NET configuration system in the process of deploying the ASP.NET applications. You saw the structure of the Web.config configuration files. Then, you learned the structure and implementation of different sections in the Web.config configuration file.
Chapter 15: Developing Business Objects
Overview
Most modern applications are based on the client/server architecture, which divides an application into two logical parts, the client and the server. The functions performed by the client and the server can be divided into three categories: user services, business services, and data services. These services are implemented as logical layers in an application. The user service layer, also called the presentation layer, performs the task of providing an interactive user interface. The business service layer enforces the business rules that define the behavior of an organization. For example, an organization might decide that the credit limit for its clients should not exceed $2,000. The business service layer performs such validations pertaining to the business rules of an organization. The data service layer is responsible for managing and manipulating data.
Based on the methods used for implementing these three layers, client-server applications are further categorized as single-tier, two-tier, three-tier, and n-tier or
multitier applications. In case of a single-tier or monolithic application, all the functions relating to the user, business, and data service layers are grouped into one logical application module, which might be a single executable file. In a two-tier application, the user and data services are located separately, either on the same machine or on separate machines. For example, you might have a Visual Basic application, which provides the user interface, and SQL Server 7.0, which manages data. In such a case, the business services might be handled by the client or by the server. In a three-tier application, all the three service layers reside separately, either on the same machine or on different machines. A multitier or n-tier application is very similar to a three-tier application. An n-tier application uses business objects for handling business rules and data access. It has multiple servers handling business services. This application architecture provides various advantages over other types of application architectures. Some of the advantages include extensibility, resilience to change, maintainability, and scalability of the application.
Most Web applications are based on the n-tier architecture. In case of Web applications, the browser acts as a client, which makes requests to the Web server for some data. The Web server processes the request and sends the requested data to the browser. You might implement an extra layer between the browser and the Web server for performing business rule validations. This layer can be implemented by using business objects.
In this chapter, you will learn to create and use business objects in ASP.NET. You will also learn about deploying business objects and working with business object namespaces in ASP.NET.
Introduction to Business Objects
In an n-tier application, the business services layer can be encapsulated in various reusable classes, known as business object classes, which can be combined to create precompiled components. Thus, business objects are reusable and interoperable components that perform a specific set of functions. Business objects enable you to build applications that can be easily changed as per the changing requirements of users and the organization. You can also build new applications based on existing components. This results in reduced development time and maintenance costs. You can also substitute the user and the data services layers without having a negative impact on the working of the business objects.
Business objects can be broadly categorized as follows:
§User interface (UI)-centric business rule objects: These objects concentrate on validation of user interface components. For example, you may create a UI-centric business rule object to ensure that a text box is not blank. A UI-centric business rule object may also perform some calculations on the data returned from the database.
§Data-centric business rule objects: These objects perform the functions relating to data access such as locating the source of data, sending the necessary commands for retrieving data, manipulating data, and sending the data back and forth between the database and the UI-centric business rule objects. Data-centric business rule objects run faster than UI-centric business rule objects, because the latter often depends on the former for completion of data manipulation and integration. For example, you might create a UI-centric business rule object that displays the net amount after calculating the sales tax and the discount based on the product price and order quantity. This object might depend on a data-centric object, which establishes a connection to the data server, sends the required commands to the server, and returns the prices and order quantities of products from the database to the UI-centric object. In this case, the UI-centric object has to wait until the data-centric object returns the required data for calculating the net amount.
Creating and Using Business Objects
ASP.NET enables you to easily create your own business objects and use them in Web applications. In this section, you will look at the process of creating a simple UI-centric business object that calculates the sales tax and the discount based on the price of a product. You will also learn to create a data-centric business rule object for establishing a connection and sending queries to the database server.
Creating a UI-centric business rule object
To create a business rule object, follow these steps:
1.Select File → New → Project. This invokes the New Project dialog box. Select Visual Basic Projects from the Project Types list box. Select Class Library from the Templates list box. Name the project CalcNetAmt.
2.In the Solution Explorer window, right-click the Class1.vb file and select Rename from the pop-up menu. Change the name of the Class1.vb file to CalcNetAmt.vb.
3.Create the function CalcAmt() in the class CalcNetAmt and type the following code:
4.Public Class CalcNetAmt
5.Public Function CalcAmt(ByVal dPrice As Double) As Double
6.Dim dNetAmt As Double
7.dNetAmt = dPrice * 1.1
8.If (dNetAmt > 100)
9. dNetAmt = dNetAmt * 0.95
10.End If
11.Return dNetAmt
12.End Function
End Class
This function takes the price of a product as a parameter. It calculates the sales tax as 10 percent of the product price. If the net price after adding the sales tax is greater than $100, a discount of 5 percent is given on net price. The function returns the net payable amount for a product.
13.Compile this class by selecting Build → Build. When you compile the class, a DLL file is created; this file can be used by other applications. Alternatively, you can compile this class by typing the following statement at the MS-DOS command prompt:
14.vbc /t:library /out:calcnetamt.dll calcnetamt.vb
In this statement, vbc is the Visual Basic compiler. You can use various command-line options with the compiler. The /t option is used to specify the type of output file format to be created by the compiler. You can set this option to exe (console application), library (code library), module (DLL), or winexe (Windows-based application). In this statement, the /t:library option instructs the compiler to create a library assembly.
Note |
Business objects created in .NET are packaged in the form of |
|
assemblies, which store all the information required for deploying |
|
and versioning a component. Assemblies are discussed in detail |
|
later in this chapter. |
The /out option specifies the name of the output file to be created. In this case, the name of the resulting file is Calcnetamt.dll. Finally, you specify the file to be compiled as Calcnetamt.vb.
Note
Creating a data -centric business rule object
For creating a data-centric business rule object, the steps will be similar to those in case of UI-centric business objects. In this section, we will create a simple reusable datacentric business rule object that establishes a connection with the specified server and sends the queries to the database server.
For creating the data-centric business rule object, complete the following steps:
1.Select File → New → Project.
2.Select Visual Basic Projects from the Project Types list box. Select Class Library from the Templates list box. Name the project GetData.
3.In the Solution Explorer window, right-click the Class1.vb file and select the Rename option from the pop-up menu.
4.Rename the Class1.vb file GetData.vb and type the following code in the file:
5.Imports System.Data
6.Imports System.Data.SQLClient
7.Public Class DataAccessObj
8.
9.Dim sConnectionStr As String
10.Dim sQryStr As String
11.
12.Public Property sConnection() As String
13.Set
14. sConnectionStr = value
15.End Set
16.Get
17.Return sConnectionStr
18.End Get
19.End Property
20.
21.Public Property sQry() As String
22.Set
23.sQryStr = value
24.End Set
25.Get
26.Return sQryStr
27.End Get
28.End Property
29.
30.Private Function EstablishConnection() As SQLConnection
31.Dim SQLConObj As New SQLConnection(sConnectionStr)
32.Return SQLConObj
33.End Function
34.
35.Public Function DisplayData() As DataView
36.Dim CmdObj As New SqlDataAdapter(sQryStr,