2

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

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

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

4

2 回答 2

5

模型类应该有多简单？

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

ViewModel 是将所有内容绑定在一起并提供给视图的粘合剂。

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

是的。为了关注点分离、可测试性或通常不使视图模型层混乱（当正确实施时，模型类可以很容易地在视图模型中重用[POCO-正确地是]）。

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

Model.Entities -- POCO 域对象
Model.Contract -- 业务逻辑接口
Model.* -- 以上的具体实现

这有多个优点：

  • 您的实体（域对象）没有与数据访问层混淆（这往往是常见的滥用）。因此，更换数据层或添加新的数据库支持非常容易，
  • 由于其简单性，实体组件很容易在其他项目中重用（请记住，仅限 POCO），
  • 视图模型只需要了解实体和合同程序集——它们保持干净，并且再次很容易替换/重用实现，
  • 您的项目将保持松散耦合、模块化和灵活。

总体而言，设计/实现模型层时的小错误（或偶然的懒惰）将在项目的后期阶段滚雪球。将整个 DAL 拉到 VM，将第 3 方 API 程序集链接到 VM（“因为模型代码滑倒”），无法编写单元测试都是糟糕的层设计的结果。结果，不是可重用的视图模型，而是每个人都害怕触摸的不可维护的怪物。

于 2013-01-28T19:34:12.767 回答
0

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

于 2013-01-28T19:40:56.083 回答