一、認識Web.config文件
Web.config 文件是一個XML文本文件，它用來儲存 asp.NET Web 應用程序的配置信息（如最常用的設置ASP.NET Web 應用程序的身份驗證方式），它可以出現在應用程序的每一個目錄中。當你通過.Net新建一個Web應用程序後，默認情況下會在根目錄自動創建一個默認的Web.config文件，包括默認的配置設置，所有的子目錄都繼承它的配置設置。如果你想修改子目錄的配置設置，你可以在該子目錄下新建一個Web.config文件。它可以提供除從父目錄繼承的配置信息以外的配置信息，也可以重寫或修改父目錄中定義的設置。
(一).Web.Config是以XML文件規范存儲,配置文件分為以下格式
1.配置節處理程序聲明
特點：位於配置文件的頂部，包含在<configSections>標志中。
2.特定應用程序配置
特點: 位於<aPPSetting>中。可以定義應用程序的全局常量設置等信息.
3.配置節設置
特點: 位於<system.Web>節中，控制ASP.Net運行時的行為.
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"
/>
I.default language: 定義後台代碼語言,可以選擇c#和vb.Net兩種語言.
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中特點:工作負載會變大，但信息不會丟失.
II. stateConnectionString :指定ASP.Net應用程序存儲遠程會話狀態的服務器名，默認為本機
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="?"/>
&l
t;/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>
之間，出於學習的目的下面的示例都省略了這段XML標記。
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>
作用：為 ASP.Net 應用程序提供有關自定義錯誤信息的信息。它不適用於 XML Web services 中發生的錯誤。
示例：當發生錯誤時，將網頁跳轉到自定義的錯誤頁面。
<customErrors defaultRedirect="ErrorPage.ASPx" mode="RemoteOnly">
</customErrors>
其中元素defaultRedirect表示自定義的錯誤網頁的名稱。mode元素表示：對不在本地 Web 服務器上運行的用戶顯示自定義(友好的)信息。
5、<httpRuntime>節
作用：配置 ASP.Net HTTP 運行庫設置。該節可以在計算機、站點、應用程序和子目錄級別聲明。
示例：控制用戶上傳文件最大為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>
作用：配置 ASP.Net 跟蹤服務，主要用來程序測試判斷哪裡出錯。
示例：以下為Web.config中的默認配置：
<trace enabled="false" requestLimit="10" pageOutput="false" traceMode="SortByTime" loca
lOnly="true" />
注：
enabled="false"表示不啟用跟蹤；
requestLimit="10"表示指定在服務器上存儲的跟蹤請求的數目
pageOutput="false"表示只能通過跟蹤實用工具訪問跟蹤輸出；
traceMode="SortByTime"表示以處理跟蹤的順序來顯示跟蹤信息
localOnly="true" 表示跟蹤查看器 (trace.axd) 只用於宿主 Web 服務器
自定義Web.config文件配置
自定義Web.config文件配置節過程分為兩步。
1.在配置文件頂部 <configSections> 和 </configSections>標記之間聲明配置節的名稱和處理該節中配置數據的 .Net Framework 類的名稱。
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中的session配置詳解
打開某個應用程序的配置文件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"
/>
這一段就是配置應用程序是如何存儲session信息的了。我們以下的各種操作主要是針對這一段配置展開。讓我們先看看這一段配置中所包含的內容的意思。sessionState節點的語法是這樣的：
< 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"
/>
必須有的屬性是：屬性選項描述
mode 設置將session信息存儲到哪裡
Ø Off 設置為不使用session功能，
Ø InProc 設置為將session存儲在進程內，就是ASP中的存儲方式，這是默認值，
Ø StateServer 設置為將session存儲在獨立的狀態服務中，
Ø SQLServer 設置將session存儲在SQL Server中。
可選的屬性是：屬性選項描述
Ø cookIEless 設置客戶端的session信息存儲到哪裡，
Ø ture 使用CookIEless模式，
Ø false 使用CookIE模式，這是默認值，
Ø timeout 設置經過多少分鐘後服務器自動放棄session信息，默認為20分鐘。
stateConnectionString 設置將session信息存儲在狀態服務中時使用的服務器名稱和端口號，例如："tcpip=12
7.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秒鐘。
ASP.Net中客戶端session狀態的存儲
在我們上面的session模型簡介中，大家可以發現session狀態應該存儲在兩個地方，分別是客戶端和服務器端。客戶端只負責保存相應網站的SessionID，而其他的session信息則保存在服務器端。在asp中，客戶端的SessionID實際是以CookIE的形式存儲的。如果用戶在浏覽器的設置中選擇了禁用CookIE，那末他也就無法享受session的便利之處了，甚至造成不能訪問某些網站。為了解決以上問題，在 ASP.Net中客戶端的session信息存儲方式分為：Cookie和CookIEless兩種。
ASP.Net中，默認狀態下，在客戶端還是使用Cookie存儲session信息的。如果我們想在客戶端使用CookIEless的方式存儲session信息的方法如下：
找到當前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自動加上的，不會影響以前正常的連接。
ASP.Net中服務器端session狀態的存儲准備工作：
為了您能更好的體驗到實驗現象，您可以建立一個叫做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>
這個SessionState.ASPx的頁面可以用來測試在當前的服務器上是否丟失了session信息。
將服務器session信息存儲在進程中
讓我們來回到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信息，發現信息已經丟失了。
將服務器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服務。
將服務器session信息存儲在SQL Server中
首先，還是讓我們來做一些准備工作。啟動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中的，能干什麼就看你的發揮了。
總結
三、ASP.Net 關於form認證的一般設置
ASP.Net 關於form認證的一般設置：
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"]
ASP.Net性能優化.
(一).選擇會話狀態存儲方式
在Webconfig文件配置:
<sessionState mode="???" stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"
cookIEless="false" timeout="20"/>
ASP.Net有三種方式存儲會話狀態信息:
1. 存儲在進程中: 屬性mode = InProc
特點： 具有最佳的性能，速度最快,但不能跨多台服務器存儲共享.
2. 存儲在狀態服務器中: 屬性mode = "StateServer"
特點: 當需要跨服務器維護用戶會話信息時，使用此方法。
但是信息存儲在狀態服務器上，一旦狀態服務器出現故障，信息將丟失
3. 存儲在SQL Server中: 屬性mode="SqlServer"
特點: 工作負載會變大，但信息不會丟失.
補充一點：
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文件中配置:
ASP.Net Sessionss可以在Web.config或Machine.config中的Sessionsstate元素中配置。
下面是在 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();
}
下面的代碼段顯然效率要高.因為i是整型的，系統要先把i進行裝箱轉換為string型的，再進行連接. 需要時間
讀者可以Copy到自己機器上測試一下.
2.使用StringBulider類
在進行字符串連接時: string str = str1 + str2 + ....;
一般超過三項連接，最好用StringBuilder來代替string類. StringBuilder可以避免重新創建string 對象造成
的性能損失.
一般用於組裝sql語句時用到: StringBulider.
讀者可以到自己機器上測試一下.
3.盡量少用:
try
{}
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.數據庫查詢
I. 直接生成sql語句。 SQL Server每次都要對其進行編譯，在性能方面不會有很大的提高。另外也不夠安全。容易被攻擊.
II. 使用帶參數的sql命令。這種方式SQL Server只對其編譯一次，對於不同的參數可以重復使用編譯後的命令。提高了性能.
III.使用SQL Server存儲過程. 編譯一次. 具有獨立性，便於修改和維護. 一次能完成用語句發送多次的功能.減少了網絡的
流量。 並不一定存儲過程一定比語句效率要高，如果商業邏輯很復雜的話，有時候用語句比存儲過程效率要高.
(六).緩存優化
緩存分為兩種：頁面緩存和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
