查看模型和依赖注入

Question

在使用PRISM和Enterprise Library进行大量CRUD操作的LOB桌面应用程序中，我注意到似乎令人讨厌的重复模式。对于每个领域模型实体（例如联系人），我发现自己用视图模型（例如ContactVM）包装它，然后引入一个新的ContactsVM（注意's'）后一类接受存储库接口的地方，该接口用于填充ObservableCollection<ContactVM>和我从存储库读取的每个Contact实体，我将它包装在一个ContactVM中，我通过构造函数将实体传递给ViewModel所需的其他企业库服务。

的问题是，我所有的视图模型构造开始采取这种模式是这样的：

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

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

Answer 1

以下是解决该问题的多种方法之一。

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

它还将逻辑保留在控制器之外，并允许视图模型被重用（当然，当然适用）。

• 轻量级视图模型

• 轻型控制器知道如何定位是组装视图模型作曲家（你可以使用DI框架设置及其所有依赖的作曲家）。控制器可能在设置过程中扮演一个小角色，但它应该保持简单。

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

• Composer组装完成视图模型所需的信息。作曲家可以使用其他作曲家收集它不直接负责的信息。同样，可以在这里使用DI框架，以便这些作曲者也可以获得他们所需的依赖关系。

• 控制器像完成视图模型一样渲染视图。

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

最终结果是：

• 大量的类（一个缺点，授予），但很少的代码重复（即DRY）

• 薄视图模型，其是可测试的（如果需要的话..他们可能不包含任何测试）

• 薄的，可测试的控制器。

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

• 灵活地混合和匹配视图模型，控制器和作曲家以支持不同的场景。