一般来说，我想知道何时使用自定义控件与将控件直接集成到表单中。应该使用自定义控件来管理表单的复杂性吗？
特别是，我有一个包含标签页的表单，其中包含6个标签，每个标签包含多个.net框架控件。目前，我在我的项目中有6个用户定义的控件，我停靠在每个标签页上。 也就是说没有重用控件，我只是用它们来管理一个表单的复杂性，否则它将包含10个gridviews，20个按钮，6个日期控件等等。你会认为这是一种管理这种复杂性的好方法，或者其他方法会更好吗（使程序员能够理解将要发生的事情）？
我认为这种页面到custom/usercontrols的划分可能证明是有用的，即使没有重用这些部分。这使您：
但要注意，这可能会适得其反，如果你的部件没有进行正确命名，分组，设计不好的，你使用大量的的动态加载，不提供良好的API或嵌套过深。我已经看到它发生在一个传统的应用程序，这是没有帮助的方式。
如果做得好，值得。由于缺乏经验/ sl team的团队成员，最好不要。
什么是你的复杂性？如果你问我，如果按照你使用的方式使用usercontrols，你会变得更加复杂。用户控件应该用来防止代码重复。基本上你正在做的是将你的逻辑移动到你的用户控件，并将你的逻辑分成多个页面，这样你的主页面上的代码就会减少。如果你问我，这不应该是你主要关心的问题。
如果在一个视图模型或控制器，用于屏幕的部分复杂的逻辑，那么这可以是有益的方法。它使您的整体形式更加复合。您可以分别开发视图模型和/或控制器中的部分/控件背后的功能，并单独测试它们。正如伊姆雷普所言，这是沿着关注点分离的路线。
但是，如果你的表格上有很多独立的控件之间的互动，那么这可能不是正确的方式。如果你可以在表单的不同区域找到单独的行为/责任区域，那么考虑到UI的发生有相当多的前提，拆分可能是一个好主意。
如果它只是在每个包有较少的基本控制的缘故，而且也没有任何组件的重用机会，那么它可能是有些污浊的水域。
一个很好的测试可能是它展示给别人在你的团队其他人，看看需要多长时间来向他们解释。通过尝试将其展示给尚未遇到过的人，您会发现一个好主意。