MVP/MVVM - фильтрация списков, кто несет ответственность?

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

Мы используем структуру MVVM.

Мой вопрос, чья ответственность заключается в том, чтобы отфильтровать список? Вид или viewmodel? Должен ли я реализовать событие OnTextChanged в xaml.cs или использовать свойство в ViewModel и использовать PropertyChanged для фильтрации списка. Последующий вопрос: должен ли я использовать BindingList/ObservableCollection в ViewModel или использовать ICollectionView для привязки ItemsControl к?

Я пробовал оба метода, и они оба работают. Предоставление ViewModel несет ответственность за сохранение кода из View, но, с другой стороны, я не полностью убежден, что ответственность за фильтрацию (например: разные представления могут потребовать различной фильтрации) - это ответственность ViewModels.

Любые мысли?

спасибо, Рул

EDIT:

Что меня беспокоит в том, чтобы поместить его в ViewModel, так это то, что (в моей текущей реализации) есть ссылка на System.Windows.Data. Это ссылка, которую я бы предпочел не иметь в ViewModel, потому что это явно что-то вроде View related. Или я чего-то не хватает? соответствующий код:

ICollectionView customerView = CollectionViewSource.GetDefaultView(customers);

Ответ 1

ViewModel, без всяких сомнений. Избегание кодового задержек является конечной целью шаблона - на самом деле, сам ViewModel является кодовым представлением.

например: разные виды могут потребовать различная фильтрация

Различные представления должны иметь разные ViewModels. ViewModel - это в основном (несколько более) объектно-ориентированный подход к файлам с кодом.

Что касается CollectionView: вы можете определить CollectionViewSource в представлении XAML, а затем привязать его свойства сортировки и фильтрации к ViewModel. Это должно держать контроль в ViewModel и CollectionView в поле зрения, но я считаю, что это слишком сложно.

Ответ 2

Вы можете проверить эту статью в своем блоге, где я использую методологию MVVM для фильтрации коллекции элементов. Я думаю, что это определенно ответственность класса VM.

Ответ 3

Я думаю, что такая функция фильтрации принадлежит модели viewmodel. Помните, что вы хотите сохранить как можно больше тестового кода в viewmodel (который вы будете тестировать на модуле, правильно?). И наоборот, вы хотите сохранить представление скудным и средним.

Функциональность фильтрации является общей и не связана с представлением как таковым. Но если другому представлению нужна другая фильтрация, вы должны увидеть это как дополнительную функциональность, поддерживаемую viewmodel.

Ответ 4

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

Но если вы можете параметризовать фильтрацию на что-то очень простое, например. текстовое свойство "Регион", которое может быть настроено на "Европа", "Северная Америка", "Айса" и т.д., которое довольно легко понять и само проверяемо. Это позволяет вам крошечный контроль над функциональностью (в очень ограниченном смысле) в представлении. Если это имеет какое-то значение для ваших усилий, тогда сделайте это. Если это не так, не делайте этого.

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

Ответ 5

Я согласен с вами в том, что беспокоит, что в VieModel есть утечка технологии View. В аналогичном ключе я использую объект RelayCommand в моих моделях ViewModels, который использует System.Windows.Input.

По всем причинам, изложенным здесь, я думаю, что ViewModel является правильным выбором дизайна для этого носителя (wpf/silverlight), хотя он менее совершенен.