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