在运行时动态指定和更改 Silverlight DataGrid 的列 (MVVM)

发布于 2024-08-31 16:13:21 字数 691 浏览 0 评论 0原文

在运行时遵循 MVVM 模式在 Silverlight DataGrid 控件中动态指定 DataGrid 列的最佳方法是什么?

我想要做的是将“DataGrid.Columns”属性绑定到我的 ViewModel 中的属性,这样,如果用户添加/删除列,我只需更新 ViewModel 属性,DataGrid 就会发生变化。问题是,“DataGrid.Columns”属性无法绑定(我不认为)。

由于此属性不可用,DataGrid 控件本身在 ViewModel 级别也不可用,因此我当前的方法是跳出此特定实现的 MVVM 模式,并使用 MVVM Light 的 Messenger 类捕获 View 代码隐藏中的某些事件,然后直接与 DataGrid 控件对话即可实现此功能。我知道这是对这种方法的一般性陈述,没有详细信息,但是有没有一种更简单的方法……或者可能不是那么容易,但是更好地遵循 MVVM 模式的更好方法?

DataGrid 控件的 Columns 属性无法绑定,这让我抓狂……看起来很简单。

仅供参考 - 在建议使用 AutoGenerateColumns = True 之前,绑定到 DataGrid.ItemsSource 的集合中每个项目绑定的类没有单独的属性来标识绑定到列的内容...它是一个集合属性,其中包含列,以保持它们完全动态,从而排除特定路径。此外,由于同样的原因,处理 AutoGenerateColumns 并使用 e.Cancel 显示/隐藏列也不确定(我认为)。

What's the best method of dynamically specifying DataGrid columns in the Silverlight DataGrid control at runtime following the MVVM pattern?

What I'd like to do would be bind the "DataGrid.Columns" property to a property in my ViewModel so that, if the user adds/removes columns, I simply update the ViewModel property and the DataGrid would change. Problem is, the "DataGrid.Columns" property can't be bound to (I don't think).

Because this property isn't available nor is the DataGrid control itself available at the ViewModel level, my current approach is to step outside of the MVVM pattern for this particular implementation and capture certain events in View's code-behind using MVVM Light's Messenger class and then talk directly with the DataGrid control to achieve this capability. I know this is a general statement to this approach without details but is there an easier way... or maybe not so much easier, but a better way that adheres to the MVVM pattern a little better?

It's driving me crazy that the DataGrid control's Columns property can't be bound... seems like such a simple thing.

FYI - Before it's suggested to use AutoGenerateColumns = True, the class being bound for each item in the collection that's bound to DataGrid.ItemsSource does not have individual properties to identify what is bound to the columns... it's a collection property that contains the columns in order to keep them completely dynamic so that particular path is out. Also, handling the AutoGeneratingColumns and using e.Cancel to show/hide columns is also iffy for this same reason (I think).

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

橘寄 2024-09-07 16:13:21

我同意 DataGrid.Columns 无法绑定是一种痛苦。我的建议是在 ObservableCollection 的 ViewModel 中定义列。在View(后面的代码)中,处理此ObservableCollection的CollectionChanged事件,并修改代码中的DataGrid.Columns。

虽然这个解决方案不太优雅,但很简单。对于您的 ViewModel,您可以对在添加、删除或移动列时是否正确引发 CollectionChanged 事件进行单元测试。视图代码无法测试,所以我想这是您需要忍受的事情。优点是,如果有一天 DataGrid.Columns 属性可以进行数据绑定,那么将很容易重构它以删除后面的代码。

另一种方法(我认为)是创建附加行为或混合行为来解决这个问题。将其附加到 DataGrid;不要直接绑定到 DataGrid.Columns,而是绑定到行为的属性,并让行为直接修改 DataGrid(AssociatedObect)。

这有道理吗?
干杯,
洛朗

I agree that it is a pain that DataGrid.Columns cannot be bound to. My recommendation here would be to define your columns in the ViewModel in an ObservableCollection. In the View (code behind), handle the CollectionChanged event of this ObservableCollection, and modify the DataGrid.Columns in code.

While this solution is less elegant, it is straightforward. For your ViewModel, you can unit test that the CollectionChanged event is raised properly when columns are added, removed or moved. The View code cannot be tested, so I guess this is something you need to live with. The advantage is that, if some day the DataGrid.Columns property can be databound, it will be easy to refactor this to remove the code behind.

Another way (I think) would be to create an attached behavior or a Blend behavior to take care of this. Attach it to the DataGrid; instead of binding to the DataGrid.Columns directly, bind to a property on the behavior, and have the behavior modify the DataGrid (the AssociatedObect) directly.

Does that make sense?
Cheers,
Laurent

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文