WPF Prism + 现有的 WPF 应用程序

Question

我有一个现有的应用程序。

拥有大约3年WPF/MVVM的良好经验 - 我觉得我应该从Prism开始（我目前没有PRISM框架的知识 - 我计划现在学习它）。

目标是 - - 将应用程序变成基于SOLID（设计）的框架。现有代码是MVVM（最近的新功能）和代码后台模型（现有功能）的混合体。

由于这是一个庞大的应用程序 - 将所有内容移动到Prism将是一项相当大的任务。

问题： - 我计划开始新开发（一个大的功能实现）。我可以在新开发中使用Prism吗？我很乐意从头编写大部分组件，并逐步按功能方式移动整个应用程序到Prism。

例如，现有的前台实时交易应用程序，计划向其中添加后台/中台功能，并逐步将前台功能移动到Prism。

• 我有一种感觉，学习PRISM可能会像从winforms到WPF一样需要学习曲线 - 这是真的吗？有关于我应该遵循的书籍的建议吗？我是一位程序性学习者，更喜欢从基础开始逐步学习（即关于Prism的所有内容）。

• 我将获得哪些巨大的优势？在GUI层面上会有任何性能损失吗？

谢谢，Vinay

- Vinay Dwivedi

---

这个问题主要基于个人观点，不符合StackOverflow规定（或任何问答网站的规定）。 - Kryptos

我认为在StackOverFlow上，我们可以寻求专家的意见，不是吗？ - Vinay Dwivedi

你的问题太宽泛了。两个人可能会对使用Prism有不同的看法。Stackoverflow的问题应该是关于具体编程问题的，而不是关于是否使用一个软件/工具是否好的问题。请查看 帮助文档。 - Kryptos

@Dennis OP：“我能在新开发中使用Prism吗？” 简短的回答是，“当然可以，为什么不行呢？”其他答案基于个人观点，因此属于离题。 “我有一种感觉[...]这是真的吗？” == “你有同样的感觉吗？”同样基于个人观点。 - Kryptos

@Dennis，请在说我错之前阅读stackoverflow规则。在现有项目中使用新软件取决于软件本身。你认为这里可以找到一个明确的答案吗？这将如何帮助其他有同样问题的用户。StackOverflow旨在建立知识库。但是这里的问题太广泛了，更适合在论坛中，每个用户都可以发表自己的意见或分享他们自己项目的经验。我不是说这个问题不合法，而是它不适合在这里。 - Kryptos

Answer 1

我推荐官方指南，该指南从定义Prism开始，如下所示：

Prism通过示例和文档提供指导，帮助您轻松设计和构建丰富、灵活且易于维护的Windows Presentation Foundation（WPF）桌面应用程序。使用体现重要架构设计原则的设计模式，例如关注点分离和松散耦合，Prism帮助您设计和构建使用松散耦合组件的应用程序，这些组件可以独立演化，但可以轻松无缝地集成到整个应用程序中。简而言之，这些应用程序是“永久存在”和“为变化而构建”的。这些类型的应用程序称为复合应用程序。

我已经突出显示了最好总结这种应用程序的句子以及他们用来指代这种应用程序的术语：复合应用程序。

如果您的应用程序可以从具有松散耦合模块中获益，则Prism可能是一种选择。例如，在开发ERP时，您可以选择将每个相关功能区域实现为一个模块。您可能需要更加细粒度，并在UI的不同部分使用模块，例如在股票交易员参考实现中。

我并没有发现学习曲线非常陡峭。事实上，该指南组织得相当好，您可以直接进入每个时刻需要的概念，而无需阅读整个内容。这绝不是从WinForms到WPF的变化：它建立在您熟悉的MVVM基础上，添加了一些更高级别的抽象，并使用一些已知的模式，例如发布者/订阅器事件。

最重要的是，对于体量较大的应用程序，通过投资使用Prism，您应该获得可维护性。已经精通MVVM，学习应该很容易。 编辑：回答评论

因此，我可以在现有的WPF应用程序中启动基于PRISM的GUI集吗？

完全可以。您可以使用您认为有用的部分，并最有可能逐渐使用更多。请注意，您可能需要更改应用程序的初始化以实现引导程序。但是，这不是强制性的，因此只需查看模式并开始使用适合您的模式即可。这不是一个全面的框架。

- jnovo

---

非常感谢@jnovo，那么我可以在现有的WPF应用程序中启动基于PRISM的GUI集吗？不想再进一步询问，只是想要一个快速的是/否答案...剩下的我会通过学习来完成。 - Vinay Dwivedi

@VinayDwivedi 请查看编辑。 - jnovo

Answer 2

将现有应用程序迁移到Prism是一项相当大的工程。虽然让应用程序的一部分成为Prism，而另一部分不成为可能，但我认为你会发现自己在这两个世界之间来回切换并找到让它们彼此协作的方法非常令人沮丧。

个人而言，我不会选择这条路。如果您想获得依赖注入的好处，那么逐步采用依赖注入库要比采用规模更大的Prism框架容易得多。具体而言，在构建新功能时，编写它们使其依赖项被注入...最初，这段代码将失败，然后您将转到实际定义每个依赖项的位置，并添加一行代码将其注册到DI容器中。

- Robert Levy

---

感谢您的见解，Robert。我最初考虑采用依赖注入框架的路径。我已经使用基本的SOLID原则编写了DI（所有新开发）。我的想法是编写新组件，然后逐步将其他部分迁移到PRISM中。由于现有的非MVVM代码很难进行单元测试并且具有许多依赖关系，这似乎是不可避免的。我确实有意愿 - 只是想选择正确的路径以获得更好的未来和适应性，您是否预见到其他挑战？ - Vinay Dwivedi

也许，有了这个建议，我会在接下来的几周内创建一个POC，这将是一次学习。非常感谢大家的意见！ - Vinay Dwivedi