タイプセーフコーディング

StackOverflow https://stackoverflow.com/questions/4267122

  •  27-09-2019
  •  | 
  •  

質問

Webアプリケーションの開発を開始したとき、ユーザーの認証の詳細を2つのセッション変数に保存しました 

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

しかし、誰かが私に、ユーザー名とパスワードのプロパティを保持するクラスを作成するアイデアを提案し、成功した認証でクラスのインスタンスを作成し、ユーザー名とパスワードのプロパティを設定し、そのインスタンスをセッションに保存するように求められました。

セッションオブジェクトはタイプセーフであると言われています。 TypeSafeコーディングとセッションにオブジェクトを保存する利点を誰かが説明できますか。

役に立ちましたか？

解決

基本的に、値を直接保存するという古典的なアプローチ Session["something"] 2つの欠点があります：

  • 魔法の弦: ：誤っている場合 something, 、コードは正常にコンパイルされますが、ランタイムエラーを取得するか、さらに悪いことに、コードに気付かれないバグが得られます。
  • 鋳造: ： 読んだあと Session["something"], 、必要なタイプにキャストする必要があります。 （これが意味するものです 「タイプセーフではない」.)

セッションに保存されている強力なオブジェクトを使用すると、2番目の問題がなくなりました。まあ、実際には、カスタムオブジェクトをキャストする必要がありますが、それは2つ（または10）のキャストの代わりに1つのキャストであり、何かがうまくいかない可能性を減らします。繰り返しますが、間違ったキャストは、実行時にのみ検出されるものです。

別のアプローチは、静的プロパティのセッション変数へのアクセスをカプセル化することです。

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

もちろん、両方のアプローチを組み合わせることができ、関連するプロパティ（ユーザー名とパスワード）を共通オブジェクトにグループ化できます。

他のヒント

2つのフィールドを持つユーザークラスを使用することは、タイプの安全性に関しては多くの理由で良いことがあります。セッション["pasword"]を入力すると、簡単に見つけることができないエラーが発生します。両方を確認する必要があります。どこでもパラメーター名。あなたはそれらを正しくする必要があり、それは素晴らしいエラーの原因です。 2つの接続されていない文字列の代わりにユーザーオブジェクトを保存すると、セッション中にString Indenserによってパスワードにアクセスしようとするのではなく、タイプSafe CodeなどのYurs.PassWordを使用できます。また、ユーザーがより多くのフィールドを取得する場合、これは非常に一般的なフィールドを取得した場合、単にユーザークラスに追加し、新しいパラメーターと名前の作成を開始してセッションヒープに保存することはありません。

TypeSafeコーディングに関しては、私は思う http://en.wikipedia.org/wiki/type_safety 非常に人気のあるトピックに関する他のタイプの記事を支援する必要があります。

また、セッションでパスワードを保存する必要があるとは思いません。プログラムのロジックに依存しますが、通常、パスワードはMD5ハッシュを計算するためにのみ使用し、その後は使用しないでください。

まあ、あなたは友達が半分正しいですが、セッションが本質的に安全だとは思いません。セッションコレクションは、オブジェクトのインスタンスを保存します。そのため、すべてオブジェクトから派生しているため、任意のタイプ（文字列、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)

カスタムログインオブジェクトを持つことは、心配するオブジェクトが1つしかなく、1つのキャストを作成するため、この問題をわずかに解決することができます。また、追加の情報を使用してログインオブジェクトを簡単に拡張することもできますが、キャストを実行する必要はありません。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top