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

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

  •  03-07-2019
  •  | 
  •  

题

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

有帮助吗？

解决方案

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

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

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

其他提示

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

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

更新1：这是类似的情况，但对于控件 - 如何使用ASP.NET Web窗体的依赖注入

更新2：可以使用它们来包装viewstate或查询字符串。我会仔细看一下，因为你不想滥用代码隐藏。如果你看到你在代码隐藏中使用了一个包装属性，那么代码隐藏中的代码可能太多了。以这种方式看待它，具有避免可以与这些属性相关联的重复转换/解析的副作用。

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

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

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

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

为什么会这么糟糕？属性实际上只是方法，我确信你一直在向页面添加方法。

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

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top