无DI框架的Prism用于WPF的优势

我正在与其他非常支持Prism的WPF应用程序开发人员一起工作，但我不了解它的好处。我得到了依赖注入框架和EventAggregator的模块化思想。然而，如果没有这两件事，使用棱镜有什么核心优势吗

基本上，我不知道为什么我需要动态加载视图并将它们放置在区域中，而我在开发过程中已经知道它们将去哪里，并且它们永远不会改变

---

我在网上找到的所有东西都表明DI的优势是Prism的唯一优势。我还缺少什么吗？

PRISM提供了一个以模块化方式组合应用程序的框架。因此，您不必将视图注入到某个区域中，但它使该区域更加灵活。您可以更轻松地使用不同的视图，并将它们注入到您的区域中

我同意DI可能是PRISM最常用的功能，也可以说是使用它最有说服力的理由。一般来说，没有必要使用PRISM，尤其是当你的应用程序足够小的时候，但它确实使它在将来的变化中更加灵活。解耦组件很好，PRISM提供了实现这一点的方法（不是唯一的方法）

---

HTH.

我确实大量使用区域和导航。它可能不适用于您的场景，但在我的例子中，我在TabControl（通过导航）中打开了多个视图。传递参数（查询字符串）和控制目标（NavigationWare）的能力对我来说是一件大事

假设您拥有与客户和订单的UI。您可以看到客户和他的订单。你点击特定的顺序，另一个页面打开。猜猜看，您可以通过如下导航方式访问订单视图：

/OrderView

/OrderView？OrderKey=123

第一个将打开您的视图。第二个将打开并导航到您需要的订单。您还可以将链接从订单视图放置到客户视图

/CustomerView-将打开新客户屏幕

/CustomerView？CustomerKey=123-将打开您的客户或导航回您已打开的视图

如果您关心这样的场景，PRISM会有所帮助

如果您的团队在同一视图上使用区域，我也看不到有什么好处。我没有这样的区域

另一个示例使用：

我有一个带区域的MenuStackPanel。根据用户权限，应用程序将加载此用户可以使用的模块。当模块加载时-它们注册它们的片段并用它们的选项填充菜单。

My IMHO

如果您对PRISM的想法是错误的：

• 棱镜是一个框架。因此，您可以独立使用它的任何部分。它包括DI容器、导航框架、EventAggregator、DelegateCommand、NotificationObject、模块化结构、区域和许多其他内容
• DI与PRISM没有任何关系。这是一件独立的事情。您可以很容易地使用Unity（或MEF，但这不是真正的DI容器），而无需PRISM。PRISM只是提供了一些所有东西的集成

我对棱镜的看法：

• “他们永远不会改变”-如果你已经知道了，离开这个项目。若项目永远不会改变，那个么它就死定了。根据我的经验，如果项目有效，任何事情都可以改变。即使是不变的东西。我曾与一家保险公司密切合作，他们说有一件事永远不会改变。他们有几十万客户。5年后，情况发生了变化。。。天气很凉爽。感谢上帝，我一直认为任何事情都可以改变
• PRISM的另一个优点是“标准化”——所有标准类都有相同的名称，它们具有相同的属性和方法，您的项目具有标准结构等
• PRISM的区域为XAML提供了一些DI的类比。没有它你能做到吗？你当然可以。但同样——这是“标准”方式。你可以很容易地跳转到另一个项目，你将不会研究另一个“穷人框架”

---

再说一次，这是我的IMHO。当然，我可能错了。

对于需要动态更改的应用程序，我可以理解。但是，大多数应用程序不需要这样做。他们确切地知道什么会去哪里。我认为在XAML视图中指定要容易得多。正如我说的，我确实喜欢DI。