Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

C# ПІДРУЧНИКИ / c# / Hungry Minds - ASP.NET Bible VB.NET & C#

.pdf
Скачиваний:
129
Добавлен:
12.02.2016
Размер:
7.64 Mб
Скачать

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

For more information about the command-line options used with vbc, type "vbc /?" at the command prompt.

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,

Соседние файлы в папке c#