一、认识
Web.config
文件
Web.config
文件是一个
xml
文本文件,它用来储存
asp.NET Web
应用程序的配置信息(如最常用的设置
asp.NET Web
应用程序的身份验证方式),它可以出现在应用程序的每一个目录中。当你通过
.NET
新建一个
Web
应用程序后,默认情况下会在根目录自动创建一个默认的
Web.config
文件,包括默认的配置设置,所有的子目录都继承它的配置设置。如果你想修改子目录的配置设置,你可以在该子目录下新建一个
Web.config
文件。它可以提供除从父目录继承的配置信息以外的配置信息,也可以重写或修改父目录中定义的设置。
1.
配置节处理程序声明
特点:
位于配置文件的顶部,包含在
<configSections>
标志中。
2.
特定应用程序配置
特点
:
位于
<appSetting>
中。
可以定义应用程序的全局常量设置等信息
.
3.
配置节设置
4.
配置节组
特点
:
用
<sectionGroup>
标记,可以自定义分组,可以放到
<configSections>
内部或其它
<sectionGroup>
标记的内部
.
(
二
).
配置节的每一节
1.<configuration>
节
根元素,其它节都是在它的内部
.
2.<appSetting>
节
此节用于定义应用程序设置项。对一些不确定设置,还可以让用户根据自己实际情况自己设置
用法
:
I.
<appSettings>
<add key="Conntction" value="server=192.168.85.66;userid=sa;password=;database=Info;"/>
<appSettings>
定义了一个连接字符串常量,并且在实际应用时可以修改连接字符串,不用修改程式代码
.
II.<appSettings>
<add key="ErrPage" value="Error.aspx"/><appSettings>
定义了一个错误重定向页面
.
3.<compilation>
节
格式
:
<compilation
defaultLanguage="c#"
debug="true"
/>
IIdebug :
为
true
时,启动
aspx
调试;
为
false
不启动
aspx
调试,因而可以提高应用程序运行时的性能。
一般程序员在开发时设置为
true,
交给客户时设置为
false.
4.<customErrors>
节
格式
:
<customErrors
mode="RemoteOnly"
defaultRedirect="error.aspx"
<error statusCode="440" redirect="err440page.aspx"/>
<error statusCode="500" redirect="err500Page.aspx"/>
/>
I.mode :
具有
On,Off,RemoteOnly 3
种状态。
On
表示始终显示自定义的信息
; Off
表示始终显示详细的
asp.net
错误信息
; RemoteOnly
表示只对不在本地
Web
服务器上运行的用户显示自定义信息
.
II.defaultRedirect:
用于出现错误时重定向的
URL
地址
.
是可选的
III.statusCode:
指明错误状态码,表明一种特定的出错状态
.
IV. redirect:
错误重定向的
URL.
5.<globalization>
节
格式
:
<globalization
requestEncoding="utf-8"
responseEncoding="utf-8"
fileEncoding="utf-8"
/>
I.requestEncoding:
它用来检查每一个发来请求的编码
.
II.responseEncoding:
用于检查发回的响应内容编码
.
III.fileEncoding:
用于检查
aspx,asax
等文件解析的默认编码
.
6.<sessionState>
节
格式
:
<sessionState
mode="InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"
cookieless="false"
timeout="20"
/>
I.mode:
分为
off,Inproc,StateServer,SqlServer
几种状态
mode = InProc
存储在进程中
特点:具有最佳的性能,速度最快
,
但不能跨多台服务器存储共享
.
mode = "StateServer"
存储在状态服务器中
特点
:
当需要跨服务器维护用户会话信息时,使用此方法。但是信息存储在状态服务器上,一旦状态服务器出现故障,信息将丢失
. mode="SqlServer"
存储在
sql server
中
特点
:
工作负载会变大,但信息不会丢失
.
III.sqlConnectionString:
当用会话状态数据库时,在这里设置连接字符串
IV. Cookieless:
设置为
true
时,表示不使用
cookie
会话状态来标识客户;
否则,相反
.
V. TimeOut:
用来定义会话状态存储的时间,超过期限,将自动终止会话
.
7.<authentication>
节
格式
:
<authentication mode="Forms">
<forms name=".ASPXUSERDEMO" loginUrl="Login.aspx" protection="All" timeout="30"/>
</authentication>
<authorization>
<deny users="?"/>
</authorization>
I.Windows:
使用
IIS
验证方式
II.Forms:
使用基于窗体的验证方式
III.Passport:
采用
Passport cookie
验证模式
IV.None:
不采用任何验证方式
里面内嵌
Forms
节点的属性涵义
:
I.Name:
指定完成身份验证的
Http cookie
的名称
.
II.LoginUrl:
如果未通过验证或超时后重定向的页面
URL
,一般为登录页面,让用户重新登录
III.Protection:
指定
cookie
数据的保护方式
.
可设置为
: All None Encryption Validation
四种保护方式
a. All
表示加密数据,并进行有效性验证两种方式
b. None
表示不保护
Cookie.
c. Encryption
表示对
Cookie
内容进行加密
d. validation
表示对
Cookie
内容进行有效性验证
IV. TimeOut:
指定
Cookie
的失效时间
.
超时后要重新登录
.
在运行时对
Web.config
文件的修改不需要重启服务就可以生效(注:
<processModel>
节例外)。当然
Web.config
文件是可以扩展的。你可以自定义新配置参数并编写配置节处理程序以对它们进行处理。
web.config
配置文件(默认的配置设置)以下所有的代码都应该位于
<configuration>
<system.web>
和
</system.web>
</configuration>
1、<authentication> 节
作用:配置
asp.NET
身份验证支持(为
Windows
、
Forms
、
PassPort
、
None
四种)。该元素只能在计算机、站点或应用程序级别声明。
< authentication>
元素必需与
<authorization>
节配合使用。
示例:
以下示例为基于窗体(
Forms
)的身份验证配置站点,当没有登陆的用户访问需要身份验证的网页,网页自动跳转到登陆网页。
<authentication mode="Forms" >
<forms loginUrl="logon.aspx" name=".FormsAuthCookie"/>
</authentication>
其中元素
loginUrl
表示登陆网页的名称,
name
表示
Cookie
名称。
2、<authorization> 节
作用:控制对
URL
资源的客户端访问(如允许匿名用户访问)。此元素可以在任何级别(计算机、站点、应用程序、子目录或页)上声明。必需与
<authentication>
节配合使用。
示例:以下示例禁止匿名用户的访问
<authorization>
<deny users="?"/>
</authorization>
注:你可以使用
user.identity.name
来获取已经过验证的当前的用户名;可以使用
web.Security.FormsAuthentication.RedirectFromLoginPage
方法将已验证的用户重定向到用户刚才请求的页面
.
具体的
3、<compilation>节
作用:配置
asp.NET
使用的所有编译设置。默认的
debug
属性为“
True
”
.
在程序编译完成交付使用之后应将其设为
False
(
Web.config
文件中有详细说明,此处省略示例)
4、<customErrors>
示例:当发生错误时,将网页跳转到自定义的错误页面。
<customErrors defaultRedirect="ErrorPage.aspx" mode="RemoteOnly">
</customErrors>
其中元素
defaultRedirect
表示自定义的错误网页的名称。
mode
元素表示:对不在本地
Web
服务器上运行的用户显示自定义
(
友好的
)
信息。
5、<httpRuntime>节
示例:控制用户上传文件最大为
4M
,最长时间为
60
秒,最多请求数为
100
<httpRuntime maxRequestLength="4096" executionTimeout="60" appRequestQueueLimit="100"/>
6、 <pages>
作用:标识特定于页的配置设置(如是否启用会话状态、视图状态,是否检测用户的输入等)。
<pages>
可以在计算机、站点、应用程序和子目录级别声明。
示例:不检测用户在浏览器输入的内容中是否存在潜在的危险数据(注:该项默认是检测,如果你使用了不检测,一要对用户的输入进行编码或验证
)
,在从客户端回发页时将检查加密的视图状态,以验证视图状态是否已在客户端被篡改。
(
注:该项默认是不验证)
<pages buffer="true" enableViewStateMac="true" validateRequest="false"/>
7、<sessionState>
作用:为当前应用程序配置会话状态设置(如设置是否启用会话状态,会话状态保存位置)。
示例:
<sessionState mode="InProc" cookieless="true" timeout="20"/>
</sessionState>
注:
mode="InProc"
表示:在本地储存会话状态(你也可以选择储存在远程服务器或
SAL
服务器中或不启用会话状态)
cookieless="true"
表示:如果用户浏览器不支持
Cookie
时启用会话状态
(
默认为
False
)
timeout="20"
表示:会话可以处于空闲状态的分钟数
8、<trace>
示例:以下为
Web.config
中的默认配置:
<trace enabled="false" requestLimit="10" pageOutput="false" traceMode="SortByTime" localOnly="true" />
注:
enabled="false"
表示不启用跟踪;
requestLimit="10"
表示指定在服务器上存储的跟踪请求的数目
pageOutput="false"
表示只能通过跟踪实用工具访问跟踪输出;
traceMode="SortByTime"
表示以处理跟踪的顺序来显示跟踪信息
localOnly="true"
表示跟踪查看器
(trace.axd)
只用于宿主
Web
服务器
自定义
Web.config
文件配置
自定义
Web.config
文件配置节过程分为两步。
2.
是在
<configSections>
区域之后为声明的节做实际的配置设置。
示例:创建一个节存储数据库连接字符串
<configuration>
<configSections>
<section name="appSettings" type="System.Configuration.NameValueFileSectionHandler, System, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
</configSections>
<appSettings>
<add key="scon" value="server=a;database=northwind;uid=sa;pwd=123"/>
</appSettings>
<system.web>
......
</system.web>
</configuration>
访问
Web.config
文件
你可以通过使用
ConfigurationSettings.AppSettings
静态字符串集合来访问
Web.config
文件示例:获取上面例子中建立的连接字符串。例如:
protected static string Isdebug = ConfigurationSettings.AppSettings["debug"]
打开某个应用程序的配置文件
Web.config
后,我们会发现以下这段:
< sessionState
mode="InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"
cookieless="false"
timeout="20"
/>
< sessionState mode="Off|InProc|StateServer|SQLServer"
cookieless="true|false"
timeout="number of minutes"
stateConnectionString="tcpip=server:port"
sqlConnectionString="sql connection string"
stateNetworkTimeout="number of seconds"
/>
必须有的属性是:
属性
选项
描述
可选的属性是:
属性
选项
描述
Ø ture
使用
Cookieless
模式,
Ø false
使用
Cookie
模式,这是默认值,
stateConnectionString
设置将
session
信息存储在状态服务中时使用的服务器名称和端口号,例如:
"tcpip=127.0.0.1:42424”。当mode
的值是
StateServer
是,这个属性是必需的。
sqlConnectionString
设置与
sql server
连接时的连接字符串。例如
"data source= localhost;Integrated Security=SSPI;Initial Catalog=northwind"
。当
mode
的值是
SQLServer
时,这个属性是必需的。
stateNetworkTimeout
设置当使用
StateServer
模式存储
session
状态时,经过多少秒空闲后,断开
Web
服务器与存储状态信息的服务器的
tcp/IP
连接的。默认值是
10
秒钟。
在我们上面的
session
模型简介中,大家可以发现
session
状态应该存储在两个地方,分别是客户端和服务器端。客户端只负责保存相应网站的
SessionID
,而其他的
session
信息则保存在服务器端。在
asp
中,客户端的
SessionID
实际是以
Cookie
的形式存储的。如果用户在浏览器的设置中选择了禁用
Cookie
,那末他也就无法享受
session
的便利之处了,甚至造成不能访问某些网站。为了解决以上问题,在
asp.NET
中客户端的
session
信息存储方式分为:
Cookie
和
Cookieless
两种。
找到当前
Web
应用程序的根目录,打开
Web.Config
文件,找到如下段落:
< sessionState
mode="InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"
cookieless="false"
timeout="20"
/>
这段话中的
cookieless="false"
改为:
cookieless="true"
,这样,客户端的
session
信息就不再使用
Cookie
存储了,而是将其通过
URL
存储。关闭当前的
IE
,打开一个新
IE
,重新访问刚才的
Web
应用程序,就会看到类似下面的样子:
其中,
http://localhost/MyTestApplication/(ulqsek45heu3ic2a5zgdl245) /default.aspx
中黑体标出的就是客户端的
session ID
。注意,这段信息是由
IIS
自动加上的,不会影响以前正常的连接。
为了您能更好的体验到实验现象,您可以建立一个叫做
SessionState.aspx
的页面,然后把以下这些代码添加到
< body>< /body>
中。
< scriptrunat="server">
Sub Session_Add(sender As Object, e As EventArgs)
session("MySession") = text1.Value
span1.InnerHtml = "Session data updated! < P>Your session contains: < font color=red>" & session("MySession"). ToString() & "< /font>"
End Sub
Sub CheckSession(sender As Object, eAs EventArgs)
If (Session("MySession")Is Nothing) Then
span1.InnerHtml = "NOTHING, session DATA LOST!"
Else
span1.InnerHtml = "Your session contains: < font color= red>" & session("MySession").ToString() & "< /font>"
End If
End Sub
< /script>
< formrunat="server"id="Form2">
< inputid="text1"type="text"runat="server"name="text1">
< inputtype="submit"runat="server"OnServerClick="Session_Add"
value="Add to session State " id="Submit1"name="Submit1">
< inputtype="submit"runat="server"OnServerClick="CheckSession"
value=" View session State " id="Submit2"name="Submit2">
< /form>
< hrsize="1">
< fontsize="6">< spanid="span1"runat="server" />< /font>
让我们来回到
Web.config
文件的刚才那段段落中:
< sessionState
mode="InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"
cookieless="false"
timeout="20"
/>
当
mode的值是InProc时,
说明服务器正在使用这种模式。
这种方式和以前
asp
中的模式一样,就是服务器将
session
信息存储在
IIS
进程中。当
IIS
关闭、重起后,这些信息都会丢失。但是这种模式也有自己最大好处,就是性能最高。应为所有的
session
信息都存储在了
IIS
的进程中,所以
IIS
能够很快的访问到这些信息,这种模式的性能比进程外存储
session
信息或是在
sql server
中存储
session
信息都要快上很多。这种模式也是
asp.NET
的默认方式。
好了,现在让我们做个试验。打开刚才的
SessionState.aspx
页面,随便输入一些字符,使其存储在
session
中。然后,让我们让
IIS
重起。注意,并不是使当前的站点停止再开始,而是在
IIS
中本机的机器名的节点上点击鼠标右键,选择重新启动
IIS
。
(
想当初使用
NT4
时,重新启动
IIS
必须要重新启动计算机才行,微软真是
@#$%^&)
返回到
SessionState.aspx
页面中,检查刚才的
session
信息,发现信息已经丢失了。
首先,让我们来打开管理工具
->
服务,找到名为:
asp.NET State Service
的服务,启动它。实际上,这个服务就是启动一个要保存
session
信息的进程。启动这个服务后,你可以从
Windows
任务管理器
->
进程中看到一个名为
aspnet_state.exe
的进程,这个就是我们保存
session
信息的进程。
然后,回到
Web.config
文件中上述的段落中,将
mode
的值改为
StateServer
。保存文件后的重新打开一个
IE
,打开
SessionState.aspx
页面,保存一些信息到
session
中。这时,让我们重起
IIS
,再回到
SessionState.aspx
页面中查看刚才的
session
信息,发现没有丢失。
实际上,这种将
session
信息存储在进程外的方式不光指可以将信息存储在本机的进程外,还可以将
session
信息存储在其他的服务器的进程中。这时,不光需要将
mode
的值改为
StateServer
,还需要在
stateConnectionString
中配置相应的参数。例如你的计算你是
192.168.0.1
,你想把
session
存储在
ip
为
192.168.0.2
的计算机的进程中,就需要设置成这样:
stateConnectionString="tcpip=192.168.0.2:42424"
。当然,不要忘记在
192.168.0.2
的计算机中装上
.NET Framework
,并且启动
asp.NET State Services
服务。
首先,还是让我们来做一些准备工作。启动
sql server
和
sql server
代理服务。在
sql server
中执行一个叫做
InstallSqlState.sql
的脚本文件。这个脚本文件将在
sql server
中创建一个用来专门存储
session
信息的数据库,及一个维护
session
信息数据库的
sql server
代理作业。我们可以在以下路径中找到那个文件:
[system drive]/winnt/Microsoft.NET/Framework/[version]/
然后打开查询分析器,连接到
sql server
服务器,打开刚才的那个文件并且执行。稍等片刻,数据库及作业就建立好了。这时,你可以打开企业管理器,看到新增了一个叫
ASPState
的数据库。但是这个数据库中只是些存储过程,没有用户表。实际上
session
信息是存储在了
tempdb
数据库的
ASPStateTempSessions
表中的,另外一个
ASPStateTempApplications
表存储了
asp
中
application
对象信息。这两个表也是刚才的那个脚本建立的。另外查看管理
->SQL server
代理
->
作业,发现也多了一个叫做
ASPState_Job_DeleteExpiredSessions
的作业,这个作业实际上就是每分钟去
ASPStateTempSessions
表中删除过期的
session
信息的。
接着,我们返回到
Web.config
文件,修改
mode
的值改为
SQLServer
。注意,还要同时修改
sqlConnectionString
的值,格式为:
sqlConnectionString="data source=localhost; Integrated Security=SSPI;"
其中
data source
是指
sql server
服务器的
ip
地址,如果
sql server
与
IIS
是一台机子,写
127.0.0.1
就行了。
Integrated Security=SSPI
的意思是使用
Windows
集成身份验证,这样,访问数据库将以
asp.NET
的身份进行,通过如此配置,能够获得比使用
userid=sa;password=
口令的
sql server
验证方式更好的安全性。当然,如果
sql server
运行于另一台计算机上,你可能会需要通过
Active Directory
域的方式来维护两边验证的一致性。
同样,让我们做个试验。向
SessionState.aspx
中添加
session
信息,这时发现
session
信息已经存在
sql server
中了,即使你重起计算机,刚才的
session
信息也不会丢失。现在,你已经完全看见了
session
信息到底是什么样子的了,而且又是存储在
sql server
中的,能干什么就看你的发挥了。
1:
在
web.config
中,加入
form
认证;
<authentication mode="Forms">
<forms name="auth" loginUrl="index.aspx" timeout="30"></forms>
</authentication>
<authorization>
<deny users="?" />
</authorization>
2:
如果有注册页面时还应该允许匿名用户调用注册页面进行注册
;
以下代码应该在
<configuration><system.web>
之间
,
而不应该包含到
<system.web>..</system.web>
之间
;
----------------
表示允许
匿名用户对
userReg.aspx
页面进行访问
.
<location path="userReg.aspx">
<system.web>
<authorization>
<allow users="?" />
</authorization>
</system.web>
</location>
3
在登录成功后要创建身份验证票
,
表明已经通过认证的合法用户
;
if(
登陆成功
)
System.Web.Security.FormsAuthentication.SetAuthCookie(
用户名称
, false);
四、访问
Web.config
文件
你可以通过使用
ConfigurationSettings.AppSettings
静态字符串集合来访问
Web.config
文件示例:获取上面例子中建立的连接字符串。例如:
protected static string Isdebug = ConfigurationSettings.AppSettings["scon"]
(
一
).
选择会话状态存储方式
在
Webconfig
文件配置
:
<sessionState mode="???" stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"
cookieless="false" timeout="20"/>
1.
存储在进程中
:
属性
mode = InProc
特点:
具有最佳的性能,速度最快
,
但不能跨多台服务器存储共享
.
2.
存储在状态服务器中
:
属性
mode = "StateServer"
特点
:
当需要跨服务器维护用户会话信息时,使用此方法。
但是信息存储在状态服务器上,一旦状态服务器出现故障,信息将丢失
特点
:
工作负载会变大,但信息不会丢失
.
补充一点:
I.
由于某些页面不需要会话状态,则可以将会话状态禁用
:
代码如下:
<%@ Page EnableSessionState="false" %>
II.
如果页面需要访问会话变量但不允许修改它们,可以设置页面会话状态为只读
:
代码如下:
<%@ Page EnableSessionState="false" %>
使用时可以根据具体情况选择某种方式
(
二
).
使用
Page.IsPostBack
Page.IsPostBack
表示是否是从客户端返回的
.
初次运行时,不是从客户端返回,它的值
为
false,
当触发页面上的事件或刷新页面时,
Page.IsPostBack
由于是回发的,值变为
true;
一般在
: Page_Load
方法中用
:
private void Page_Load(Object sender,EventArgs e)
{
if(!Page.IsPostBack)
{
....; //
初始化页面的代码。这些代码第一次页面初始化时执行,当第二次回发时,
//
不会再执行。提高效率。
}
}
往往很多时候不得不用
IsPostBack,
因为有些控件初始化后,要保持它的状态
.
例如
: DropDownList,
如果每次都初始化,则用户无论选择其选项,都会被初始化为默认值
.
(
三
).
避免使用服务器控件
1.
一般的静态显示信息,尽量不要用服务端控件显示
.
因为服务端控件需要回发服务端执行
,
会降低程序执行效率
,
一般用
<DIV>
显示即可
.
如果用了服务端控件,将
: runat="server"
去掉
,
也会提高效率
.
2.
禁用服务端控件的状态视图,有些控件不需要维护其状态,可以设置其属性
: EnableViewState=false;
如果整个页面控件都不需要维持状态视图,则可以设置整个页面的状态视力为
false:
代码如下
: <%@ Page EnableViewState="false"%>
3.
在
Web.Config
文件中配置
:
下面是在
Web.config
中的设置的例子:
<Sessionsstate timeout="10" cookieless="false" mode="Inproc" />
(
四
).
避免使用
DataGrid
大家都知道
DataGrid
功能强大。
但是功能强大的同时,增加了性能上的开销。
一般用其它控件
: DataList
或
Repeater
控件能实现的,尽量不用
DataGrid.
(
五
).
字符串操作
1.
避免装箱操作
.
装箱操作运行效率比较低
.
例如运行两个代码段
:
string test="";
for(for int i=0;i<10000;i++)
{
test = test + i;
}
和
string test="";
for(for int i=0;i<10000;i++)
{
test = test + i.ToString();
}
读者可以
Copy
到自己机器上测试一下
.
2.
使用
StringBulider
类
在进行字符串连接时
: string str = str1 + str2 + ....;
的性能损失
.
读者可以到自己机器上测试一下
.
3.
尽量少用
:
{}
catch
{}
finally
{}
语句
.
此语句执行效率比较低
.
(六).ADO.Net使用方面优化
1.
数据库连接打开和关闭。
在需要连接时打开,当访问完数据库要立刻关闭连接
.
举例说明
,
还是看两个代码段
:
I.
DataSet ds = new DataSet();
SqlConnection MyConnection = new SqlConnection("server=localhost; uid=sa; pwd=; database=NorthWind");
SqlCommand myCommand = new SqlCommand(strSql,MyConnection);
SqlDataAdapter myAdapter=new SqlDataAdapter(queryStr,connectionStr);
MyConnection.Open(); //
打开连接
for(int i=0;i<1000;i++) //for
循环模拟取得数据前的商业逻辑操作
{
Thread.Sleep(1000);
}
myAdapter.Fill(ds);
for(int i=0;i<1000;i++) //for
循环模拟取得数据后的商业逻辑操作
{
Thread.Sleep(1000);
}
MyConnection.Close(); //
关闭连接
II.
DataSet ds = new DataSet();
SqlConnection MyConnection = new SqlConnection("server=localhost; uid=sa; pwd=; database=NorthWind");
SqlCommand myCommand = new SqlCommand(strSql,MyConnection);
SqlDataAdapter myAdapter=new SqlDataAdapter(queryStr,connectionStr);
for(int i=0;i<1000;i++) //for
循环模拟取得数据前的商业逻辑操作
{
Thread.Sleep(1000);
}
MyConnection.Open(); //
打开连接
myAdapter.Fill(ds);
MyConnection.Close(); //
关闭连接
for(int i=0;i<1000;i++) for
循环模拟取得数据后的商业逻辑操作
{
Thread.Sleep(1000);
}
显示
II
代码比
I
代码好的多,
I
中早早占着连接不放,如果用户很多的话,容易出现连接池满情况。严重时出现死机现象
.
2.
数据库查询
流量。
并不一定存储过程一定比语句效率要高,如果商业逻辑很复杂的话,有时候用语句比存储过程效率要高
.
(
六
).
缓存优化
缓存分为两种:
页面缓存和
API
缓存
.
1.
使用页面缓存和片段缓存
<%@ OutputCache Duration="5" VaryByParam="None"%>
<%@ OutputCache Duration=60 VaryByParam=”TextBox1,TextBox2” %>
说明
: Duration
是设置
Cache
的过期时间
;
VarByParam
是设置是否根据参数而变化
,None
时所有参数使用同一
Cache,
设置
TextBox1
时则根据
TextBox1
的不同值分别缓存
;
当有多个参数时则要组合缓存
;
2.API
缓存。用于在应用程序中使用
I.
一个
Cache
使用的例子
:
http://blog.csdn.net/chengking/archive/2005/10/03/494545.aspx
II.
使用时注意
Page.Cache
和
HttpContext.Current.Cache
区别
:
它们指的同一个对象,在
Page
里,用
Page.Cache
,如果在
global.asax
或自己的类里用
:HttpContext.Current.Cache
在有些事件中,由于其没有
HttpContext
,就用
HttpRuntime.Cache.