Prism：寻找如何设计不一定符合标准区域布局的应用程序的想法

Question

我有一个应用程序，其中有几个具有完全不同功能的模块，我正在尝试找出使用 prism 实现此功能的最佳方法。

为了更好地解释，我将尝试使用 Northwind 为例。我有 3 个模块：订单、客户和订单。雇员。

客户模块将允许您执行与客户相关的任何操作。添加、删除和编辑。我将使用客户模块中主视图的范围区域来处理我需要在此处显示的所有不同视图。

在上面的场景中，我只想在用户想要与客户、订单或员工合作时加载模块。

您布置了这些模块，并意识到您需要能够向显然是员工的客户或销售人员显示订单。

在这种情况下，您会做什么，因为您不想为雇员订单和客户订单创建全新的模块，并且您不想复制任何订单相关的代码。

我开始怀疑，如果您正在构建 Outlook 这样的应用程序，那么考虑使用 Prism 构建复合应用程序是否可行，但对于 LOB 业务应用程序，我还没有找到如何执行此操作的良好示例，并且为此，不要违反 MVVM 的一些原则和 Prism 的定义。

我刚使用 Prism 3 周，仍在学习，但这是我遇到的最大问题。

有什么想法吗？

Answer 1

对于这些类型的通信场景，您应该使用事件聚合器。本质上，您希望模块提供功能，但也公开可以从其他模块调用的事件。您还可以在 Unity 容器中注册服务。例如：

public interface ICustomerOrderInvoker 
{
    void DisplayCustomerOrdersInRegion(string customerId, string regionName);
}

这些技术在某种程度上与 MVVM 正交。您的事件处理程序可以创建视图/视图模型对并将它们插入到区域中。或者，您的事件处理程序可以创建一个 UserControl，其所有功能都在后面的代码中实现，并将其添加到一个区域。复合 UI 的美妙之处在于，您的模块可以使用 MVVM，而另一个团队的模块可以使用直接的用户控件、MVP 或 MVC 或任何其他东西；关键是所有模块都被组合成一个应用程序，无论它们如何实现，因为它们使用 Prism 中建立的模式，如区域、事件等。

在您的特定情况下：

您布置了这些模块，并意识到您需要能够向显然是员工的客户或销售人员显示订单。

您的订单模块肯定会知道客户 ID 的概念，因为订单实体与客户相关联。 Order 模块应该公开一个 CompositePresentationEvent，该事件显示一个包含特定客户 ID 的所有订单的视图。

Prism 的重点是创建逻辑上独立且松散耦合的功能块。这并不意味着模块之间不进行通信，而是通信以有限且松散耦合的方式进行。您当然可以使用此模式和 MVVM 编写 LOB 应用程序；我们中的许多人已经这样做很多年了。 :)

Answer 2

我正在研究类似的问题（而且我也是 Prism 新手），但目前还没有解决方案。我认为在使用 Prism 时，很容易将框架用作参考实现的意图，但事实并非如此。

Prism 应该（如果使用正确）促进软件开发，而不是阻碍它。因此，不要太执着于任何实现都必须满足严格的解耦重构超级模式化标准的想法！

我正在做/打算做的是创建一个 MainModule，其中包含我的许多核心功能，包括 MainView/MainViewModel 用户控件。然后，Shell 有一个区域“Main”，并且在 MainModule 加载时，MainView 将按照标准棱镜用法注入其中。

我在 MainView 上使用来自 Telerik 的 Docking Manager（与 Silverlight 和 WPF 兼容），并在基础设施中实现了类 IDockingManager / DockingManager 类，该类在 Unity 中注册为引导程序中的单例 (ContainerControlledLifetimeManager)。

在我的应用程序中的任何位置，我都可以获取 IDockingManager 实例并通过调用 IDockingManager.DockView(IView view, DockingParameters args) 注入视图。 DockingParameters 可以包含诸如停靠位置（左、右、上、下、选项卡式文档）以及要停靠的父容器等信息。

这是我还没有完成的部分 - 我可以停靠左/右/主视图上的顶部/底部，但我想在我的子视图上实现附加属性或某些内容，在停靠时将它们注册为 DockSite。例如，我可以将 Treeview 停靠在左侧，并将 Treeview 停靠在列表视图下方，方法是使用 Treeview 名称作为父 DockSite，使用 DockBottom 作为侧面。

希望这是有道理的，我已经胡言乱语了，没有真正解释得很好。基本上我想说的是，我在这个应用程序中根本不使用区域（除了注入 MainView），并且创建了一个类来处理可停靠容器中的视图注入。严格来说，它不是 Prism，但 Prism 的存在是为了让我的生活更轻松，而不是相反；）