MVVM какая часть паттерна отвечает за группировку datagrid

Я возился с шаблоном MVVM, и теперь я пытаюсь реализовать небольшое приложение на его основе.

В этом приложении есть датагрид, в котором, как ни странно, представлены некоторые данные. Теперь я пытаюсь добавить к нему возможность группировки. Я знаю, как написать это в коде (C# и XAML), но мне интересно, в какой слой я должен поместить ответственный код.

Одна часть меня говорит мне, что это должно быть в представлении, потому что это код специально для этого конкретного представления. Он не является общим и служит одной цели: группировать данные.

С другой стороны, я думаю, что должен обрабатывать это в ViewModel с помощью команды. Однако мне кажется, что я загрязняю свою ViewModel логикой, специфичной для View.

Любой свет, который можно пролить на это?


mvvm c# wpf separation-of-concerns responsibility
person user362397    schedule 11.06.2010    source источник

Ответы (3)


arrow_upward
7
arrow_downward

В большинстве своих приложений MVVM я пытаюсь разделить обязанности следующим образом:

  • Представление должно просто выполнять простой перевод данных модели представления в пиксели. Обычно это приводит в основном к XAML и очень небольшому количеству кода.
  • Модель представления должна выполнять специфическую для представления логику, такую ​​как группировка и т. д. У меня часто даже есть несколько моделей представления для каждого представления. У вас может быть основная модель представления, которая предоставляет список подмоделей представления для каждой группы для вашего представления, например, для реализации группировки.
  • Если у вас есть какая-либо логика, которая применяется к более чем одной модели представления, вероятно, это логика предметной области, и она должна войти в модель предметной области.

Поэтому я думаю, что группировка должна идти в модели представления.

person Mendelt    schedule 11.06.2010
comment
+1 Я думаю, что и VM тоже... Другим моментом будет возможность тестирования - вы захотите протестировать логику группировки без необходимости создания экземпляра представления. - person kiwipom; 11.06.2010
comment
@IanR Как я мог забыть угол тестируемости? :-) Хорошая точка зрения. - person Mendelt; 11.06.2010
comment
@IanR Как я мог забыть угол тестируемости? :-) Хорошая точка зрения ;) - person user362397; 11.06.2010

arrow_upward
0
arrow_downward

На это нет единого ответа. Это действительно зависит от вашего сценария:

1) Имеет ли пользователь какое-либо влияние на этот вопрос? Если они этого не делают и это фиксированная группа, я бы опубликовал свойство с помощью IGrouping и использовал службу данных или LINQ, чтобы сделать это до того, как оно войдет в представление.

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

person Goblin    schedule 11.06.2010
comment
У пользователя есть, это тестовый пример для проверки применимости WPF в нашем следующем большом проекте. В этом сценарии пользователь имеет полный контроль над сеткой данных. Группировка, сортировка и фильтрация должны максимально настраиваться пользователем. - person user362397; 11.06.2010
comment
Хорошо, тогда вы можете проверить сетку данных XCeed (xceed.com/Grid_WPF_Intro.html) или Infragistics. datagrid (infragistics.com/dotnet/netadvantage/wpf/ у них есть встроенная поддержка такого рода вещей. - person Goblin; 11.06.2010

arrow_upward
0
arrow_downward

если пользователь имеет некоторое влияние на группировку, я бы привязался к ICollectionView, предоставляемый ViewModel. Представление поддерживает группировку, фильтрацию, сортировку и валюту, а интерфейс ICollectionView создан из System.ComponentModel, поэтому вам не нужно добавлять ссылку «gui» в проект ViewModel. Также WPF DataGrid поддерживает интерфейс ICollectionView.

Если пользователь не имеет никакого влияния на группировку (группы фиксированы), я бы просто «предварительно» сгруппировал данные в модели. ХТН.

person andyp    schedule 09.07.2010