Why shouldn't UserControls be used as an ItemSource?

Question

I was the answer to another question here, where the user had a ListView with ItemsSource containing UserControls . I said that I would not recommend it, and I was asked why.

It really surprised me. I have never thought about this before. I know this is not a good idea, but I never thought about why this is not a good idea.

The only thing I can think of is that you create UIElements in memory for each element of your collection, which can be much heavier than data objects. This not only increases the amount of memory that your application uses, but also does not allow the use of virtualization. And it does not fit into the MVVM pattern, which I use almost religiously when working with WPF.

So, can someone list me all the reasons why you should not use the UserControls list as ItemsSource ? Or if you think differently, why would you?

Basically, I want something to tell people when they ask me why they shouldn't use List<MyUserControl> and ItemsSource="{Binding MyUserControlList}" in their applications.

Answer 1

Your thoughts on overhead are very good.

I would like to ask the opposite question ... why do you need this?

I have seen this practice in VB6 in the past. The developer stores the information in user controls in an array somewhere and uses it to access information outside of the lifetime in the user interface that initially displays this control.

This template violates the separation of business logic, model, and user interface.

There's a fine line between lazy and messy .... reuse and misuse. I'm all about code reuse ... but when a developer tells me that they want to use custom controls to transfer information between different areas of the software, I think this is due to misuse. This negatively affects maintainability.

So, if the answer to the question "why do you need this?" has something to do with the use of user controls to convey information, this is certainly applicable.

PS I do not understand what this intention was. In addition, there are good reasons for snapping to other user interface elements in the same context (usually using relative sourcing sources).

Answer 2

It really comes down to the separation of problems, the MVVM design pattern, and, most importantly, (for me) unit testability (and therefore code support).

Is it easier or harder to unit test the UserControls collection as an ItemSource? I would say that the unit test found in the views is much more complicated than unit test.

As you probably know (and I just mention that this is especially specific), the main reason for MVVM has grown because of the need to increase the test and maintainability that MVC offered. In WPF, MVVM provides robust unit testing of logical layers independent of presentation layers.

If your logical operations are embedded in presentation layers, it will be harder to unit test and therefore (checked again and again) more difficult to maintain. I remember from college, and this manifests itself in my professional career, the maintenance of poorly archived solutions is very expensive, in accordance with the general project.

So, the short answer is: Separating presentation and logic (without doing things like having ItemsSource of UserControls) saves your company money throughout the entire project. In the case of WPF, in particular, the separation of presentation and logic exists through the MVVM pattern.