我有更多关于“良好编程实践”的问题。我刚刚开始了一个非常大的项目。我正在使用 WebGui（长话短说……它是 Web 中的 WinForms）——但这并不重要。
我正在创建数以百万计的表单，其中包含数以百万计的控件，如、TextBox等。这可能会发生，我将不得不改变一些行为或外观。在每个控件中都无法更改它。我希望我的项目灵活，所以我有一个想法..NumericUpDownDateTimePickerDateTimePicker
我为每种类型（字符串、数字、日期、字节）做单独的自定义控件。例如，我将在其中放置 TextBox。在每个表单上，我不会放置 TextBox，而是 MyTextBox。实际上，那个 MyTextBox 将只是 TextBox，但是当我在那里更改某些内容时，每个控件都会更改。
它是一种好的、流行的编程实践吗？
在 WPF 的情况下，这可以很容易地使用样式和模板来实现。在 Winforms 中这是不可能的，因此我想说您从控件派生并在 UI 上使用您自己的自定义控件的方法是一种很好的实用方法，有助于集中管理更改。
如果控件是在程序中手动创建的，或者您可以使用工厂类并让工厂创建控制器对象，而不仅仅是更新。但是，当通过拖放控件创建 UI 时，这可能是不可能的，因为开发人员无法控制控件的创建。
无论您选择哪种方法，基本目标都应该是集中控件的创建逻辑。
是的，如果标准控件不能满足您的要求，这对于 GUI 开发来说是完全正常的编程实践。
大多数开发人员获得了 3rd 方控制套件以获得额外的灵活性。购买的好处远远超过了自己建立核心控制的好处。
我曾在一个有 companyTextBox、companyDatePicker 的地方工作过，它工作正常。一些控件在 .Net 版本上进行了改进，因此这些基类控件需要一些手术。任何折旧的控件都保留为依赖于框架版本。
对于特殊的事情，我对CodeProject 、 CodePlex 、 Code.Google.com 等良好的自定义控件进行了大量研究，并将它们实施到我正在处理的项目中。否则，请使用我正在工作的公司的库存标准控件或第 3 方控件套件。
我的建议是获取第 3 方控件套件，并基于第 3 方控件制作大量可重复使用的用户控件。这样，您可以通过将用户控件拖放到表单上来构建 200 个表单中的大部分。使用 Create、Retrieve、Update 和 Delete 方法使每个用户控件实现一个接口，以使表单与您的用户控件一起工作。