Почему не следует использовать UserControls как ItemsSource?

Question

Я отвечал на другой вопрос здесь, где у пользователя было ListView с ItemsSource, содержащим UserControls.Я сказал, что не буду рекомендовать это, и меня спросили, почему.

Это действительно удивило меня.Я никогда не думал об этом раньше.Я знаю, что это не очень хорошая идея, но я никогда не задумывался над тем, почему это не очень хорошая идея.

Единственное, о чем я могу думать, это то, что вы создаете элементы UIE в памяти.для каждого элемента в вашей коллекции, который может быть намного тяжелее, чем объекты данных.Это не только увеличивает объем памяти, используемой вашим приложением, но и не позволяет использовать виртуализацию.И он не вписывается в шаблон проектирования MVVM, который я использую почти религиозно при работе с WPF.

Итак, кто-то может перечислить мне все причины, по которым вам не следует использовать список UserControls в качествеItemsSource?Или если вы думаете иначе, почему бы вы?

По сути, я хочу, чтобы люди указывали на то, когда они спрашивают меня, почему им не следует использовать List<MyUserControl> и ItemsSource="{Binding MyUserControlList}" в своих приложениях.

Answer 1

Ваши оценки производительности очень хорошие.

Я бы задал обратный вопрос .... почему бы ты этого хотел?

Я видел эту практику в VB6 в прошлом. Разработчик хранит информацию в пользовательских элементах управления в массиве где-то и использует ее для доступа к информации за пределами жизненного цикла в пользовательском интерфейсе, который первоначально отображает этот элемент управления.

Этот шаблон нарушает разделение бизнес-логики, модели и пользовательского интерфейса.

Существует тонкая грань между ленивостью и неряшливостью .... повторное использование и неправильное использование. Я все о повторном использовании кода ... но когда разработчик говорит мне, что он хочет использовать пользовательские элементы управления для переноса информации между различными областями программного обеспечения, я думаю, что это приводит к неправильному использованию. Это отрицательно влияет на ремонтопригодность.

Итак, если ответ на вопрос "почему вы хотите?" как-то связано с использованием пользовательских элементов управления для передачи информации, приведенное выше, безусловно, применимо.

P.S. Мне непонятно, с чем это было связано в вопросе, с которым вы связаны. Кроме того, существуют веские причины для привязки к другим элементам пользовательского интерфейса в том же контексте (обычно с использованием относительных источников привязки).

Answer 2

Это действительно сводится к разделению проблем, шаблону проектирования MVVM и, что важнее всего (для меня) тестируемости модулей (и, следовательно, к поддерживаемости кода).

Это проще или сложнее для модульного тестированияколлекция UserControls, как ItemSource?Я бы сказал, что бизнес-логику для юнит-тестирования гораздо сложнее найти в Views.

Как вы, наверное, знаете (и я бы сказал, что это конкретно), основная причина MVVM выросла из необходимости улучшения тестируемостии ремонтопригодность, которую предложил MVC.В WPF MVVM обеспечивает надежное модульное тестирование логических уровней, независимых от уровней представления.

Если ваши логические операции встроены в уровни представления, будет сложнее проводить модульное тестирование, и, следовательно,снова) труднее поддерживать.Я помню из колледжа, и это подтверждает мою профессиональную карьеру: обслуживание плохо спроектированных решений очень дорого по сравнению с общим проектом.

Итак, краткий ответ: разделение представления и логики (поотсутствие таких вещей, как использование ItemsSource of UserControls), экономит деньги вашей компании в течение всего проекта в целом.В частности, в случае WPF существует разделение представления и логики через шаблон MVVM.