類型安全編碼

當我開始開發Web應用程序我存儲在兩個會話變量類型安全編碼

Session["UserName"]="username"; 
Session["Password"]="paswword-123";

但有人提出我的想法，創造出包含用戶名和密碼屬性和一類用戶的認證細節成功的身份驗證我被要求創建類的實例，並設置UserName和Password屬性並將該實例存儲在會話中。

我被告知會話對象是TypeSafe。有人可以解釋什麼是類型安全編碼和在會話中存儲對象的優點。

來源

2010-11-24 Novice

誰告訴你的？在什麼情況下 - 上述？你有鏈接到一個頁面說的那個？ – Oded 2010-11-24 13:17:09

當我在大學時，我的一位教授告訴我..有什麼不對或無法理解？ – Novice 2010-11-24 13:18:14

基本上，直接在Session["something"]存儲值的經典方法有兩個缺點：

魔術字符串：如果輸錯something，你的代碼編譯好，但你無論是運行時錯誤，或者更糟糕，你的代碼中一個未被注意的錯誤。
鑄造：在閱讀Session["something"]後，您需要將其轉換爲您需要的類型。（這是什麼意思「不是類型安全的」。）

使用存儲在會話中的強類型對象消除了第二個問題。實際上，你的自定義對象仍然需要被投射，但它只有一個投射而不是兩個（或十個）投射，這減少了出錯的可能性。同樣，錯誤的轉換是隻在運行時才被檢測到的。

另一種方法是封裝在靜態屬性的訪問會話變量：

public class MySession { 
    public static string UserName { 
     get { return (string)HttpContext.Current.Session["UserName"]; } 
     set { HttpContext.Current.Session["UserName"] = value; } 
    } 
}

當然，這兩種方法可以結合起來，使您可以在一個共同的對象組相關的屬性（用戶名和密碼）。

來源

2010-11-24 13:25:49 Heinzi

擁有帶2個字段的用戶類可以有很多原因，至於類型安全性，如果您曾在某處輸入Session [「Pasword」]，您將遇到一個不容易找到的錯誤，您將擁有在任何地方檢查兩個參數名稱。你需要它們是正確的，而且它是一個很大的錯誤來源。一旦存儲User對象而不是2個未連接的字符串，您將能夠使用類型安全的代碼（如User.Password），而不是嘗試通過Session中的字符串索引器訪問密碼。此外，如果您的用戶獲得更多的字段，這是很常見的，您只需將它們添加到用戶類，不開始創建新參數&名稱並將它們存儲在會話堆中。

至於類型安全編碼，我認爲http://en.wikipedia.org/wiki/Type_safety應該幫助，或任何其他類型的文章，這是非常受歡迎的主題，我認爲。

另外我不認爲你應該在會話中存儲密碼，取決於你的程序邏輯，但通常密碼應該只用於計算其md5散列，並且以後再也不會使用。

來源

2010-11-24 13:18:15

那麼你是朋友是一半的權利，但我不相信會話本質上是類型安全的。 Session集合存儲Object的實例。因此，您可以存儲任何類型的實例（字符串，int或自定義登錄類），因爲它們都來自對象。但是，當您檢索該對象時，您不知道它是什麼類型，並且在使用它之前需要小心地對它進行轉換，並進行異常處理。如能正常工作：

Session["UserName"] = "Freddy"; 
string theUserName = (string)Session["UserName"];

但是你可以嘗試做以下，這將導致錯誤。

Session["UserName"] new StrangeDataClass(); //Uh Oh, that's not a string. 
string theUserName = (string)Session["UserName"]; //unexpected behaviour based on StrangeDataClass.ToString() implementation.

要解決這個問題，你必須做到以下幾點：

string theUserName = Session["UserName"] as string; 
if (string != null) 
    //The cast worked... 
else 
    //The cast failed, (or the string stored in session was null)

有一個自定義登錄對象稍微解決了這個問題，因爲你只能有一個對象的後顧之憂，和一個鑄造。您還可以使用額外信息輕鬆擴展登錄對象，並且不必再進行強制轉換。

來源

2010-11-24 13:18:59

類型安全編碼

回答

相關問題