【问题标题】:Prism: Looking for ideas of how to design apps that don't necessarily comply to a standard region layoutPrism:寻找有关如何设计不一定符合标准区域布局的应用程序的想法
【发布时间】:2011-01-18 00:38:40
【问题描述】:

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

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

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

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

您已经布置了这些模块,并意识到您需要能够为显然是雇员的客户或销售人员显示订单。

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

我开始怀疑如果您正在构建 Outlook 之类的应用程序,考虑使用 prism 构建复合应用程序是否可行,但对于 LOB 业务应用程序,我还没有找到一个很好的示例来说明如何这样做并且不违反 MVVM 的一些原则和 Prism 的定义。

我刚刚进入 Prism 3 周,仍在学习,但这是我遇到的最大问题。

有什么想法吗?

【问题讨论】:

    标签: wpf prism


    【解决方案1】:

    我正在研究一个类似的问题(我也是 Prism 的新手),但还没有解决方案。我认为在使用 Prism 时,很容易将框架用作参考实现的意图,但并非必须如此。

    Prism 应该(如果使用得当)促进软件开发,而不是阻碍它。所以不要太拘泥于任何实现都必须满足严格的解耦重构超级模式化标准的想法!

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

    我在 MainView 上使用 Telerik 的对接管理器(与 Silverlight 和 WPF 兼容),并在基础架构中实现了一个类 IDockingManager / DockingManager 类,该类在引导程序中作为单例 (ContainerControlledLifetimeManager) 在 Unity 中注册。

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

    这是我尚未完成的部分 - 我可以在主视图上停靠左/右/上/下,但我想在我的子视图上实现附加属性或其他东西,在停靠时将它们注册为 DockSite .因此,例如,我可以将 Treeview 停靠在左侧,并使用 Treeview 名称作为父 DockSite 并将 DockBottom 作为侧面停靠在列表视图下方。

    希望这是有道理的,我已经漫无目的的解释了。基本上我所说的是我在这个应用程序中根本没有使用区域(除了注入 MainView),并且创建了一个类来处理视图注入到可停靠容器中。这不是严格意义上的 Prism,但 Prism 可以让我的生活更轻松,而不是相反;)

    【讨论】:

      【解决方案2】:

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

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

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

      在您的特定情况下:

      您已经布置了这些模块,并意识到您需要能够为显然是雇员的客户或销售人员显示订单。

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

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

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2010-12-12
        • 2010-11-08
        • 1970-01-01
        • 2020-05-22
        • 1970-01-01
        相关资源
        最近更新 更多