MVVM 模式的哪一部分负责数据网格的分组
我一直在修改 MVVM 模式，现在我正在尝试基于它实现一个小应用程序。
该应用程序有一个数据网格，令人惊讶的是，其中显示了一些数据。现在我正在尝试为其添加一些分组功能。我知道如何用代码（C# 和 XAML）编写此内容，但我想知道应该将负责的代码放在哪一层。
我的一部分告诉我它应该在视图中，因为它是专门针对该特定视图的代码。它不是通用的，只有一个目的：对数据进行分组。
另一方面，我认为我应该使用命令在 ViewModel 中处理它。不过，感觉好像我正在用视图特定的逻辑污染我的视图模型。
有什么可以阐明这一点吗？
I've been tinkering around with the MVVM pattern and now I'm trying to implement a little application based on it.
This application has a datagrid in which, surprisingly enough, some data is presented. Now I'm trying to add some grouping ability to it. I know how to write this in code (C# and XAML), but I'm wondering in what layer I should put the responsible code.
One part of me tells me it should be in the view, because it's code especially for that specific view. It's not generic and serves one purpos: to group the data.
On the other hand I think I should handle it in the ViewModel using a command. It feels, though, as if I'm contaminating my ViewModel with View specific logic.
Any ligt that can be shed on this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在我的大多数 MVVM 应用程序中，我尝试像这样划分职责：
将视图模型数据转换为
像素。通常，这会导致大部分 XAML 和很少的隐藏代码。
特定于视图的逻辑，例如分组
等等。我什至经常每个视图有多个视图模型。您可以拥有一个主视图模型，该主视图模型将每组的子视图模型列表公开给您的视图，例如以实现分组。
可能有不止一个视图模型
领域逻辑，应该进入
域模型。
所以我认为分组应该放在视图模型中。
In most of my MVVM apps I try to divide responsibilities like this:
translation of viewmodel data to
pixels. Usually this results in mostly XAML and very little code behind.
view-specific logic like grouping
etc. I often even have multiple viewmodels per view. You can have a main viewmodel that exposes a list of sub-viewmodels per group to your view for example to implement grouping.
more than one viewmodel it's probably
domain logic and should go into the
domain model.
So I think grouping should go in the viewmodel.
对此没有一个答案。这实际上取决于您的场景：
1）用户对此事有任何影响吗？如果不这样做，并且它是固定分组，我将使用 IGrouping 发布一个属性，并在进入视图之前使用数据服务或 LINQ 来完成此操作。
如果您在视图中进行分组，通常性能会降低，但这不是一个明确的选择。如果用户可以选择许多不同的分组，那么这可能是为了增加可用性而付出的代价。
There is no one answer to this. It really depends on your scenario:
1) Does the user have any influence on the matter? If they do not, and it's a fixed grouping, I'd publish a property with IGrouping and use the dataservice or LINQ to do it before it enters the view.
It is typically less performant if you do grouping in the view, but it's not a clear-cut choice. If the user can select a lot of different groupings, this might be a penalty worth paying for the added usability..
如果用户对分组有一些影响，我会绑定到 ICollectionView 由 ViewModel 公开。该视图支持分组、过滤、排序和货币，并且 ICollectionView 接口来自 System.ComponentModel，因此您不必向 ViewModel 项目添加“gui”引用。 WPF DataGrid 还支持 ICollectionView 界面。
如果用户对分组没有影响（组是固定的），我只需对模型中的数据进行“预”分组。 HTH。
if the user has some influence on the grouping I'd bind to an ICollectionView exposed by the ViewModel. The view supports grouping, filtering, sorting and currency and the ICollectionView interface is from System.ComponentModel so you wouldn't have to add a "gui" reference to your ViewModel project. Also the WPF DataGrid supports the ICollectionView interface.
If the user has no influence on the grouping (the groups are fixed) I'd just "pre"-group the data in the model. HTH.