asp.net - 总是使用 ASP.NET 服务器控件的子类？如果没有，为什么不呢？

Question

在我的 ASP.NET 开发环境中，有一个几乎通用的最佳实践:

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

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

例如:假设您决定希望在 Web 表单应用程序中的每个文本框右侧显示一个问号图标。图标已呈现，将鼠标悬停在其上会弹出气泡帮助 - 前提是 TextBox.ToolTip 属性中有文本。

如果您使用 MS 提供的 TextBox 控件，您将如何实现这一点？

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

急!您应用程序的所有文本框都会出现小问号图标 - 或者当您设置其工具提示文本时，它们会出现。

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

在 ASP.NET 中，我从未遇到过这种做法的拥护者。我刚刚错过了吗？一篇描述两打 ASP.NET 设计模式的文章没有任何相关内容。关于如何对服务器控件进行子类化的帖子描述了特殊用途的一次性内容，例如仅接受数字的文本框 - 但他们都没有推荐普遍存在的“始终使用子类化控件!”我以前订阅的政策。

在 ASP.NET 中工作时应用这种古老的智慧有意义吗？始终使用 native 服务器控件的子类等效项？

如果没有——为什么不呢？还有其他方法可以给这只猫剥皮吗？一种技术只为您提供一个位置，您可以在其中增强给定控件的所有应用程序实例？

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

TIA - 霍伊斯特

Answer 1

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

添加带有文本框和图像的用户控件或您需要的任何控件组合比使您的项目变得困惑更好。

您的 WinForms 项目也这样做吗？ (我很少看到这样做，而且它似乎并没有增加它声称的值(value)。)