文章目錄
- 1. 使用者配置的效能
- 2. 使用者配置如何儲存資料
- 3. 使用者配置和驗證
在 ASP.NET 1.x 中,儲存使用者資訊唯一可行的方式是建立你自己的資料訪問組件,這很有用。從 ASP.NET 2.0 開始,又多了一個選擇,那就是使用使用者配置。ASP.NET 會自動使用一個背景資料來源來處理指定使用者的資料(讀取、更新)。
從概念上看,使用者配置和自訂資料群組件非常類似,但它更為簡介方便。它和 ASP.NET 驗證模型渾然一體,當需要時,使用者資訊會自動獲得,如果使用者資訊被修改過,當前請求結束時會自動被寫會資料庫中。
在使用使用者配置之前,你需要仔細對它進行評估。
1. 使用者配置的效能
ASP.NET 使用者配置功能的目標就是提供一個透明的方式系統管理使用者的資訊,你不需要使用 ADO.NET 資料類編寫自己的資料庫存取碼。遺憾的是,很多功能看上去方便,但效能和可擴充性卻不盡如人意。
使用者配置的擴充性問題完全取決於你需要儲存的資料量和你計劃訪問資料的頻率。
使用者配置通過兩種方式加入網頁的生命週期:
- 程式中第一次訪問使用者設定物件時,ASP.NET 會從資料庫取回目前使用者的所有配置資料。至此,後續操作再也無需訪問資料庫
- 如果更改了任意的使用者配置資料,更新會延遲到頁面處理完成之後進行。PreRender、PreRenderComplete、Unload 事件釋放了當前頁面之後,使用者配置被寫回資料庫
使用者配置功能沒有與緩衝整合,因此每次使用使用者配置資料的請求都需要一次資料庫連接。
下面兩個條件都成立,使用者配置效能最佳:
- 只有相對較少的訪問使用者配置資料的頁面
- 只儲存少量資料
反之,使用者配置的執行效率就會下降:
- 大量的頁面需要訪問使用者配置資訊
- 儲存大量的資訊。如果一次請求只需要其中一小部分資料,效率會更低(使用者配置模型總是會取回使用者配置資訊的所有部分)
2. 使用者配置如何儲存資料
其實,使用者配置如何被序列化才是它真正的限制。ASP.NET 預設包含的使用者配置提供者將使用者配置資訊序列化為一個資料區塊,並作為一個單獨欄位插入到資料庫中。比如,序列化地址資訊,會得到類似下面的結果:
Marty Soren315 Southpart DriveLompocCalifornia93436U.S.A
另外一個欄位指明每一個值從什麼地方開始,在什麼地方結束:
Name:S:0:11:Street:11:19:City:S:36:10:ZipCode:S:46:5:Country:S:51:6
這種方式給了程式員足夠的靈活性來儲存任何類型的資料,但在其他程式中使用這些資料會變得非常困難。當然,你可以編寫自訂的解析代碼,但這過程依賴於你的資料量和資料類型,過程可能非常枯燥和冗長。
這種私人的資料格式,在其他程式比如 Word 中就無法建立客戶列表了,也不可能執行查詢來過濾這些使用者配置資料或排序,你更不能通過查詢來獲得指定城市中的所有使用者。不過,解決方案有兩種:
- 使用自訂資料群組件代替使用者配置,在資料庫中儲存和擷取資料
- 建立一個自訂的使用者配置提供者,以使用你的資料庫結構描述來儲存資訊
方案二仍允許你的頁面使用使用者配置模型。實際上,你可以建立一個使用 SQLProfileProvider 的標準使用者配置序列化方案,之後再將其切換成自訂的提供者。整個切換無需修改任何代碼,只需修改 web.config 配置。
3. 使用者配置和驗證
使用者配置和自訂的資料群組件很自然會被放在一起比較。很明顯,資料群組件更加靈活。不僅可以維護使用者資訊、儲存其他類型的資訊、並執行更加複雜的任務。
ASP.NET 提供的標準使用者配置提供者(SQLProfileProvider )沒有提供太多額外的功能。下面的列表是自訂資料群組件可以很容易添加的功能,但 SQLProfileProvider 中是沒有的。如果你需要其中任意功能,就得放棄使用者配置,或者你需要建立一個自訂的使用者配置程式:
- 加密:使用者配置資料可以被序列化為字串、XML或者二進位,但它仍然是原始的文本資料。如果有敏感資訊,你唯一的選擇是加密之後再進行儲存,這導致你必須在你的代碼中放入加密邏輯,這會是你不希望發生的
- 驗證:你無法限制使用者配置裡儲存的資訊類型。你需要使用其他工具(例如驗證控制項或自訂的資料類)防止無效資料
- 緩衝:你不能將從資料庫取出的資訊儲存在記憶體中,雖然可以複製到緩衝中,但跟蹤這些資訊會非常困難
- 審核:設計一個自訂資料群組件時,你可以添加任何登入或者跟蹤代碼。可以使用這種方式診斷意外的錯誤或者監控 Web 程式的效能。如果你想在使用者配置裡使用這種功能,你需要建立一個自訂的使用者配置程式,並在其中包含登入代碼