使用XML模型和LinqToXml实现MVVM?

3
我一直在研究MVVM模式,想在一个相对较小的WPF项目中尝试它。该应用程序将是单用户的。输入和输出数据都将存储在一个“关系型”XML文件中。使用带有键和键引用的模式(XSD文件)来验证文件。
我还开始涉足Linq和LinqToXml,并编写了几个相当复杂的查询(小胜利:))。
现在,我正在尝试将所有这些内容整合起来,但我发现我有点困惑,不知道应该将什么放在Model中,将什么放在ViewModel中。以下是我迄今为止一直在努力解决的选项:
1. 我是否应该将Model视为XML文件本身,并将所有的LinqToXml查询放在ViewModel中?换句话说,甚至不编写名为Model的类?
2. 我是否应该编写一个只是简单包装XML文件和XSD Schema Set并执行验证、保存更改等的Model?
3. 我是否应该将“基本”查询放在Model中,而将“视图特定”的查询放在ViewModel中?如果是这样,那么在这两个类别之间应该画哪条线?
我意识到这个问题可能没有一个“正确”的答案……我只是在寻求建议和利弊分析,如果有人知道类似场景的代码示例,那就太好了。
谢谢,
-Dan
2个回答

3
对于一个小型应用程序来说,拥有单独的数据访问层、领域模型和表示模型层可能会显得过度,但是像这样对应用程序进行建模将有助于您决定哪些内容应该放在哪里。即使您不想将应用程序分解为三个不同的项目/库,思考每个功能块应该放在哪里也可以帮助您做出决策。
在这种情况下,纯数据访问(即加载XML文件、查询和更新)属于数据访问层,因为这些是技术特定的。
如果您有任何与特定数据访问技术无关的操作,但可以被视为通用于应用程序领域的操作,则应将其放入领域模型(或某些人所称的业务逻辑)中。
任何仅提供特定用户界面技术(在您的情况下为WPF)特定功能的逻辑应该放在表示模型中。
在您的情况下,XML文件和所有LINQ到XML查询都应该放在数据访问层中。
要使用MVVM,您需要为每个要在应用程序中拥有的视图创建一个ViewModel。
从您的问题中,我不清楚是否有任何可以被视为领域模型的东西,但是验证之类的功能是一个很好的选择。这样的功能应该放入领域模型中。领域模型中的任何类都不应直接绑定到视图。相反,ViewModel负责在领域模型和视图之间进行转换。
所有与WPF相关的东西都应该放在ViewModel中,而应用程序中的其他类则应该不知道WPF。

谢谢,马克。听起来我需要比我在问题中提到的第三点更进一步,并将所有查询放入模型(领域模型),即使我编写了查询以支持特定的视图。我看到了一些优点:(1)我可以将我的XML数据库更改为SqlServer数据库,我的ViewModel不需要更改(尤其是如果我为我的Model编写接口)。 (2)如果特定查询是为了支持View A而编写的,但稍后我意识到我需要相同的数据来查看View B,我不需要进行任何重构即可访问数据。缺点是在模型中有很多“自定义”内容。 - devuxer
@DanThMan:是的,你已经列出了自己的好处 :) 通常情况下,优点总是伴随着缺点; 在这种情况下,主要的缺点是增加了复杂性。您需要在应用程序的上下文中权衡利弊,但对于除最简单的应用程序外,优点远大于缺点。我唯一的更正是所有查询都需要进入数据访问层,并隐藏在不透明的方法后面-而不是在域模型中。 - Mark Seemann

0

Scott Hanselmen有一个播客,与非常了解WPF的Ian Griffiths一起详细介绍了这个主题,并共同编写了O'Reilly书籍《Programming WPF》。

Ian Griffiths解释的Windows Presentation Foundation
http://hanselminutes.com/default.aspx?showID=184

简短(遗憾而不完整)的答案是视图包含可视对象和最小逻辑以操作它们,而View Model则包含这些对象的状态

但请收听播客。 Ian比我说得更好。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接