使用 MVVM ViewModel 将 XDocument 显示为 WPF 树视图
我将 XSD 作为数据保存在 SQL Server XML 或 Oracle XMLtype 字段中。我从数据库中检索 XSD 作为 XDocument。我想在 WPF 树视图中显示此 XDocument。如果我使用 xmldataprovider 和 hierarchicalDataTemplate 将 Xdocument 直接绑定到树视图，则这是相对简单的。
但是，我的应用程序使用 mvvm 模式，我想在 ViewModel 层中表示 xdocument，然后将树视图绑定到该 xdocument，其方式与 Josh Smith 关于将 WPF 树视图绑定到 ViewModel 的文章类似。 http://www.codeproject.com/KB/WPF/TreeViewWithViewModel.aspx
我的目标是选择 XSD（XDocument）的 XNode。
关于如何在 ViewModel 中表示 XSD 的 Xdocument 以便我可以选择 XNode，有什么建议吗？
I have XSD's held as data in a SQL Server XML, or oracle XMLtype field. I retrieve an XSD from the database as an XDocument. I want to display this XDocument in a WPF treeview. This is relatively straight forward if I bind the Xdocument directly to the treeview using an xmldataprovider and a hierarchicalDataTemplate.
However, my application is using the mvvm pattern and I would like to represent the xdocument in the ViewModel layer, which the treeview then binds to in a similar way to the Josh Smith article on binding the WPF treeview to ViewModels.
http://www.codeproject.com/KB/WPF/TreeViewWithViewModel.aspx
My goal is to select an XNode of the XSD (XDocument).
Any suggestions for how I could represent the Xdocument of an XSD in the ViewModel so that I can select an XNode?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您正在进行只读操作，我建议您保持简单，并且不要引入没有任何好处的新类。只需留下评论，如果您想支持编辑结构，则应该添加视图模型。即使您希望能够编辑文档，您仍然可以根据需要直接绑定到文档和节点。
如果您需要更高级的支持（例如
INotifyPropertyChanged），我建议您基于XObject创建类似于原始 API 的类层次结构。我只会添加计划在 UI 中直接支持的属性。然后，我将创建一个单独的模型类，它可以从XDocumentViewModel层次结构转换为真正的XDocument，然后再转换回来。你说的选择是什么意思？
如果您的意思是在 UI 中，那么这将在 XAML 中处理。
如果您正在谈论查询视图模型，那么您可以尝试对基础文档使用现有的 LINQ XML 查询 API。保留一个将 XObject 映射回视图模型对象的内部字典，当您获得结果时，只需在返回之前在字典中查找每个结果即可。
If you're doing read-only operations, I'd recommend that you keep it simple and don't introduce new classes that provide no benefit. Just leave a comment that you should add a view model if you ever want to support editing the structure. Even if you want to be able to edit the document, you might still be able to bind to the document and nodes directly, depending on your needs.
If you need more advanced support (like
INotifyPropertyChanged), I suggest that you create a hierarchy of classes like the original API, based onXObject. I would only add properties that I planned on directly supporting in the UI. I would then create a separate model class that could convert from theXDocumentViewModelhierarchy to a realXDocument, and back.What do you mean by select?
If you mean in the UI, then that's taken care of in the XAML.
If you're talking about querying the view model, then you could try to use the existing LINQ XML querying API against the underlying document. Keep an internal dictionary mapping XObjects back to your view model objects, and when you get results, simply look up each result in the dictionary before returning it.