一定要使用BasePage

ASP.NET 比起傳統ASP網頁最大的好處之一，就是可以用物件導向的方式來設計網頁應用程式，這使得ASP.NET網頁的架構可以比ASP擁有更大的彈性。
一般我們建立一個Web Application後總是會加入許多不同的頁面，雖然看上去每個頁面都有各自不同的功能，但是仔細瞧瞧你一定會發現每個頁面都會有共同的特性或功能，把這些共同的行為規畫在物件導向的繼承架構下可以建立更完善的系統模組，我的偶像維克大隊長就發生這樣的一個故事。

維克大隊長又接到新的任務，這次的客戶可真是有夠難搞。
「我們需要一個報表查詢系統，而且每個頁面功能都要檢查使用者的權限以免有人會在我們的系統上做壞事。」客戶這麼說。
這簡單，只要在每個頁面貼上一段檢查權限的函式就好了，不過維克大隊長選擇了更好的方法，他先寫了一個繼承System.Web.UI.Page的BasePage頁面，並且在OnPreLoad事件中加入檢查權限的函式。

public class BasePage : System.Web.UI.Page { public BasePage():base() { } protected override void OnPreLoad(EventArgs e) { base.OnPreLoad(e); if (this.ValidatePermission() == false) { throw new Exception("滾吧!!你還沒有獲得這個頁面的授權!!"); } } protected virtual bool ValidatePermission() { return false; } }

然後在每個後來加上去的功能頁面都繼承BasePage再複寫ValidatePermission()
public partial class _Default : BasePage { protected void Page_Load(object sender, EventArgs e) { this.DataBind(); } protected override bool ValidatePermission() { If( User.Name == "維克大隊長") { return true; } else { return false; } } }

這樣一來只要所有繼承BasePage的網頁都有的檢查的功能，真是聰明，而且萬一那個應死的客戶又企圖加上任何共用的功能時只要修改BasePage就可以反應在所有頁面上，結論是使用BasePage有益無害，不管是多小的案子都應該採用這種方式來開發，就算BasePage暫時還也沒任何功能也一樣。

最後維克大隊長又漂亮的完成了他的任務。

程式控制存取 Web.config 應用程式設定檔

在一般的 Web-base 應用系統中我們總是會用 Web.config 來設定各種環境配置，尤其是在 <appSettings> 區段中可以允許自由的加入自定的 key/value 成對參數，在以往.net 1.0 或是 .net 1.1 之下可以很簡的讀取自定參教，然而如果要在程式中以程式控制來寫入 Web.config 卻不太容易，幸運的是在 .net 2.0 中以已增加了若干種物件來支援這些功能，其中 System.Web.Configuration.WebConfigurationManager 物件就俱有操作 Web.config 檔案的能力。

假設在我們範例中的 Web.config 設定如下：
<appSettings> <add key="WebName" value="This is MyWeb" /> <add key="LastUpdate" value="2006-01-01" /> </appSettings>


讀取設定
單純的讀取設定非常的簡單，僅僅只需要一行程式碼
string str = System.Web.Configuration.WebConfigurationManager.AppSettings["WebName"];
這樣我們便可以讀取到 "This is MyWeb" 字串，然後將它運用在程式中任何需要使用的地方。


修改設定
修改設定的步驟稍微多了一點，但是依然非常的簡單
Configuration config = WebConfigurationManager.OpenWebConfiguration("~"); config.AppSettings.Settings["LastUpdate"].Value = DateTime.Noew.ToString("yyyy-MM-dd"); config.Save();
當程式執行到 config.Save(); 的時後就會將所有更變存儲回 Web.config 裏。


真實的應用
現在要討論的是程式中俱備有存取 Web.config 能力可以用來做些什麼..... 嗯.... 也許在一些小型的系統中可以用來直接當做系統參數的存放檔，那麼我們就不再需要另外的 .ini 檔或是 xml 設定檔了不是嗎?
如果寫一個專門控制的 SysConfig 物件然後存放到 Application 變數裏更能突顯它的好處
public class SystemConfiguration { private string m_WebName= string.Empty; private DateTime m_LastUpdate= DateTime.Now; public SystemConfiguration() { this.m_WebName = WebConfigurationManager.AppSettings["WebName"]; this.m_LastUadate = DateTime.Parse(WebConfigurationManager.AppSettings["LastUadate"]); } public void SaveConfig { Configuration config = WebConfigurationManager.OpenWebConfiguration("~"); config.AppSettings.Settings["WebName"].Value = this.m_WebName; config.AppSettings.Settings["LastUpdate"].Value = this.m_LastUpdate; config.Save(); } public string WebName { get { return this.m_WebName; } set { this.m_WebName = value; } } public DateTime LastUadate { get { return this.m_LastUadate; } set { this.m_LastUadate= value; } } }

