WPF MVVM模式中的关注点分离

Question

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

目前，我在Models文件夹中有一个Movie类，该类包含电影的所有属性以及设置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（“，因为模型代码”），不可能编写单元测试，这都是不良层设计的结果。结果，你不再使用可重复使用的视图模型，而是找不到每个人都不敢触及的不可维护的怪物。

Answer 2

我想说：将用于下载数据的代码完全移到另一个类中。该模型应该是数据的简单表示。让您的应用程序代码调用您的API帮助程序来下载数据并返回一个简单的模型或模型列表（甚至是模型对象的层次结构）。然后将这些模型包装在视图模型中，并将视图模型提供给视图的DataContext。