为什么不应将UserControl用作ItemsSource？

Question

我在这里answering another question，用户的ListView ItemsSource包含UserControls。我说我不推荐它，并被问到为什么。

这真让我感到惊讶。我以前从未考虑过。我知道这样做并不是一个好主意，但我从未真正想过为什么这样做不是一个好主意。

我唯一能想到的是你在内存中为集合中的每个项目创建UIElements，这可能比数据对象重得多。这不仅会增加应用程序使用的内存，还会阻止您使用虚拟化。它不适合MVVM设计模式，我在使用WPF时几乎虔诚地使用它。

那么，有人可以列出您不应该使用UserControls列表作为ItemsSource的所有原因吗？或者如果你不这么认为，为什么会这样？

基本上，当他们问我为什么不应该在他们的应用程序中使用List<MyUserControl>和ItemsSource="{Binding MyUserControlList}"时，我想要点一些东西。

Answer 1

关于性能开销的要点非常好。

我会问相反的问题......为什么你想要？

我过去在VB6中看过这种做法。开发人员将信息存储在某个位置的数组中的用户控件中，并使用它来访问最初显示该控件的UI上的生命周期之外的信息。

此模式违反了业务逻辑，模型和用户界面的分离。

在懒惰和邋....之间存在一条微妙的界限......重用和误用。我只是关于代码重用...但是当开发人员告诉我他们想要使用用户控件来在软件的不同区域之间传递信息时，我认为这是误用的一面。它对可维护性产生了不利影响。

那么，如果回答“为什么你想要？”与使用用户控件传递信息有关，上面肯定会适用。

P.S。 我不清楚你所关联的问题的意图是什么。此外，有正当理由在同一上下文中绑定到其他UI元素（通常使用相对绑定源）。

Answer 2

它真正归结为关注点分离，MVVM设计模式，最重要的是（对我而言）单元可测试性（以及代码可维护性）。

作为ItemSource，对UserControls集合进行单元测试是否更容易或更难？我会说在视图中对单元测试业务逻辑进行单元测试要困难得多。

正如您可能知道的那样（我只是提到它具体而言）MVVM的主要原因来自于MVC提供的改进的可测试性和可维护性的需求。在WPF中，MVVM允许对独立于表示层的逻辑层进行稳健的单元测试。

如果您的逻辑操作嵌入在表示层中，则单元测试将更难，因此（一遍又一遍地证明）难以维护。我记得从大学开始，在我的职业生涯中，对于整体项目来说，维护架构不佳的解决方案非常昂贵。

所以，简短的回答是： 在整个项目的整个过程中，表示和逻辑的分离（通过不执行诸如具有UserControls的ItemsSource之类的东西）可以节省公司的资金。在WPF的情况下，具体而言，通过MVVM模式存在表示和逻辑的分离。