c# - WPF MVVM 模式中的关注点分离

Question

我正在使用 WPF 和 MVVM 设计模式编写一个应用程序(我也是 MVVM 模式的新手)。该应用程序管理并跟踪用户观看过的电影。它还需要联系外部网站才能下载电影的元数据。我使用 .NET TMDb 和 Rotten Tomatoes 库来完成此操作。

目前，我有一个Movie Models 文件夹中的类，该类包含电影的所有属性以及设置 TMDb/RT 库、搜索匹配结果，然后下载所有元数据所需的方法和逻辑。然而，这使得我的Movie类比我想象的更加困惑和沉重。

将访问第三方API的方法和逻辑移至MovieViewModel更有意义吗？或者甚至完全是另一门课？模型类应该有多简单？

Answer 1

How simple should the Model classes be?

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

ViewModel 是将它们绑定(bind)在一起并提供给 View 的粘合剂。

Does it make more sense to move the methods and logic for accessing the third party APIs to the MovieViewModel or even another class altogether?

是的。为了关注点分离、可测试性或通常不困惑 View 模型层(当正确实现时，模型类可以在 View 模型中轻松重用[POCO-正确地])。

此外，请考虑进一步分离您的模型:

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

这有多个优点:

• 您的实体(域对象)不会与数据访问层混淆(这往往是常见的滥用)。因此，替换数据层或添加新的数据库支持非常容易，
• 由于其简单性，实体组装可以在其他项目中轻松重用(请记住，仅限 POCO)，
• View 模型只需要了解实体和契约程序集 - 它们保持干净，并且很容易替换/重用实现，
• 您的项目将保持松散耦合、模块化和灵活性。

总的来说，设计/实现模型层时的小错误(或偶然的懒惰)会在项目的后期阶段像滚雪球一样越滚越大。将整个 DAL 拉到 VM、将第 3 方 API 程序集链接到 VM(“因为模型代码丢失了”)、无法编写单元测试都是糟糕的层设计的结果。结果，你最终变成了每个人都不敢碰的难以维护的怪物，而不是可重用的 View 模型。