ASP.NETページプロパティ良い考え方または悪い考え方

Question

私はASP.NETページにプロパティを追加することを躊躇しがちです。それは私にとって素晴らしいアイデアのようには思えませんでした。しかし、最近私はいくつかのサンプルアプリケーションで採用されている手法を見てきました。ページにカスタムプロパティを追加することに対する私の嫌悪感は否認されているのか、それとも「それは依存している」状況ですか？

Answer 1

覚えておく必要があるプロパティについては、ページのライフサイクル全体で最後になることが重要です。これは、それらを非常に便利なものにして（ライフサイクルの早い時期にプロパティを設定し、それは後で有効です）、危険です（プロパティが設定される前にアクセスしたり、別のライフサイクルフェーズが変更されたことを認識しません）。

私は大きな効果があったプロパティを見てきましたが、クエリ文字列とSessionをラップするための型として安全な方法です。予想されるクエリ文字列またはセッション値のそれぞれのプロパティを定義すると、将来の開発者が期待しているものと利用可能なものが非常に明確になります。

もう1つの一般的な使用方法は、ViewStateアイテムをラップすることです。ほとんどのサンプルでは、​​ViewStateがオンになっていると想定されるため、これはサンプルで見ているところです。

Answer 2

なぜ悪いですか？プロパティは本当に単なるメソッドであり、私はあなたがいつもページにメソッドを追加すると確信しています。

Answer 3

プロパティを使用してサーバーサイドページのコードをクリーンアップすることは何も問題ありません。プロパティを使用してセッション状態またはビュー状態情報にアクセスするのが好きです。この方法でデータにアクセスする方法を変更すると、1つの場所のみが変更されます。

Answer 4

Asp.netはコンストラクタベースの注入をサポートしていません。これは、asp.netのプロパティを使用する明確なシナリオです（プロパティベースの注入を使用できます）。

アップデート1：ここでは同様のシナリオであるが、コントロールのための - How to use Dependency Injection with ASP.NET Web Forms

アップデート2：ビューステートまたはクエリ文字列をラップするためにそれらを使用しても大丈夫です。コードビハインドを乱用したくないので、私は注意深くそれを見るでしょう。コードビハインドで折り返しプロパティの1つを使用していると思われる場合は、コードビハインドに多すぎるコードが含まれている可能性があります。このように見て、それらのプロパティに関連付けることができる繰り返しのキャスト/解析を避けるという副作用があります。

Answer 5

私はasp.netページのプロパティを使用して、Session、Viewstate、およびQueryStringにアクセスします。ただコードを書く必要がなくなり、読みやすさが向上します

Answer 6

ページのプロパティに問題はありません。ページが外部コードによってオブジェクトとして操作されることはめったにありませんが、ページを操作することはほとんどできません。それを考えると、ページ上のほとんどのプロパティはプライベートとマークすることができます。すべてのものと同様、例外もあります。最大の

一つのViewState値ラップされたとき、私は私のページのプロパティを持っている使用しています。この場合

protected string TaskName 
{ 
    get { return (string)ViewState["TaskName"] ?? string.Empty; } 
    set { ViewState["TaskName"] = value; } 
} 

を私からそれにアクセスすることを可能にする「保護」として、私は、プロパティをマークしました私のマークアップ。