应该使用自定义控件来管理表单复杂性吗？

Question

一般来说，我想知道何时使用自定义控件与将控件直接集成到表单中。

特别是，我有一个包含标签页的表单，其中包含6个标签，每个标签包含许多.net框架控件。目前，我在我的项目中有6个用户定义的控件，我将这些控件停靠在每个标签页上。 即没有重用控件，我只是使用它们来管理一个表单的复杂性，否则它将包含10个网格视图，20个按钮，6个日期控件等等。您是否认为这是管理这种复杂性的好方法，或者其他替代方案会更好（使程序员能够做到这一点） 了解将要发生的事情？

Answer 1

你的复杂性是什么？如果你问我，如果你使用usercontrols作为你的使用方式，你会使它变得更复杂。应使用Usercontrol来防止代码重复。基本上你正在做的是将你的逻辑转移到你的用户控件并将你的逻辑分成多个页面，这样你的主页上的代码就会减少。如果你问我，这不应该是你的主要关注点。

Answer 2

我认为即使不重复使用这些部分，这种对自定义/用户控制的页面划分也可能有用。这给你：

1. 封装 - 您可以从较高级别的代码中隐藏枯燥的管道和脆弱的内部状态，从而为您提供更清晰的控件集以及更多面向业务的代码。
2. 关注点的分离 - 你可以制作简单而又逻辑完整的作品。
3. 重用的准备 - 可能永远不会变得有用但它会让你感觉更强大;）

但请注意，如果您的组件未正确命名和分组，设计不当，使用大量动态加载，不提供良好的API或嵌套过深，这可能会适得其反。我已经看到它发生在一个遗留应用程序中，并没有那么有用。

如果做得好，值得。对于缺乏经验/邋team的团队成员，最好不要。

Answer 3

如果视图模型或控制器中的逻辑部分有复杂的逻辑，那么这可能是一种有益的方法。它使您的整体形式更具复合性。您可以分别在视图模型和/或控制器中开发部分/控件背后的功能，并单独对它们进行单元测试。正如ImreP所说，这是关注点的分离。

但是，如果表单上的单独控件之间存在大量交互，那么这可能不是正确的方法。如果您可以在表单的不同区域找到不同的行为/责任区域，那么拆分可能是一个好主意，前提是有相当多的UI发生。

如果它只是为了在每个包装中具有较少的基本控制，并且没有机会重复使用任何组件，那么它可能会在某种程度上混淆水域。

一个好的测试可能是向团队中的其他人展示，并看看向他们解释它需要多长时间。如果它是直观的，或者通过尝试向尚未遇到它的人展示它，你会得到一个好主意。