总是使用 ASP.NET 服务器控件的子类？如果不是，为啥不呢？

Posted 2023-03-05

【中文标题】总是使用 ASP.NET 服务器控件的子类？如果不是，为啥不呢？

【英文标题】：Always use SUBCLASSES of ASP.NET server controls? If not, why not?总是使用 ASP.NET 服务器控件的子类？如果不是，为什么不呢？

【发布时间】：2010-12-25 10:40:19

【问题描述】：

在我之前的 ASP.NET 开发环境中，有一个近乎普遍的最佳实践：

* NEVER use the native controls!
* Instead, subclass ALL the controls, and ALWAYS use the subclassed version.

为什么？因为这给了你一个钩子……一个编写代码并将其应用到整个应用程序的地方。

例如：假设您决定要在 Web 表单应用程序中每个 TextBox 的右侧显示一个问号图标。图标被渲染，悬停在它上面会弹出气泡帮助——如果 TextBox.ToolTip 属性中有文本。

如果您使用的是 MS 提供的 TextBox 控件，您将如何做到这一点？

如果您在应用程序中一直使用 TextBox 的子类版本，那么您可以转到该对象，并添加呈现图标的方法，其中包含您最喜欢的 bubblehelp javascript。

快！您应用的所有文本框都会出现小问号图标——或者当您设置它们的工具提示文本时它们会出现。

随着时间的推移，您可以轻松地调整和增强所有文本框，因为它们都有一个可以修改的基类。您添加一个功能，其中工具提示是从资源文件中设置的。接下来，添加一个 ShowOnLeft 属性，该属性在 TextBox 的左侧显示图标。您喜欢 iPhone 密码控件如何显示您键入的最后一个字符，而不是前面的字符吗？使用实现该行为的方法覆盖子类 TextBox 的默认密码行为。

我从未在 ASP.NET 中遇到过这种做法的倡导者。我刚刚错过了吗？一篇描述两打 ASP.NET 设计模式的文章没有任何相关内容。关于如何对服务器控件进行子类化的帖子描述了特殊用途的一次性操作，例如只接受数字的文本框——但没有一个推荐普遍的“总是使用子类化控件！”我过去订阅的政策。

在 ASP.NET 中应用这种古老的智慧是否有意义？要始终使用本机服务器控件的子类等效项？

如果不是——为什么不呢？还有其他方法可以剥这只猫的皮吗？一种技术只为您提供了一个可以扩充给定控件的所有应用程序实例的地方？

我很想听听这个。我想要我的 TextBoxQMark 控件。 :-)

TIA - 霍伊斯特

【问题讨论】：

我从没想过，但这对我来说很有意义。它还允许您在不更改任何页面的情况下无缝替换底层控件 - 例如，所有 DropDownLists 现在实际上应该是 RadioButtonLists，或某些第三方控件。

@aehiilrs，我猜你认为级联样式表也不需要？

这怎么有点像？当你改变一种风格时，你这样做是为了让事情看起来一致。当您想要做的只是向其中添加一个功能时，为什么要随意更改项目中每个控件的行为方式？我认为 YAGNI 可能适用于此。

如果你只是想给页面上的一个东西添加一个特性，你直接声明一个样式。与子分类控件类似，如果您要添加一次性功能，则可以只修改一页。 Hoyster 提供了充分的例子来说明这将如何有用。您说“当您更改样式时，您这样做是为了使事情看起来一致”，但您错过了 hoyster 所说的部分“假设您决定要在 webforms 应用程序中的每个 TextBox 的右侧显示一个问号图标。图标被渲染，悬停在它上面会弹出气泡帮助..."

我很可能希望该选项出现问号。我仍然不明白这个建议比根据需要滚动自定义控件更好。

【参考方案1】：

理论上很好，但是您多久需要一次这些子类以及派生类以及搜索和替换必要变量的难度。我猜想所有未使用的子类造成的“混乱”会使项目不必要地“复杂化”。

最好添加一个带有文本框和图像的用户控件，或者添加你需要的任何控件组合，而不是添加你的项目。

您是否也为您的 WinForms 项目这样做？ （我已经看到它完成了，很少，而且它似乎并没有增加它声称的价值。）

【讨论】：

> 你多久需要这些子类 你会感到惊讶。如果你有一个子类 - 你会找到使用它的机会。当一个新版本具有中心对齐日期控件会 GPF 的缺陷时——我在子类的构造函数中使所有日期控件左对齐——也许 100 个日期控件重新开始工作。 10分钟工作。 > 我猜想由所有未使用的子类引起的“混乱”会使项目不必要地“复杂化”。我会（将）用 ZTextBox 替换 TextBox，并从 VS 库存中删除 TextBox。不再杂乱；完全相同的数量。

@hoytster - 这不是我所指的混乱。混乱是你的 ZTextBox ；）“中心对齐日期控制将 GPF”...... hrm 有任何证据证明这实际上发生了？重点是你所做的是让你看起来比自己优越，而不会给项目增加价值。必须是您工作场所的集体思考。

嘿，Roygbw。我想你会怀疑，因为你认为你会听说过这样的事情。这是一个大约 2000 点的 PowerBuilder 版本——如果您不使用该技术，那将是相当晦涩的。至于让自己显得优越：我希望。我是前 PowerBuilder 大师，努力攀登 .NET 学习曲线。我还有很长的路要走，而且这门学科的扩展速度似乎比我学的要快。感觉不是很优越。 :)

【参考方案2】：

理论上，这是个好主意。在实践中，我大部分时间都懒得创建子类，而且我并不经常必须回去添加它们。

【参考方案3】：

大多数时候，不需要子类。

您可以改用标签映射或控制适配器来完成多种类型的自定义。

如果有帮助，我会在我的书中讨论这两种方法以及示例代码：Ultra-Fast ASP.NET。

【讨论】：

这个周末我在 Barnes and Noble 看了这本书。看到有多少我从未听说过的提高性能的东西真是令人震惊。在我的快速浏览中，我没有看到标签映射部分，关于控制适配器的部分很轻；我可能找不到合适的零件。感谢您的领导。

很高兴听到您找到了这本书。标签映射信息（又名“标签转换”）在第 247 页。我在两个地方讨论了控制适配器：一次在标签映射之后，也从第 216 页开始。

【参考方案4】：

我在我的应用程序中广泛使用了这个概念，我发现的唯一缺点是

1) 有时，您的基类中有太多 if/else 条件，这些条件仅适用于 5% 的情况，但它们会影响 100% 的情况

2) 代码可能会变得复杂且开发人员难以理解，因此很难在您的项目中添加新的开发人员

所以，这是个好主意，但实际上很难以良好的方式实施

【讨论】：

Re 1：我无法相信一些 if-then 子句会对性能产生任何影响。您必须进行 10 亿次迭代才能获得可测量的结果。回复 2：有效问题。如果 ZTextBox 有 ShowOnLeft 属性，那么当菜鸟谷歌搜索时——只有 this 页面会命中。另一方面，与 MS 的服务器控件不同，源是现成的。将控制项目添加到解决方案中，“Go To Implementation”将带您进入注释良好的代码。

不仅是 if then 子句，而且如果我们的控件适用于配置设置，那么 if then 子句需要昂贵的操作，例如数据库连接或服务调用，这会使处理速度变慢

无论您是否使用此模式，您可能只想预先缓存类似的配置设置。如果它显着提高了性能，那是值得的。