WPF MVVM模式中的关注点分离

Question

我正在使用WPF和MVVM设计模式编写应用程序(我也是MVVM模式的新手).此应用程序管理和跟踪用户观看的电影.它还需要联系外部网站以下载电影元数据.我是通过使用.NET TMDb和烂番茄库来做到这一点的.

目前,我Movie在Models文件夹中有一个类,该类包含电影的所有属性以及设置TMDb/RT库,搜索匹配结果,然后下载所有元数据所需的方法和逻辑.然而,这使我的Movie班级比我认为的应该更加混乱和沉重.

将用于访问第三方API的方法和逻辑移动到MovieViewModel甚至是另一个类是否更有意义？Model类应该有多简单？

Answer 1

Model类应该有多简单？

通常,POCO-简单.将模型层视为域对象定义 + 业务逻辑是安全的.域对象通常只是数据持有者(如提到的POCO类),而业务逻辑是执行应用程序所请求的功能所需的任何内容(数据检索,持久性,与其他API的通信等).

ViewModel是粘合剂,它将它们全部绑定在一起并提供给视图.

将用于访问第三方API的方法和逻辑移动到MovieViewModel甚至是另一个类是否更有意义？

是.为了分离关注点,可测试性或通常不会使视图模型层混乱(模型类在正确实现时可以在视图模型中轻松重用[正确的POCO]).

另外,请考虑进一步分离您的模型:

Model.Entities -- POCO domain objects
Model.Contract -- interfaces for your business logic
Model.*        -- concrete implementations of above

这有多个优点:

• 您的实体(域对象)不会与数据访问层混淆(这往往是常见的滥用).因此,替换数据层或添加新的数据库支持非常容易,
• 由于其简单性,实体组装在其他项目中很容易重复使用(请记住,仅限POCO),
• 视图模型只需要知道实体和合同程序集 - 它们保持干净,再一次很容易替换/重用实现,
• 您的项目将保持松散耦合,模块化和灵活.

总的来说,在设计/实施模型层时,轻微的错误(或偶然的懒惰)将在项目的后期非常滚雪球.将整个DAL拉到VM,将第三方API程序集链接到VM("因为模型代码滑落"),编写单元测试的不可能性都是不良层设计的结果.因此,您不会使用可重复使用的视图模型,而是会导致每个人都不敢触及的无法维护的怪物.