C# – Is it good practice to use user controls to structure WPF forms even if these user controls are only used once

cuser controlwpf

I develop a WPF application using MVVM and I am learning how to do things best.

I have a WPF form with selectors, two list with search fields, and some other elements. Currently all is in one form and it works. But by now the VM for that form has more than 800 lines and it is not yet finished.

I want to structure this form and the code better. I thought about regions, files with partial classes and user controls. I think user controls would be best because they encapsulate a couple of controls and logic. If I would use user controls then the amount of code in that window and VM would be drastically reduced.

To do this right I work through the book "Pro WPF 4.5 In C# 4th Edition", Chapter 18 – Custom Elements and the ColorPickerUserControl sample. The sample is about a color picker with three sliders and it has 150 lines of code.

I think I understand how it works but it seems to me that creating user controls, even with very limited functionality like in that sample, is a lot of work. If I would use these controls several times then I understand it would make sense to do this. But if I use the controls only one time and I do this only to structure my form then this seems to be a lot of work for little gain.

My question is: Is it good practice to use user controls to structure forms even if these user controls are only used once? If not, is there a better alternative?

Edit (not necessary to read, just more information): Until now I did not write any details because I wanted to learn about the principle but after reading 17 of 26’s interesting answer, here are some details: This form is to select music titles.

  • Group A: (possible user control A) is about the type of selection like select by artist or album, with or without video, maybe year of publication, etc.

  • Group B: This list contains artist names which are filtered according to criteria in A. The user can filter the list i.e. showing only artist names containing "top".

  • Group C: This list shows titles from the artist selected in B also using criteria from A (i.e. audio or video). It can be filtered similar to B i.e. only titles containing "you".

Most of the logic happens in the VM (DataContext of the form). The lists from A and B come from a database. The lists are filtered and prepared for presentation (i.e. multiple titles with the same name but in different albums). The user selects a title in the C-List by double clicking or uses drag and drop into another WPF form.

What I want: I want readable code so that I can easily amend it. If I want to add i.e. another filter let’s say to only show female artists then it would be good if I could just go to user control A and add checkboxes for male and/or female artists.

The XAML in the current form is no problem, it is well structured. But the VM has code for all of the above. Some things are in the constructor, some in the commands section, some properties and backing fields. I can still find things now but I think it would be better if the code would be more structured. This is why I think about the User Controls.

I try to follow MVVM because I think the logic behind it makes a lot of sense. But I am not a fanatic follower of any theoretical practice. I.e. if I can do something in 5 lines of CodeBehind or in 50 lines in the VM I will do it likely in the CodeBehind. My question is about the principle how to create structured forms in WPF. The form I describe above is a good example but the answer should not concentrate on this one single from but on the idea how to structure WPF forms i.e. with (or without) user controls.

About why I think user controls are a lot of work: They have dependency properties, routed events, etc. All this seems to me a lot more complicated than “normal” properties with backing fields and INotify. But maybe I just have to get used to dependency properties, routed events, etc.

Best Answer

Absolutely yes. It is a good idea in the same way that it is a good idea to apply separation of concerns on classes to put each in its own in order to perform a single task. You may only have one instance of that class, but it matters not. The optimization is not in terms of program performance but in terms of organization and overall program "health".

You want to be able to return to your program one day and not have to scroll through several hundred pages of code, even if it is put into regions (using regions on classes with lots of code is like putting lipstick on a pig, by the way). Should you ever one day decide to use it somewhere else, you can do so gracefully and without many problems.

Just don't make the temptation of giving the user control access to the parent form. If you do it this way, use events to convey information to the parent, with the parent form as a subscriber.

Related Topic