我为什么要使用棱镜？
我有兴趣制作一个像样的 WPF 应用程序，该应用程序将非常庞大。 有人建议使用我们目前正在研究的 PRISM。 我们可能会使用 MVVM 模式来实现此应用程序。 我看了一些 PRISM 截屏视频，似乎 PRISM 主要用于注入具有不同视图的区域。 这是使用 PRISM 的主要目的吗？
我始终可以通过 ContentPresenter 使用 WPF MasterPages，那么为什么我应该使用 PRISM 来实现区域目的呢？
I am interested in making a decent WPF application which will be pretty huge. Someone suggested using PRISM which we are currently looking into. We might be using the MVVM pattern to implement this application. I saw some PRISM screencasts and it seems like PRISM is mainly used to inject the regions with different views. Is that the main purpose of using PRISM?
I can always use WPF MasterPages using ContentPresenter so why should I use PRISM for the region purpose?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
Prism 提供的不仅仅是区域系统。 不详尽：
区域系统也不仅仅是一个“内容呈现器包装器”。 它可用于“推”（将视图放入某个区域）或“拉”（让模块声明它们填充的区域）。 它还支持的不仅仅是简单的内容呈现器区域（例如基于 ItemsControl 的区域），并且可以通过区域适配器进行扩展。
最后但也许并非最不重要的一点是，当您采用 Prism 的形式主义时，您就押注于一种外人可能已经知道的通用“语言”（几乎是框架，即使 Prism 团队并不这样称呼它），而不是重新发明你自己的，这需要有人学习一套全新的东西。 对于一个长期存在的项目来说，这可能是一件好事（前提是 Prism 显然不会死得太早）。
Prism offers a bit more than the region system. Not exhaustively:
The region system is also more than simply a "content presenter wrapper". It can be used to "push" (put a view into a region) or "pull" (let modules declare which region they populate). It also support much more than simple contentpresenter regions (ItemsControl based regions for example) and is extensible through region adapters.
Last, but maybe not least, when you adopt Prism's formalism, you bet on a common "language" (and almost framework, even if the prism team doesn't call it like that) that outsiders may already know, instead of re-inventing your own which would require someone to learn a whole new set of things. It can be a good thing for a long-lived project (provided Prism does not die too young obviously).
如果您已经以页面的各个子组件独立的方式合成页面，那么 PRISM（或先驱复合 UI 应用程序块）除了公认的“标准”合成方式之外并没有真正为您带来太多帮助这是有记录的。
组合的好处是，用户界面中的每个组件都可以单独开发，然后在生产周期的后期将其捆绑在一起。 这意味着您已经生成了可以在多个地方轻松使用的组件，并且组件之间的通信是通过定义良好的接口进行的，而不是典型的“将组件扔到页面上并与状态对话”的方法。
所以，如果你现在所做的事情有效，我可能会继续下去。 如果您所拥有的尚未开发，请考虑使用 PRISM 之类的东西，如果您有很多开发人员致力于各个部件和部件，而另一个开发人员或团队将这些部件组合在一起，形成供用户使用的完整用户界面。 我的经验是使用复合 UI 应用程序块，它在大型项目中带来了很多好处，但所承诺的简化即使对于中等规模的项目来说也听起来不错。
If you are already compositing your pages in a way where the various sub-components of the page are independent then PRISM (or the forerunner Composite UI Application Block) isn't really buying you much other than a recognized "standard" way of doing compositing that is documented.
The benefit of compositing is that each of the components in the user interface can be developed individually and then tied together late in the production cycle. This means that you have generated components that can be used in multiple places easily and your communication between components is happening via a well defined interface rather than the typical "throw the components on the page and talk to the state" approach.
So, if what you are doing now works, I probably would continue with it. If what you have is underdeveloped, consider something like PRISM if you have a lot of developers working on the parts and pieces and another developer or group pulling these pieces together into full blown user interfaces for the user. My experience is with the Composite UI Application Block and it brought a lot to the table in large projects, but the promised simplifications sound good for even a modest sized project.
我在这里强调开发模块的划分。 它允许单独的较小团队开发应用程序的各个部分，然后最后将其组合在一起。
我还想说，MVVM 绝对是正确的选择，但 CAG 还鼓励您对 ViewModel 使用依赖注入，使它们比其他方式更易于测试。 当然，您可以在没有 CAG 的情况下使用依赖项注入，但有这种正式的鼓励真是太好了。
I'd emphasize the compartmentalization of developing modules here. It allows separate smaller teams to develop portions of an application and then put it together at the end.
I'd also like to say that MVVM is definitely the way to go here, but the CAG also encourages you to use dependency injection for your ViewModels, making them more testable than they would be otherwise. Of course you can use dependency injection without the CAG, but it's nice to have this formal encouragement.
如果您了解复合应用程序块，它基本上是相同的。 PRISM 的主要目的是拥有一个 WPF 复合应用程序，其中应用程序的每个部分（即屏幕部分或不可见组件）与应用程序的其他部分松散耦合。
If you know Composite Application Block, it's basically sort of the same. The main purpose for PRISM is to have a WPF Composite Application, in which each portion (i.e. screen portion or non visible component) of the application is loosely coupled with other part of the application.