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

Question

我一直回避添加属性到我的ASP.NET页面。这对我来说似乎不是一个好主意。但是，最近我在几个示例应用程序中看到了这种做法。我厌恶添加自定义属性到一个页面没有根据，或者这是一个“它取决于”的情况？

Answer 1

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

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

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

Answer 2

为什么它会不好？属性实际上只是方法，我相信你总是在页面中添加方法。

Answer 3

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

Answer 4

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

更新1：这里是一个类似的情况，但对于控制 - How to use Dependency Injection with ASP.NET Web Forms

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

Answer 5

我在我的asp.net页面上使用属性来访问Session，Viewstate和querystring。它只会让你编写更少的代码并提高可读性

Answer 6

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

我有我的网页上性能的最大用途的包装一ViewState的值时：

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

在这种情况下，我已标记属性为“受保护”，让我从访问我的标记。