总是使用 ASP.NET 服务器控件的子类？如果没有，为什么不呢？
在我的 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 中工作时应用这种古老的智慧是否有意义？始终使用本机服务器控件的子类等效项？
如果没有——为什么不呢？还有其他方法可以给这只猫剥皮吗？一种只为您提供一个位置来增强给定控件的所有应用程序实例的技术？
我很想听听这个。我想要我的 TextBoxQMark 控件。 :-)
TIA - 霍伊斯特
In my pre-ASP.NET development environment, there was a near-universal best practice:
* NEVER use the native controls!
* Instead, subclass ALL the controls, and ALWAYS use the subclassed version.
Why? Because that gave you a hook... one place to write code and have it applied throughout your application.
For example: Suppose you decide that you want a question mark icon to appear to the right of every TextBox in your webforms app. The icon is rendered, and hovering over it pops up bubble help -- iff there is text in the TextBox.ToolTip property.
How would you accomplish that, if you're using the MS-provided TextBox control?
If you consistently used a subclassed version of TextBox in your application, then you could go to that object, and add the method that renders the icon, stocked with your favorite bubblehelp javascript.
Presto! All of your app's TextBoxes sprout little question mark icons -- or they will, when you set their ToolTip text.
Over time, you can easily adapt and enhance ALL your TextBoxes, because they all have a base class that you can modify. You add a feature where ToolTips are set from a resource file. Next, you add a ShowOnLeft property that presents the icon on the left side of the TextBox. Do you like how the iPhone password control shows the last character you type, obscuring the earlier characters? Override your subclassed TextBox's default behavior for passwords with a method to implement that behavior.
I have never encountered advocates for this practice, in ASP.NET. Have I just missed it? An article describing two dozen ASP.NET design patterns doesn't have anything related. The posts about how to subclass server controls describe special-purpose one-offs, like a TextBox that only accepts digits -- but none of them recommend the pervasive "ALWAYS use subclassed controls!" policy that I subscribed to in olden days.
Does it make sense, to apply this ancient wisdom, when working in ASP.NET? To always use the subclassed equivalent of the native server controls?
If not -- why not? Are there other ways to skin this cat? A technique that provides you with just one place where you can augment ALL your application's instances of a given control?
I'd love to hear about that. I want my TextBoxQMark control. :-)
TIA - Hoytster
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
理论上这很好，但是您多久需要一次这些子类，派生类以及搜索和替换必要的变量有多困难。我猜想所有未使用的子类造成的“混乱”会使项目不必要地“复杂化”。
添加带有文本框和图像的用户控件或您需要的任何控件组合比使您的项目变得混乱更好。
您的 WinForms 项目也这样做吗？ （我很少看到这样做，而且它似乎并没有增加它声称的价值。）
It's nice in theory, but how often do you need these subclasses and how hard is it to derive the class and search and replace the necessary variables. I'd guess that the "clutter" caused by all the unused subclasses would unnecessarily "complicate" the project.
Better to add a user control with a textbox and an image or what-ever-control-combination-you-need-than-to-clutter-up-your-project.
Do you also do this for your WinForms projects? (I've seen it done, rarely, and it doesn't seem to add the value that it claims.)
从理论上讲，这是一个好主意。在实践中，大多数时候我都懒得创建子类，而且我并不经常需要回去添加它们。
In theory, it's a good idea. In practice, I'm too lazy to create the subclasses most of the time, and it's not often that I have to go back and add them.
大多数时候，不需要子类。
您可以使用标签映射或控制适配器来完成多种类型的自定义。
如果有帮助，我会在书中讨论这两种方法以及示例代码： Ultra-快速 ASP.NET。
Most of the time, subclasses aren't needed.
You can use tag mapping or control adapters instead to accomplish many types of customizations.
In case it helps, I discuss both approaches in my book, along with sample code: Ultra-Fast ASP.NET.
我在我的应用程序中广泛使用了这个概念，我发现的唯一缺点是
1) 有时你的基类中有太多 if/else 条件，这些条件仅 5% 的情况需要，但它们影响 100% 的情况
2）代码可能会变得复杂并且开发人员难以理解，因此很难在项目中添加新的开发人员
所以，这是个好主意，但在实践中很难以良好的方式实施
I have used this concept extensively in my application and the only drawback i found is
1) sometimes it happens that you are having too many if/else condition in your base class which are required for only 5 % cases but they are affecting 100 % case
2) Code can become complex and difficult to understand for developer, so it is difficult to add new developer in your project
So, it is good idea but in practice it is difficult to implement in a good manner