4

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

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

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

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

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

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

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

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

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

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

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

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

TIA - 霍伊斯特

4

4 回答 4

2

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

于 2009-12-10T22:05:28.087 回答
2

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

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

您是否也为您的 WinForms 项目执行此操作？（我很少看到它完成了，而且它似乎并没有增加它声称的价值。）

于 2009-12-10T22:11:54.983 回答
1

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

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

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

于 2009-12-11T11:08:16.117 回答
0

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

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

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

因此，这是个好主意，但在实践中很难以良好的方式实施

于 2009-12-11T05:06:38.677 回答