2

在使用PRISM和Enterprise Library处理具有大量 CRUD 操作的 LOB 桌面应用程序时，我注意到一个重复出现的模式似乎很烦人。对于每个域模型实体（例如 Contact），我发现我用视图模型（例如 ContactVM）自我包装了它，然后我引入了一个新的ContactsVM（注意“s”），其中后一个类接受一个用于填充的存储库接口对于我从存储库中读取ObservableCollection<ContactVM>的每个Contact实体，我将它包装在一个ContactVM中，我通过构造函数将实体与我的 ViewModel 所需的其他企业库服务一起传递给它。

问题是我所有的视图模型构造函数都开始采用这种模式：

ViewModel(EntityToWrap e, DependencyFromEntLib, OtherDependencies ...)

现在这是一个问题，因为大多数工具和库都需要默认的无参数构造函数（例如，一些商业数据网格需要它来提供过滤支持），而且您不能使用设计数据来可视化实体，因为它们也需要无参数构造函数。最后的问题是：构建视图模型的正确方法是什么，Entlib 服务应该通过构造函数还是通过ServiceLocator提供？

4

1 回答 1

11

以下是解决问题的许多不同方法之一。

我更喜欢更轻量级的视图模型。然后我添加一个类，其职责是从一个或多个源（例如存储库）组成视图模型。这并不能消除级联依赖的问题，但它确实释放了您的视图模型构造函数。

它还将逻辑排除在控制器之外，并允许重用视图模型（当然，在适当的时候）。

  • 轻量级视图模型

  • 轻量级控制器知道如何定位组装视图模型的作曲家（您可以使用 DI 框架来设置作曲家及其所有依赖项）。控制器可能在设置过程中起次要作用，但应保持简单。

  • 控制器知道应该如何组装视图模型，并与作曲家类共享。例如，该操作可能会请求一个摘要视图，该视图仍然可以利用相同的视图模型而没有填充任何子项。

  • Composer 组装必要的信息以完成视图模型。Composer 可能会使用其他 Composer 来收集其不直接负责的信息。同样，这里可以使用 DI 框架，这样这些作曲家也可以获得他们需要的依赖项。

  • 控制器像往常一样使用完整的视图模型呈现视图。

在我看来，这也提供了更好的抽象级别。仅仅因为视图模型通常看起来像一个特定的域模型，并不意味着它总是如此。

最终结果：

  • 很多类（缺点，被授予），但代码重复最少（即 DRY）

  • 可测试的瘦视图模型（如果需要......它们可能不包含任何要测试的内容）

  • 纤薄、可测试的控制器。

  • 可测试的作曲家对象可以在不同的场景中重用，因为它们（大概）知道如何为各种目的组装视图模型。

  • 灵活混合和匹配视图模型、控制器和合成器以支持不同的场景。

于 2013-01-03T02:14:48.580 回答