WPF棱镜 - 使用棱镜区域有什么意义?

mic*_*ael 15 wpf design-patterns prism prism-4

我只是想知道地区的意义.我想我不明白他们解决的问题.

例如,我看到很多人使用区域作为导航区域,但是为什么不只是将ItemsControl绑定到ObservableCollection而不是具有区域并将不同的导航元素加载到该区域?


一个现实世界的例子,它的使用/好处超过替代品将摇滚!

m-y*_*m-y 18

将RegionManager与EventAggregator进行比较,您将看到它的优势......

EventAggregator允许不同的组件发布/订阅事件而不相互耦合.RegionManager也是如此......您可以将视图加载到某个区域,而无需其他视图知道其中发生了什么.它将你的观点彼此分离......这并不是说每个观点都应该彼此不知道......有时候观点应该知道另一个观点.


看看Microsoft Outlook(注意:我在这里制作东西,包括名称,因为Outlook 不是用WPF编写的,而是用C++编写的):

主UI将具有以下区域:

  • MenuRegion
  • NavigationRegion
  • ContentRegion
  • SideRegion

区域在标准控件上定义(因此您仍需要标准控件),更具体地说,ItemsControl,ContentControl和Selector开箱即用(您可以将其他控件扩展为"区域支持").它们允许另一部分代码通过将适当的视图解析并加载到这些区域来管理区域.基本上,要保持事物分离.

你是主UI,不需要知道你的应用程序的一切 ; 相反,它只需要知道它有一个菜单,导航,内容和侧面区域.实际放置在区域中的哪些视图无关紧要.现在,这并不意味着每个视图都应该彼此分离.我稍后会谈到的.

那么,它实际上如何解耦?这是一个场景:单击导航控件中的日历图标.那么当你这样做会发生什么?

  1. NavigationView- 按钮(图标)绑定到a ICommand,因此它调用该ExecuteLoadCalendar()函数.
  2. NavigationViewModel- 该ExecuteLoadCalendar()功能使用该功能EventAggregator来宣告用户正在尝试启动日历.
  3. ContentController- ContentController已订阅LoadCalendarAggregateEvent,所以执行.在这里,它使用和区域名称解析/激活CalendarView(COUPLED)IRegionManager.它应该通过抓住ICalendarView而不是a来做到这一点CalendarView.

在整个过程中,除了ContentControllerCalendarView/ 之外,每个部分都是分离的ICalendarView.当然,你可以说,NavigationView/ NavigationViewModel 排序知道了这件CalendarView/ CalendarViewModel由具有ICommand和功能.好吧,"有点"与"他们做"不同,因为代码隐藏和视图模型代码永远不应该引用实际CalendarView/ CalendarViewModel对象.

此外,我们可以通过使执行泛型来删除"种类".它没有ExecuteLoadCalendar()函数,而是可以有一个LoadContent(NavigationItem item)函数,其中AggregateEvent有效载荷是某种类型的标识,例如,item.Name (String)(从DB,XML等加载)到它们点击"Calendar"的状态.在ContentController使用相同的数据,以解决"日历",而不是一个ICalendarView(因为实在不应该关心什么接口/类型解析/在激活ContentRegion-它只是需要一个对象来激活).我使用MEF,因此可以使用以下代码块实现:

[Export("Calendar")]
public class CalendarView : UserControl, ICalendarView { }
Run Code Online (Sandbox Code Playgroud)

那么,观点能相互了解吗?是! 例如,我EmailUserControl有一个搜索栏/电子邮件列表以及一个预览窗格.这两个控件可以是EmailListUserControl搜索栏和ItemsControl,而a EmailContentUserControl只是所选电子邮件的预览窗格.它们必须是单独的控件吗?不,但如果他们是,那么EmailContentUserControl当我们在单独的窗口中打开电子邮件时,我们可以重复使用.因此,这是一个EmailUserControl耦合到2个不同视图(EmailListUserControl和和EmailContentUserControl)的示例.


为什么这与其他方法更好/不同:它将视图彼此分离(并防范需要了解视图的视图模型).


Rac*_*hel 17

区域允许您在程序中定义为特定目的而存在的位置.例如,您可能有一个菜单区域或页脚区域.然后,您可以将这些特定区域的Views/ViewModel分离到它们自己的程序部分.

因此,与其具有的ApplicationViewModel对包含性质MenuViewModelFooterViewModel,以及具有查看每个部分绑定到这些属性,你会为菜单和页脚独立的ViewModels,和你的ApplicationViewModel只会处理内容.这是分离应用程序中某些逻辑边界的更好方法.

我个人认为地区过度使用和滥用.我几乎从不使用它们,除非我有一些与我的应用程序代码的其余部分无关的Header或Footer.它们也主要用于View-First开发,我更喜欢ViewModel-First.