簡(jiǎn)介一套基于ASP.NET技術(shù)開發(fā)的學(xué)生信息管理Web應(yīng)用源碼面向Web開發(fā)初學(xué)者、高校課程設(shè)計(jì)或畢業(yè)設(shè)計(jì)人群可用于理解并搭建完整的學(xué)生數(shù)據(jù)管理流程。系統(tǒng)覆蓋學(xué)生、教師、課程、成績(jī)、專業(yè)、班級(jí)等模塊包含全局配置、業(yè)務(wù)頁(yè)面與后端邏輯能夠完成信息的增刪改查、導(dǎo)航切換及基本權(quán)限控制。資源包共174個(gè)文件以aspx頁(yè)面和cs后臺(tái)代碼為主另有g(shù)if圖標(biāo)、js腳本、css樣式、配置文件及數(shù)據(jù)庫(kù)文件mdf/ldf/sqlite壓縮包僅1.14MB輕量便于部署和調(diào)試。目前已有4664人學(xué)習(xí)下載。通過(guò)學(xué)習(xí)可掌握ASP.NET應(yīng)用程序生命周期、全局事件處理、ADO.NET或Entity Framework數(shù)據(jù)訪問(wèn)方式以及表單提交、數(shù)據(jù)綁定等關(guān)鍵實(shí)踐同時(shí)可從UI布局與分層結(jié)構(gòu)中借鑒項(xiàng)目組織思路適合直接運(yùn)行驗(yàn)證或在此基礎(chǔ)上擴(kuò)展新功能。1. ASP.NET學(xué)生信息管理系統(tǒng)教學(xué)項(xiàng)目里的硬骨頭值得對(duì)著源碼拆一遍很多人覺(jué)得ASP.NET Web Forms是上個(gè)時(shí)代的產(chǎn)物但你去企業(yè)看一眼就知道大量?jī)?nèi)部管理系統(tǒng)、教務(wù)系統(tǒng)至今還在跑這套技術(shù)棧。這套asp.net學(xué)生信息管理系統(tǒng)正是典型的Web Forms完整項(xiàng)目包含了用戶登錄、角色權(quán)限、學(xué)生信息增刪改查、數(shù)據(jù)分頁(yè)和成績(jī)管理頁(yè)面不多但五臟俱全。它尤其適合兩類人一是剛學(xué)完C#語(yǔ)法但沒(méi)做過(guò)完整項(xiàng)目的新手二是接手舊系統(tǒng)維護(hù)但搞不懂Web Forms事件模型的工程師。拆完這個(gè)項(xiàng)目你能明白一個(gè)請(qǐng)求從瀏覽器到數(shù)據(jù)庫(kù)再返回到頁(yè)面的完整路徑也能理解為什么網(wǎng)上那么多人說(shuō)Web Forms的ViewState是個(gè)坑。這套資源雖然不算前沿卻恰好能讓你把基礎(chǔ)功補(bǔ)扎實(shí)。2. 架構(gòu)與數(shù)據(jù)庫(kù)設(shè)計(jì)先弄懂?dāng)?shù)據(jù)流向再思考功能代碼放哪里2.1 三層架構(gòu)還是簡(jiǎn)單分層教學(xué)項(xiàng)目不需要過(guò)度設(shè)計(jì)拿到學(xué)生信息管理系統(tǒng)需求后很多人的第一反應(yīng)是建Model、DAL、BLL、UI四個(gè)類庫(kù)工程做成教科書式的三層架構(gòu)。但實(shí)際上Web Forms項(xiàng)目更偏向事件驅(qū)動(dòng)和頁(yè)面中心化你如果強(qiáng)行把每一層都拆成獨(dú)立項(xiàng)目最后的結(jié)果是改一個(gè)學(xué)生的姓名長(zhǎng)度校驗(yàn)要跨三個(gè)項(xiàng)目來(lái)回切換調(diào)試時(shí)光是定位代碼就得花不少時(shí)間。這套資源的代碼組織方式更貼近一線生產(chǎn)環(huán)境的真實(shí)狀態(tài)站點(diǎn)根目錄下面直接建App_Code文件夾公共數(shù)據(jù)訪問(wèn)類放在這個(gè)文件夾里比如SqlHelper.cs負(fù)責(zé)所有數(shù)據(jù)庫(kù)操作頁(yè)面aspx.cs后置代碼直接調(diào)用SqlHelper。如果你在維護(hù)老系統(tǒng)大概率看到的也是這種結(jié)構(gòu)——頁(yè)面代碼厚一點(diǎn)但勝在直接按CtrlF搜索SQL語(yǔ)句就能找到數(shù)據(jù)從哪里來(lái)。想從這套系統(tǒng)里學(xué)習(xí)分層思想先從這個(gè)平鋪結(jié)構(gòu)開始理解后面再自己動(dòng)手往三層架構(gòu)遷移也不遲。我個(gè)人的建議是如果你只是做課程設(shè)計(jì)或者給學(xué)校做一個(gè)內(nèi)部使用的系統(tǒng)保持單項(xiàng)目加App_Code就夠用。因?yàn)閃eb Forms的頁(yè)面生命周期天然帶來(lái)了一定程度的表現(xiàn)層與邏輯層分離你完全可以把數(shù)據(jù)校驗(yàn)、權(quán)限判斷邏輯寫到獨(dú)立的.cs文件甚至寫成靜態(tài)工具類沒(méi)必要物理分層。真要分也優(yōu)先把SqlHelper獨(dú)立出來(lái)這是這套代碼里最值得復(fù)用的部分。2.2 數(shù)據(jù)庫(kù)腳本與連接串表結(jié)構(gòu)怎么設(shè)計(jì)最省心學(xué)生信息管理系統(tǒng)的核心數(shù)據(jù)無(wú)非三個(gè)實(shí)體用戶、學(xué)生、成績(jī)。這套資源的數(shù)據(jù)庫(kù)腳本基本圍繞以下三張表展開表名用途關(guān)鍵字段說(shuō)明UserInfo登錄賬戶表UserId, UserName, Password, RoleTypeRoleType區(qū)分管理員和普通教師StudentInfo學(xué)生基本信息StudentId, Name, Gender, ClassName, Phone, Email展示列表核心數(shù)據(jù)源ScoreInfo成績(jī)記錄表ScoreId, StudentId, CourseName, Score按學(xué)生ID外鍵關(guān)聯(lián)StudentInfo建表腳本里有一個(gè)值得注意的細(xì)節(jié)學(xué)生表的StudentId使用自增int作為主鍵而不是直接拿學(xué)號(hào)字符串做主鍵。這樣做的好處是關(guān)聯(lián)查詢性能好、索引小而且學(xué)號(hào)格式調(diào)整的時(shí)候不需要?jiǎng)油怄I關(guān)系。如果直接用學(xué)號(hào)字符串做主鍵看似省事但到了跨表關(guān)聯(lián)查詢時(shí)字符串比較比int慢是實(shí)打?qū)嵉牟顒e。連接字符串集中寫在Web.config里這一點(diǎn)幾乎任何Web Forms項(xiàng)目都通用。注意providerName屬性一定要寫對(duì)configuration connectionStrings add nameStudentDB connectionStringData Source.;Initial CatalogStudentManager;Integrated SecurityTrue providerNameSystem.Data.SqlClient / /connectionStrings /configuration開發(fā)階段用Integrated SecurityTrue可以減少賬號(hào)管理的麻煩但當(dāng)你把網(wǎng)站部署到服務(wù)器上網(wǎng)站應(yīng)用池運(yùn)行賬號(hào)如果是IIS默認(rèn)的ApplicationPoolIdentity它并不一定有訪問(wèn)SQL Server的權(quán)限這時(shí)候要么給該賬號(hào)授權(quán)要么改成SQL Server賬號(hào)登錄形式add nameStudentDB connectionStringData Source服務(wù)器IP;Initial CatalogStudentManager;User IDsa;Password你的密碼 providerNameSystem.Data.SqlClient /這里還有個(gè)容易踩的小坑如果你用的是SQL Server Express且服務(wù)端和數(shù)據(jù)庫(kù)不在同一臺(tái)機(jī)器連接串里建議加上TrustServerCertificateTrue否則從.NET Framework 4.7開始TLS協(xié)議協(xié)商失敗會(huì)直接報(bào)證書鏈錯(cuò)誤。另外連接超時(shí)時(shí)間也建議寫清楚默認(rèn)15秒在校園網(wǎng)環(huán)境下偶爾不夠用可以設(shè)置Connect Timeout30。3. 登錄鑒權(quán)與會(huì)話管理FormsAuthentication和Session怎么選3.1 登錄邏輯的正確姿勢(shì)票據(jù)優(yōu)先Session做輔助這套學(xué)生信息系統(tǒng)的登錄模塊其實(shí)可以拆成兩種典型方案。第一種是純Session保存登錄狀態(tài)登錄成功往Session里塞一個(gè)實(shí)體對(duì)象后續(xù)頁(yè)面判斷Session是否為空來(lái)確認(rèn)登錄。第二種是FormsAuthentication寫加密票據(jù)。兩種方案都可以跑通但從系統(tǒng)穩(wěn)定性和安全性角度我更推薦后者。純Session的問(wèn)題前面提過(guò)這里的坑實(shí)際發(fā)生在你部署到IIS之后。IIS應(yīng)用池默認(rèn)有閑置超時(shí)設(shè)置默認(rèn)20分鐘一旦應(yīng)用池被回收所有內(nèi)存中的Session全部清空。用戶可能正在錄成績(jī)一個(gè)提交回來(lái)就被踢回登錄頁(yè)之前輸入的數(shù)據(jù)全部丟失這在教學(xué)演示現(xiàn)場(chǎng)直接翻車。而FormsAuthentication的票據(jù)以Cookie形式存在客戶端應(yīng)用池回收之后票據(jù)仍然有效用戶感知不到服務(wù)端重啟。核心登錄代碼可以這樣寫private void DoLogin(string userName, string password) { // 從數(shù)據(jù)庫(kù)驗(yàn)證用戶名密碼這里省略查詢過(guò)程 bool isValid UserDao.ValidateUser(userName, password); if (!isValid) { lblMessage.Text 用戶名或密碼錯(cuò)誤; return; } // 查詢?cè)撚脩舻慕巧糜诤竺鏅?quán)限判斷 string role UserDao.GetUserRole(userName); FormsAuthenticationTicket ticket new FormsAuthenticationTicket( 1, // Ticket版本號(hào) userName, // 用戶名 DateTime.Now, // 簽發(fā)時(shí)間 DateTime.Now.AddMinutes(30), // 過(guò)期時(shí)間 true, // 是否持久化Cookie role, // 用戶角色放入U(xiǎn)serData FormsAuthentication.FormsCookiePath ); string encryptedTicket FormsAuthentication.Encrypt(ticket); HttpCookie authCookie new HttpCookie( FormsAuthentication.FormsCookieName, encryptedTicket ); Response.Cookies.Add(authCookie); Response.Redirect(Default.aspx); }FormsAuthentication.Encrypt會(huì)對(duì)票據(jù)做序列化和簽名加密客戶端無(wú)法篡改內(nèi)容。把角色信息放進(jìn)UserData屬性里后續(xù)從Cookie解密就能直接讀到用戶角色不用每次請(qǐng)求都去查一遍數(shù)據(jù)庫(kù)這套邏輯在性能上也有好處。過(guò)期時(shí)間30分鐘代表從簽發(fā)時(shí)刻開始算的絕對(duì)過(guò)期。如果你希望用戶長(zhǎng)時(shí)間不操作后才失效適合改成滑動(dòng)過(guò)期模式每次用戶發(fā)起請(qǐng)求時(shí)檢查剩余時(shí)間若少于一半就重新簽發(fā)新票據(jù)。3.2 頁(yè)面級(jí)權(quán)限校驗(yàn)用BasePage統(tǒng)一收口學(xué)生管理系統(tǒng)通常有兩種角色管理員能增刪改學(xué)生信息普通教師只能查看和錄成績(jī)。權(quán)限控制如果放在每個(gè)頁(yè)面里重復(fù)判斷代碼會(huì)散落得到處都是這套系統(tǒng)里比較好的做法是在項(xiàng)目里建一個(gè)BasePage基類所有業(yè)務(wù)頁(yè)面繼承它。public class BasePage : System.Web.UI.Page { /// summary /// 當(dāng)前頁(yè)面要求的角色子頁(yè)面繼承后設(shè)置 /// /summary public string RequireRole { get; set; } protected override void OnLoad(EventArgs e) { base.OnLoad(e); // 解密票據(jù)取出角色信息 HttpCookie authCookie Request.Cookies[FormsAuthentication.FormsCookieName]; if (authCookie null) { Response.Redirect(Login.aspx); return; } FormsAuthenticationTicket ticket FormsAuthentication.Decrypt(authCookie.Value); if (ticket null || ticket.Expired) { Response.Redirect(Login.aspx); return; } string userRole ticket.UserData; Session[CurrentUserRole] userRole; // 頁(yè)面設(shè)置了角色要求才校驗(yàn) if (!string.IsNullOrEmpty(RequireRole) !userRole.Equals(RequireRole, StringComparison.OrdinalIgnoreCase)) { Response.Redirect(Unauthorized.aspx); } } }業(yè)務(wù)頁(yè)面只需要繼承BasePage并指定角色要求比如管理頁(yè)面寫public partial class StudentAddPage : BasePage { this.RequireRole admin; }權(quán)限就自動(dòng)生效。這樣做的價(jià)值是權(quán)限判斷邏輯只有一個(gè)修改點(diǎn)后面如果要加新角色只需要調(diào)整基類里的比較邏輯業(yè)務(wù)代碼一行都不用動(dòng)。菜單的渲染也可以用類似思路在MasterPage母版頁(yè)里判斷角色后控制菜單項(xiàng)Visible屬性。管理員看到完整菜單普通老師只能看到查詢和成績(jī)錄入這比一個(gè)個(gè)頁(yè)面去改鏈接要省事得多。4. 核心功能實(shí)現(xiàn)學(xué)生信息增刪改查與GridView實(shí)戰(zhàn)4.1 GridView數(shù)據(jù)綁定用代碼綁不用SqlDataSource控件學(xué)生信息管理系統(tǒng)的主體頁(yè)面就是學(xué)生列表。用GridView展示數(shù)據(jù)是最常規(guī)的做法但數(shù)據(jù)綁定方式有兩種各有使用場(chǎng)景。直接在aspx頁(yè)面里拖一個(gè)SqlDataSource控件配置好SQL語(yǔ)句就能跑這種方案適合微軟快速演示Demo的場(chǎng)景而實(shí)際開發(fā)維護(hù)中我?guī)缀蹩偸沁x擇在后臺(tái)代碼里手動(dòng)綁定Grid。原因很簡(jiǎn)單SqlDataSource的SQL語(yǔ)句寫在aspx頁(yè)面里沒(méi)有編譯期檢查改字段名漏改一個(gè)地方就是運(yùn)行時(shí)才發(fā)現(xiàn)。而后臺(tái)代碼綁定方式可以充分利用Visual Studio的斷點(diǎn)調(diào)試逐步檢查DataTable里到底返回了什么出了問(wèn)題一眼就能看到是哪一步少了條件。下面是列表綁定的標(biāo)準(zhǔn)寫法public partial class StudentList : System.Web.UI.Page { protected void Page_Load(object sender, EventArgs e) { if (!IsPostBack) { BindStudentList(); } } private void BindStudentList() { string sql SELECT StudentId, Name, Gender, ClassName, Phone, Email FROM StudentInfo ORDER BY StudentId DESC; DataTable dt SqlHelper.ExecuteDataTable(sql); GridView1.DataSource dt; GridView1.DataBind(); } }IsPostBack的判斷可以說(shuō)決定了你這個(gè)頁(yè)面50%的穩(wěn)定性。GridView的分頁(yè)、排序、編輯操作全部會(huì)觸發(fā)PostBack回發(fā)如果你不加這個(gè)判斷每點(diǎn)一次分頁(yè)按鈕頁(yè)面都要重新綁定一次數(shù)據(jù)用戶已經(jīng)輸入的查詢條件也會(huì)被覆蓋。初次加載時(shí)綁定一次后續(xù)事件里按需手動(dòng)綁定這是Web Forms頁(yè)面開發(fā)的基本習(xí)慣這套系統(tǒng)的每個(gè)列表頁(yè)都應(yīng)該遵守這個(gè)原則。數(shù)據(jù)綁定后的aspx頁(yè)面里GridView配置也要注意幾個(gè)屬性asp:GridView IDGridView1 runatserver AutoGenerateColumnsFalse DataKeyNamesStudentId AllowPagingTrue PageSize10 OnPageIndexChangingGridView1_PageIndexChanging OnRowDeletingGridView1_RowDeleting OnRowEditingGridView1_RowEditing OnRowUpdatingGridView1_RowUpdating OnRowCancelingEditGridView1_RowCancelingEdit Columns asp:BoundField DataFieldName HeaderText姓名 / asp:BoundField DataFieldGender HeaderText性別 / asp:BoundField DataFieldClassName HeaderText班級(jí) / asp:BoundField DataFieldPhone HeaderText聯(lián)系電話 / asp:CommandField ShowEditButtonTrue ShowDeleteButtonTrue / /Columns /asp:GridViewDataKeyNames是刪除和更新操作的命脈它指定了主鍵字段名事件觸發(fā)后GridView會(huì)通過(guò)DataKeys集合把當(dāng)前主鍵值傳遞出來(lái)。如果你沒(méi)有設(shè)置這個(gè)屬性而又在刪除事件里去讀取DataKeys就會(huì)拋索引超出范圍異常。AutoGenerateColumns改為False之后列表列完全由Columns集合控制避免出現(xiàn)重復(fù)的數(shù)據(jù)列。4.2 編輯、刪除、分頁(yè)的事件順序先弄清觸發(fā)流程再寫代碼GridView看似只是一個(gè)控件實(shí)際上它的事件觸發(fā)有一套嚴(yán)格的順序邏輯理解這套順序比記憶代碼重要得多。用戶點(diǎn)擊編輯按鈕時(shí)觸發(fā)的是RowEditing事件此時(shí)GridView進(jìn)入編輯態(tài)把普通列切換為輸入框用戶修改完點(diǎn)擊更新后才觸發(fā)RowUpdating事件?？釉谟诤芏嘈率职迅逻壿媽懺诹薘owEditing里結(jié)果點(diǎn)編輯就馬上改數(shù)據(jù)庫(kù)完全不是期望行為。刪除的完整處理代碼如下protected void GridView1_RowDeleting(object sender, GridViewDeleteEventArgs e) { int studentId Convert.ToInt32(GridView1.DataKeys[e.RowIndex].Value); string sql DELETE FROM StudentInfo WHERE StudentIdId; SqlHelper.ExecuteNonQuery(sql, new SqlParameter(Id, studentId)); BindStudentList(); }這里e.RowIndex是用戶點(diǎn)擊刪除按鈕所在行的索引GridView1.DataKeys[e.RowIndex].Value拿到的就是該行對(duì)應(yīng)的主鍵。有一種常見的錯(cuò)誤寫法是嘗試從行單元格中提取ID這在設(shè)置了DataKeyNames之后其實(shí)拿不到數(shù)據(jù)因?yàn)橹麈I默認(rèn)不渲染到HTML里。如果你確實(shí)看到ID列顯示在頁(yè)面上那多半是AutoGenerateColumns還在生效。編輯更新的處理要稍微多一點(diǎn)步驟protected void GridView1_RowEditing(object sender, GridViewEditEventArgs e) { GridView1.EditIndex e.NewEditIndex; BindStudentList(); } protected void GridView1_RowUpdating(object sender, GridViewUpdateEventArgs e) { int studentId Convert.ToInt32(GridView1.DataKeys[e.RowIndex].Value); TextBox txtName GridView1.Rows[e.RowIndex].FindControl(txtName) as TextBox; TextBox txtPhone GridView1.Rows[e.RowIndex].FindControl(txtPhone) as TextBox; string sql UPDATE StudentInfo SET NameName, PhonePhone WHERE StudentIdId; SqlHelper.ExecuteNonQuery(sql, new SqlParameter(Name, txtName.Text.Trim()), new SqlParameter(Phone, txtPhone.Text.Trim()), new SqlParameter(Id, studentId)); GridView1.EditIndex -1; BindStudentList(); }更新后把EditIndex設(shè)回-1是必須的否則GridView停留在編輯模式頁(yè)面沒(méi)有視覺(jué)上的刷新反饋。FindControl查找的控件ID必須在編輯模板里真實(shí)存在如果你在TemplateField的EditItemTemplate里寫的是txtName在ItemTemplate里寫的是lblName那FindControl用txtName就只能在編輯狀態(tài)下找得到。模板字段里控件放錯(cuò)位置同樣會(huì)導(dǎo)致FindControl返回null空引用異常就在所難免。分頁(yè)事件處理也很簡(jiǎn)單但少寫一行就會(huì)出現(xiàn)翻頁(yè)后數(shù)據(jù)不動(dòng)的怪象protected void GridView1_PageIndexChanging(object sender, GridViewPageEventArgs e) { GridView1.PageIndex e.NewPageIndex; BindStudentList(); }把新頁(yè)索引賦值到GridView的PageIndex之后再重新綁定邏輯就完整了。忘了賦值的情況很常見用戶點(diǎn)了第二頁(yè)GridView內(nèi)部PageIndex沒(méi)變重新綁定的還是第一頁(yè)數(shù)據(jù)。而且Delete最后一頁(yè)的最后一條數(shù)據(jù)后GridView當(dāng)前PageIndex可能超過(guò)實(shí)際頁(yè)數(shù)需要重置為0否則頁(yè)面渲染空白列表這個(gè)問(wèn)題好在排查但確實(shí)容易忽略。5. ASP.NET學(xué)生信息管理常見坑與排查從編譯錯(cuò)誤到白屏一次說(shuō)清5.1 中文亂碼頁(yè)面文字全是問(wèn)號(hào)數(shù)據(jù)庫(kù)里卻正常顯示現(xiàn)象網(wǎng)站頁(yè)面上所有中文顯示為問(wèn)號(hào)或者亂碼錕斤拷但用SQL Server Management Studio直接查詢數(shù)據(jù)庫(kù)中文完全正常。原因這個(gè)問(wèn)題的根源往往不是數(shù)據(jù)庫(kù)字符集而是ASP.NET頁(yè)面輸出的編碼與瀏覽器解析編碼不一致。Web.config里如果缺少globalization配置ASP.NET默認(rèn)按請(qǐng)求頭里的Accept-Charset來(lái)響應(yīng)某些情況下瀏覽器發(fā)送的編碼與頁(yè)面實(shí)際編碼對(duì)不上中文就亂了。更隱蔽的原因是數(shù)據(jù)庫(kù)的排序規(guī)則和頁(yè)面編碼都是好的但代碼里SQL字符串拼接時(shí)中間層把Unicode字符串轉(zhuǎn)換成了非Unicode字符集再發(fā)給SQL Server。解決先檢查Web.config中是否顯式聲明了編碼system.web globalization requestEncodingutf-8 responseEncodingutf-8 fileEncodingutf-8 / /system.web再確認(rèn)每個(gè)aspx頁(yè)面頭部聲明% Page CodePage65001 %。如果這兩步都做了還是亂去看SQL Server表的Collation是否為Chinese_PRC_CI_AS不是的話執(zhí)行ALTER TABLE StudentInfo ALTER COLUMN Name NVARCHAR(50) COLLATE Chinese_PRC_CI_AS。最后把所有拼接SQL改成參數(shù)化查詢往往參數(shù)化改完亂碼也跟著消失。5.2 GridView刪除不刷新按了刪除沒(méi)反應(yīng)重新打開數(shù)據(jù)還在現(xiàn)象點(diǎn)刪除按鈕頁(yè)面沒(méi)有明顯變化也不報(bào)錯(cuò)但刷新頁(yè)面后記錄還在說(shuō)明刪除并沒(méi)有執(zhí)行。原因最常見的是aspx頁(yè)面里的GridView缺少OnRowDeletingGridView1_RowDeleting的事件綁定。后臺(tái)代碼雖然寫了RowDeleting方法但前臺(tái)沒(méi)有把事件掛上去用戶點(diǎn)擊刪除按鈕時(shí)事件根本不會(huì)觸發(fā)。另一種情況是刪除執(zhí)行了但事件末尾忘了調(diào)用BindStudentList()重新加載列表頁(yè)面看起來(lái)像沒(méi)刪除一樣。解決打開aspx頁(yè)面檢查GridView標(biāo)簽里OnRowDeleting屬性是否指向了正確的方法名。確認(rèn)方法名一致后再看事件代碼末尾有沒(méi)有重新綁定數(shù)據(jù)protected void GridView1_RowDeleting(object sender, GridViewDeleteEventArgs e) { int studentId Convert.ToInt32(GridView1.DataKeys[e.RowIndex].Value); string sql DELETE FROM StudentInfo WHERE StudentIdId; SqlHelper.ExecuteNonQuery(sql, new SqlParameter(Id, studentId)); BindStudentList(); // 重新綁定數(shù)據(jù) }如果刪除的是最后一頁(yè)的最后一行在前面4.2節(jié)提過(guò)刪除后PageIndex要重置為0。不然GridView分頁(yè)邏輯計(jì)算出0頁(yè)中沒(méi)有任何行頁(yè)面干干凈凈但用戶并不知道發(fā)生了什么。5.3 Session超時(shí)掉登錄填了半小時(shí)的信息提交后被踢回登錄頁(yè)現(xiàn)象用戶在錄成績(jī)頁(yè)面停留較長(zhǎng)時(shí)間填寫了很多字段點(diǎn)擊保存時(shí)頁(yè)面跳回Login.aspx填寫的數(shù)據(jù)全部丟失。原因ASP.NET默認(rèn)Session超時(shí)時(shí)間為20分鐘。所謂超時(shí)是指兩次請(qǐng)求之間的間隔超過(guò)20分鐘而不是從登錄開始算20分鐘。用戶雖然一直在頁(yè)面上打字但沒(méi)有向服務(wù)器發(fā)起請(qǐng)求Session沒(méi)有活躍。如果你用的是Session來(lái)保存用戶登錄狀態(tài)一旦超時(shí)Session[CurrentUser]就被清空任何后續(xù)請(qǐng)求都會(huì)因?yàn)闄?quán)限校驗(yàn)失敗而被重定向到登錄頁(yè)。解決第一種方案是延長(zhǎng)Session超時(shí)時(shí)間system.web sessionState modeInProc timeout60 cookielessfalse / /system.web同時(shí)把FormsAuthenticationTicket的過(guò)期時(shí)間也調(diào)整到一致。第二種方案更推薦就是本章前面說(shuō)過(guò)的滑動(dòng)過(guò)期模型在Global.asax中每次請(qǐng)求時(shí)刷新票據(jù)。第三種真正一勞永逸的做法是放棄Session保存登錄態(tài)改用FormsAuthentication的票據(jù)因?yàn)槠睋?jù)存在客戶端Cookie里不受服務(wù)端Session過(guò)期影響。只要Cookie還在即使Session被回收了用戶下次請(qǐng)求時(shí)可以通過(guò)重新解密票據(jù)嘗試恢復(fù)登錄狀態(tài)。5.4 部署后連不上SQL Server本地正常服務(wù)器上報(bào)錯(cuò)現(xiàn)象本地開發(fā)環(huán)境F5運(yùn)行一切正常發(fā)布到服務(wù)器或者拷給同學(xué)電腦后提示“在建立到服務(wù)器的連接時(shí)出錯(cuò)。在建立連接之前出現(xiàn)網(wǎng)絡(luò)相關(guān)或特定于實(shí)例的錯(cuò)誤”之類信息。原因原因通常有三個(gè)。第一SQL Server只啟用了Windows身份認(rèn)證模式但連接串里寫的是SQL賬號(hào)方式登錄自然失敗。第二目標(biāo)機(jī)器的SQL Server沒(méi)有啟用TCP/IP協(xié)議默認(rèn)只開了Shared Memory。第三沒(méi)有配置SQL Server允許遠(yuǎn)程連接特別是Express版本默認(rèn)禁用遠(yuǎn)程連接。解決按順序排查。第一步在目標(biāo)機(jī)器上用SQL Server Management Studio嘗試用連接串里的賬號(hào)密碼登錄如果登錄失敗問(wèn)題出在SQL Server這邊不是網(wǎng)站代碼的問(wèn)題。第二步打開SQL Server Configuration Manager查看SQL Server網(wǎng)絡(luò)配置里的TCP/IP協(xié)議是否已啟用。第三步右鍵單擊TCP/IP進(jìn)入IP地址選項(xiàng)卡把IPAll里的TCP端口設(shè)置為1433。最后檢查Windows防火墻是否放行了1433端口這一步最容易被忽略雖然服務(wù)器內(nèi)部能連上但外面訪問(wèn)被防火墻攔截。5.5 ViewState體積過(guò)大頁(yè)面數(shù)據(jù)量不大但加載特別慢現(xiàn)象學(xué)生列表只有幾百條記錄但用瀏覽器開發(fā)者工具查看網(wǎng)絡(luò)請(qǐng)求發(fā)現(xiàn)返回的HTML體積非常大頁(yè)面加載要好幾秒。在HTML源碼里能看到一個(gè)很大的隱藏字段內(nèi)容是一長(zhǎng)串base64編碼。原因Web Forms運(yùn)行時(shí)默認(rèn)會(huì)把控件狀態(tài)序列化到一個(gè)名為__VIEWSTATE的隱藏字段里。GridView數(shù)據(jù)綁定后每一行的狀態(tài)信息都會(huì)被序列化進(jìn)去數(shù)據(jù)越多ViewState越大。如果還開啟了GridView的排序和分組ViewState會(huì)膨脹得更快。解決業(yè)務(wù)列表頁(yè)面完全不需要跨回發(fā)保留數(shù)據(jù)每次回發(fā)都重新查庫(kù)綁定即可因此可以直接關(guān)閉GridView的ViewStateasp:GridView IDGridView1 runatserver EnableViewStatefalse ...其余配置保持不變 /加上這個(gè)屬性后頁(yè)面DOM體積通常會(huì)縮小一半以上。但要注意如果GridView開啟了編輯模板編輯狀態(tài)下輸入框的值需要保留到回發(fā)后操作這時(shí)關(guān)閉ViewState可能導(dǎo)致編輯狀態(tài)下的輸入內(nèi)容丟失。折中方案是保留ViewState但在頁(yè)面生命周期里提前綁定數(shù)據(jù)減少ViewState回傳后的重新加載次數(shù)實(shí)際效果沒(méi)有直接關(guān)閉明顯。如果你的系統(tǒng)確實(shí)依賴ViewState做狀態(tài)保留可以用ViewStateModeDisabled配合個(gè)別控件單獨(dú)開啟這也是ASP.NET 4.0以后更精細(xì)的控制方式。6. 部署發(fā)布與項(xiàng)目改造從能跑到跑得順的關(guān)鍵動(dòng)作學(xué)生管理系統(tǒng)做完只是第一步能順利部署到別的機(jī)器上跑起來(lái)才是真正水平的體現(xiàn)。發(fā)布前我會(huì)習(xí)慣性檢查三件事。第一件是連接字符串本地集成認(rèn)證改成明確的SQL登錄賬號(hào)第二件是Web.config里的debug開關(guān)system.web compilation debugfalse targetFramework4.7.2 / /system.webdebug設(shè)為false能提升運(yùn)行性能防止異常堆棧直接暴露給最終用戶。第三件是發(fā)布方式用Visual Studio的“發(fā)布”功能編譯所有后置代碼不要直接把源碼目錄拷過(guò)去。源碼拷過(guò)去會(huì)連帶aspx.cs文件一起暴露別人能看到你的密碼哈希邏輯和數(shù)據(jù)庫(kù)連接賬號(hào)這是很常見的安全翻車點(diǎn)。項(xiàng)目改造方面如果這套系統(tǒng)將來(lái)要繼續(xù)升級(jí)優(yōu)先做兩件事。一是把SqlHelper統(tǒng)一換成參數(shù)化訪問(wèn)把所有SQL語(yǔ)句帶值拼接的代碼全找出來(lái)改掉這個(gè)動(dòng)作能堵住絕大多數(shù)注入漏洞。二是把登錄密碼存儲(chǔ)從純MD5升級(jí)為帶鹽的哈希public static string ComputeHash(string password, string salt) { byte[] bytes Encoding.UTF8.GetBytes(salt password); using (SHA256Managed sha new SHA256Managed()) { byte[] hash sha.ComputeHash(bytes); return Convert.ToBase64String(hash); } }鹽值可以按用戶來(lái)生成并存入用戶表這樣即使用戶密碼相同最終哈希值也不同徹底避免批量撞庫(kù)。這是我把這個(gè)教學(xué)項(xiàng)目改造后最滿意的一個(gè)動(dòng)作——改動(dòng)量小安全收益大。最后給所有還在跟Web Forms搏斗的同行一句實(shí)實(shí)在在的建議遇到頁(yè)面表現(xiàn)和代碼邏輯不一致的情況先打開瀏覽器的F12開發(fā)者工具看Network面板里的請(qǐng)求和響應(yīng)內(nèi)容再回代碼里查事件綁定。這套學(xué)生信息管理系統(tǒng)的所有坑幾乎都能通過(guò)F12加斷點(diǎn)的組合定位到具體原因。從那以后我每次拿到這一類老項(xiàng)目第一件事就是掃一遍所有aspx頁(yè)面里事件是否綁定完整再把所有拼接SQL換成參數(shù)化查詢這兩個(gè)步驟做完項(xiàng)目立馬穩(wěn)定一大截希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取