現在我們有了自定的 SystemConfiguration 物件，剩下的只需要把它加到 Application 中隨時取用。

客制化你的Profile物件

如果在你的系統中每個使用者除了一般的帳號密碼之外，還需要記錄電話、地址等額外的資訊，你可以利用.net 中所提供的 Profile 物件來加入一些新的屬性或是方法。
首先你要繼承 ProfileBase 物件來做到客制化專屬的 Profile 物件，在 ProfileBase 中有SetPropertyValue() 跟 GetPropertyValue() 方法是用來設定跟取得額外的Profile屬性，甚至你可以更簡單的直接用 index 來存取額外屬性。
public class MyProfile : System.Web.Profile.ProfileBase { public MyProfile() { this.TEL = string.Empty; this.Address = string.Empty; } public string TEL { get { return base["TEL"] as string; } set { base["TEL"] = value; } } public string Address { get { return base["Address"] as string; } set { base["Address"] = value; } } }
完成了MyProfile後你還需要在web.config 裏設定使用你改寫過的Profile物件。

<profile inherits="MyProfile">

這樣子你就可以在程式中使用客制化的Profile物件了。

多人共用系統的資料庫存取解決方案

想想看這個狀況。
你正在開發一個系統，這個系統可以供不特定多數人同時上線操作並且修改資料，但是總會有那麼巧的事發生，很可能的有兩個以上的人在同時修改同一筆資料當大家一起按下”確定”按鈕後只有動作最慢的那個人的修改被更新在系統上，其他的人就白作工了。於是你改用資料鎖定的方式企圖防止這種鳥事，現在，當某個人開始修改他選定的資料，那筆資料就會被鎖定直到他修改完成前其他人都不能再修改同一筆資料，太好了事情解決了。不！才沒那麼簡單，要知道人是最難掌握的部份，事情總是會意料之外的困難。

好吃的豬小妹發現 001 號訂單的金額打錯了，於是她打開啟訂單檔案正要修改金額，但是正巧吃飯時間到了，她便頭也不回的往福利社衝過去…..。
這時後哈巴狗夫人接到 001 號訂單的客戶打電話來要加購新產品，但是因為001號訂單被豬小妹開啟而鎖定，所以哈巴狗夫人什麼事也不能做，只能等豬小妹吃飽了再說。
最糟的是獅子王大老闆上班時沒事做，所以他一口氣打開 200 個檔案假裝很忙，但是下班卻忘了把檔案關上，而且跟本沒有人敢去提醒他，結果那 200 個檔案就一直被鎖定直到大老闆想起來後把它們全部關上為止。

從個例子你應該看的出來單純的資料鎖定還不夠，只因為人生有太多的意外，使用者至少會有一百種方法讓你的系統卡在那，注意了我都還沒提到兩個人互相等待對方關檔的死結情況。

無論如何總要想出個一比較好的方式才行，我們可以試試使用時間搓記 (Timestamp) ，每當你將修改內容傳給資料庫的時後，資料庫會為Timestamp欄位產生新的數值，把這個變更用在資料更新的邏輯中問題便可迎刃而解。


假設我們擷取資料的查詢如下
SELECT OrderID, ProductID, Quantity, UnitPrice, [Timestamp] FROM Order WHERE OrderID = @OrderID

那麼更新資料的查詢可以這樣寫
UPDATE Order SET ProductID=@ProductID, Quantity=@Quantity, UnitPrice=@UnitPrice WHERE OrderID=@OrderID AND [Timestamp] = @Timestamp

拿擷取的 Timestamp 代入更新的 @Timestamp 參數，如果有人比你搶先一步 Timestamp 的值就會不同當然更新就不會成功，這時後可以在畫面顯示一個嚇人的說明，「嗨! 你所看到的訂單資料已經過時，確定要更新嗎?」，然後剩下的就讓使用者去決定要怎麼做了。

只有想不到沒有做不到，這個方法真是好，再也不用去管那個該死的資料鎖定問題。