Should custom controls be used to manage form complexity?

In general, I am wondering when to use custom controls vs integrating the control directly into your form.

In particular, I have a form that contains a tab page, with 6 tabs each containing a number of .net framework controls. Currently, I have in my project 6 user defined controls that I dock onto each of those tab pages. I.开发者_运维技巧e. there is no reuse of controls, I just use them to manage the complexity of a form that would otherwise contain 10 gridviews, 20 buttons, 6 date controls, etcetera. Would you consider this a good way to manage this complexity, or would other alternatives be better (in enabling the programmer to understand what is going)?

I think this kind of division of page to custom/usercontrols may prove to be useful even without reusing the parts. This gives you:

1. Encapsulation - you can hide the boring plumbing and fragile internal state from higher level code, leaving you a much cleaner set of controls to work with and more business-oriented code on page level.
2. Separation of concerns - you can make pieces which are simple, yet logically whole.
3. Readiness for reuse - may never become useful but it does make you feel more powerful ;)

But be aware that this can backfire if your components are not properly named and grouped, badly designed, you use lots of dynamic loading, do not provide good API or nesting goes too deep. I have seen it happen in a legacy app and it wasn't helpful that way.

If done well, worth it. With inexperienced/sloppy team members, better don't.

What is complexity for you? If you ask me, you are making it more complex if you use usercontrols as the way you use. Usercontrols should be used to prevent code duplication. Basically what you are doing is moving your logic to your usercontrol and deviding your logic into multiple pages so you have less code on your main page. This shouldn't be your main concern if you ask me.

If you have complex logic in a view model or controller for the sections of screen, then this can be a beneficial approach. It is making your overall form more of a composite. You can develop the functionality behind the sections/controls in the view models and/or controllers separately and unit test them separately. As ImreP says, this is along the lines of separation of concerns.

However, if there's a lot of interaction between the separate controls on your form, then this might not be the right way. If you can find separate areas of behaviour/responsibility for different areas of the form, then the split may be a good idea, given your premise that there is quite a lot of UI happening.

If it's simply for the sake of having fewer basic controls in each package, and there's no chance of reuse of any of the components, then it might be muddying the waters somewhat.

A good test might be to show it to someone else on your team and see how long it takes to explain it to them. You'll get a good idea if it's intuitive or not by trying to show it to someone who hasn't come across it yet.