ASP.NET 页面属性好主意或坏主意答案

【问题标题】：ASP.NET Page Properties Good Idea or Bad IdeaASP.NET 页面属性好主意或坏主意
【发布时间】：2009-03-03 16:15:54
【问题描述】：

我倾向于回避向我的 ASP.NET 页面添加属性。对我来说，这从来都不是一个好主意。但是，最近我在一些示例应用程序中看到了这种做法。我对向页面添加自定义属性的反感是没有根据的，还是这是“视情况而定”的情况？

【问题讨论】：

【解决方案1】：

我认为使用属性清理服务器端页面上的代码没有任何问题。我喜欢使用属性来访问会话状态或视图状态信息，这样如果我修改访问数据的方式，我只更改一个地方。

【讨论】：

【解决方案2】：

您需要记住的关于属性的事情是它们在整个页面生命周期中都存在。这使得它们既非常有用（在生命周期的早期设置一个属性，它在以后仍然有效）也很危险（在设置之前很容易访问一个属性，或者没有意识到另一个生命周期阶段改变了它）。

我见过一个效果很好的属性是包装查询字符串和会话的一种很好的类型安全方式。为每个预期的查询字符串或会话值定义属性，未来的开发人员会非常清楚预期和可用的内容。

另一个常见的用途是包装 ViewState 项。我希望这是您在示例中看到它们的地方，因为大多数示例倾向于假定 ViewState 已打开。

【讨论】：

【解决方案3】：

Asp.net 不支持基于构造函数的注入。这是一个明确的场景，您希望使用 asp.net 属性（因为您可以使用基于属性的注入）。

更新 1：这是一个类似的场景，但用于控件 - How to use Dependency Injection with ASP.NET Web Forms

更新 2： 可以使用它们来包装视图状态或查询字符串。不过，我会仔细查看它，因为您不想滥用代码隐藏。如果您看到您在代码隐藏中多次使用包装属性之一，则代码隐藏中可能有太多代码。以这种方式看待它的副作用是避免与这些属性相关联的重复转换/解析。

【讨论】：

【解决方案4】：

页面上的属性没有任何问题。他们可能会觉得奇怪，因为页面很少被外部代码作为对象操作，但可以做到。鉴于此，页面上的大多数属性都可以标记为私有。像所有事物一样，也有例外。

我对页面上的属性的最大用途之一是包装 ViewState 值：

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

在这种情况下，我已将该属性标记为“受保护”，这样我就可以从我的标记中访问它。

【讨论】：

【解决方案5】：

为什么会不好？属性实际上只是方法，我相信您一直在向页面添加方法。

【讨论】：

【解决方案6】：

我使用我的asp.net 页面上的属性来访问会话、视图状态和查询字符串。它只是让您编写更少的代码并提高可读性

【讨论】：