CODEWITHSUNDEEP
wpfuser-controlsdatacontextitemssource
Rachel
Rachel

Reputation: 132588

Why shouldn't UserControls be used as an ItemsSource?

I was answering another question on here where the user had a ListView with an ItemsSource containing UserControls. I said I wouldn't recommend it, and got asked why.

This really surprised me. I've never considered it before. I know it's not a good idea to do so, but I never really thought about why it wasn't a good idea to do so.

The only thing I can think of is that you are creating UIElements in memory for every item in your collection, which can be much heavier than data objects. This not only increases the memory your application uses, but also prevents you from using Virtualization. And it doesn't fit in with the MVVM design pattern, which I use almost religiously when working with WPF.

So, can someone list me all the reasons you should not be using a list of UserControls as an ItemsSource? Or if you think otherwise, why you would?

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

Upvotes: 4

Views: 224

Answers (2)

EtherDragon
EtherDragon

Reputation: 2698

It really comes down to the Separation of Concerns, the MVVM Design Pattern, and most importantly (to me) unit testability (and thus, code maintainability).

Is it easier, or harder to unit test a collection of UserControls, as an ItemSource? I would say it's much harder to unit test business logic found in the Views.

As you are probably aware (and I only mention it to be specifically specific) the main reason for MVVM grew from the need for improved testability and maintainability that MVC offered. In WPF, MVVM allows for robust unit testing of the logical layers independant of the presentation layers.

If your logical operations are embedded in the presentation layers, it will be harder to unit test, and thus (proven over and over again) harder to maintain. I remember from college, and it bears out in my professional career, maintenance of poorly architected solutions is very expensive, in perportion to the overall project.

So, the short answer is: Separation of presentation and logic (by not doing things like having an ItemsSource of UserControls) saves your company money, over the course of the project overall. In the case of WPF, specifically, separation of Presentation and Logic exists through the MVVM pattern.

Upvotes: 0

Jeff
Jeff

Reputation: 36573

Your points about performance overhead are very good.

I would ask the converse question....why WOULD you want to?

I've seen this practice in VB6 in the past. The developer stores information in user controls in an array somewhere and uses it to access information outside the lifetime on the UI which initially displays that control.

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

There's a fine line between being lazy and being sloppy....reuse and misuse. I'm all about code reuse...but when a developer tells me they want to use user controls to carry information between different areas of the software, I think that falls on the side of misuse. It adversely affects maintainability.

So, if the answer to "why would you want to?" has something to do with using user controls to pass around information, the above would certainly apply.

P.S. It's unclear to me what the intent was in the question you linked to. Also, there are valid reasons to binding to other UI elements in the same context (usually using relative binding sources).

Upvotes: 1

Related Questions