快捷搜索:

CAL学习之一:UI的组织

用户界面的组成:

为了构建你的用户界面,你必要一个架构,可以创建一个layout,这个layout是由一些松耦合的可视化单元组成的。并且你要供给一种松耦合的通讯给这些可视化单元。你必要定义下列策略:

View Composition(view的组织)

敕令

事故

下边我们来一一详细看。

View的组织:

在一个组合利用法度榜样中,来自不合module 的View必要在运行时被显示在用户界面的恰当位置。为了达到这个目的,开拓职员必要定义一些位置来供view显示,并且必要定义一个view是怎么被创建以及以何种要领显示的。

View在什么地方显示是经由过程定义一个含有命名位置的结构。在运行时,view将显示在这些命名位置中。View可以经由过程法度榜样或者自动的填入响应的位置。经由过程法度榜样的我们叫做 view 注入,后者我们称为view感知。这两种技巧抉择了如何在用户界面中显示view.

View平日用分层的模式来体现,比如 MVP模式。这可以将营业逻辑和体现层隔离。View和一个被隔脱离来的 presenter来交互。Presenter里封装了营业逻辑。 在View的组织上,开拓职员可以选择

View优先,也可以选择 Presenter优先。

Layout (结构)

一个layout 在用户界面上定义了一些命名位置。View将在运行时显示在这些位置上。Layout可以在不影响 module 的环境下将view加入到layout。这样就界面设计职员的变动就不会影响内务营业逻辑。

Shell定义了一个法度榜样最高层次的layout。像下边的例子,Shell将用户界面分成两部分,导航部分和主体显示区:

在shell下我们可以类似的定义更多的layout,所有的UI就这样组织起来。

我们经由过程在一个control中注册一个位置的名字来定义一个命名位置。这个control将在运行时保存对应的view。这些control扮演者占位符的感化。并且在control内部定义了若何显示view的策略。比如:一个 tab control 会集理的组织和显示很多view在不合的tab里。在module里我们定义了一个view,然则并不知道若何在一个命名位置显示。

View 感知(view Discovery)

View感知是这样实现的:module可以将一个view注册到一个命名位置,这样在法度榜样运行时,对付一个命名位置来说,任何注册的view都邑自动创建并且显示出来。

Module经由过程一个registry来注册一个view。父View会哀求这个registry,并查找此中的注册信息,一但发明,就会经由过程把view加到上边提到的起占位符感化的control中,来添补用户的屏幕显示。

当一个法度榜样启动后,layout上的各个占位符control将被看护,用已经注册的view来显示界面。如图:

CAL定义了一个标准的 registry,RegionViewRegistry,用来将view注册到命名位置。

View注入(view injection)

View注入模式,是由view所在的module经由过程法度榜样显式的节制一个view在一个命名位置的显示和移除。 它是这样实现的 :利用法度榜样保留了所有的命名位置的注册,每个module可以在注册信息中找到一个命名位置,并且将view注入进去。

为了以一种通用的措施实现view注入,所有的命名位置都承袭了一个通用的Interface,用来实现view的注入。

如图:

CAL定义了一个标准的注册:RegionManager 和一个标准的interface:IRegion。

View优先和Presenter优先 的组合

平日View的实现都是把营业逻辑和体现层分离。View认真体现,Presenter认真营业逻辑,当view组应时,View和Presenter连接到一路。

View优先的组合,逻辑上,View先被创建,view依附的Presenter紧随着被创建。而Presenter优先的组合,与之相反。不管若何,当view和Presenter被创建和初始化后,view就被显示在指定的位置上了。

View感知的措施自然的应用了View优先的模式,由于view先被创建并注册进去。View注入的要领供给了编程的要领,对付View优先照样presenter优先都是一样的。

敕令(commanding)

在一个composite法度榜样中,我们分离了体现层和营业逻辑层。这带来了好处也使得我们必须将View上用户的操作通报到view之外的handler来处置惩罚。别的,一个用户控件的可用与否还常常和法度榜样内部的逻辑相关。

WPF引入了Command的观点来办理这个交互的问题。一个用户控件可以绑定一个command。这个command处置惩罚用户活动与 handler的履行逻辑。当一个控件吸收用户的动作,它就可以履行绑定的command。而不管command的内部逻辑。而且,控件可以经由过程判断这个command是否可用来抉择自己是否可用。

WPF 默认的 RoutedUICommand 机制,要求事故处置惩罚的handler必须定义在吸收用户操作的控件或者包孕它控件中。对付一个composite 的法度榜样,command的处置惩罚不能遵照这种树形布局,实际上,一个command实际上将处置惩罚代理给他的子command的模式是繁杂的。

为了冲破这个限定,你可以在WPF中创建自定义的ICommand,这样你就可以直接将command转到处置惩罚逻辑哪里,而不要理会控件的树形布局。两种常见的要领是:代理和组合。

敕令代理:

敕令代理用一个Command来代理一个处置惩罚逻辑。不管是用event照样delegate实现,处置惩罚逻辑可以在Presenter,Service或者Controller里。没有让处置惩罚逻辑呈现在view的代码中,这让处置惩罚逻辑加倍轻易测试。一个Command必要两个处置惩罚措施,一个是Execute,一个是CanExecute。这两个措施都是经由过程调用Command来调用的。不管是经由过程event照样delegate。

敕令组合:

敕令组合是一个可变的敕令代理。这种模式,一个组合敕令实际上代理了一系列松耦合的子敕令。这个模式在有一个共享的敕令,然则各个子窗口实现措施不合的环境下有用,比如SaveAll。组合敕令模式必要供给一种让子敕令注册进来的机制,履行敕令组合便是自行各个子敕令。只有当所有的子敕令的CanExecute返回为true时,组合敕令模式的CanExecute措施才返回true。

CAL供给了DelegateCommand和CompositeCommand两个类来是实现上边提到的两种不合的模式。

事故办事(EventService)

经由过程事故办事,一个法度榜样特定的办事将孕育发生一个标准的.net事故。为了能添加新的事故,service和service的接口必要改变。这个Service被注册,并且所有的module都可以得到。订阅和查询方都引用这个service的接口,然则彼此不依附。这样订阅者必要手动来处置惩罚线程同步的问题,并且要能够把自己从订阅者列表中取消,这样它才能被垃圾收受接收。

事故聚拢(EventAggregation)

事故聚拢用一种通用的聚拢办事来存储所有的event 工具。Event object 自己用代理而不是.net的event。这样做的一个好处是这些代理可以在宣布时被创建并且顿时被开释。这样就可以被垃圾收受接收。每个event工具包孕了一个订阅者列表。新的event可以被添加到系统而不要改动这个service的代码。并且event工具可以自动的调用到精确的线程。

EventAggregator 办事和CompositePresentationEvent 类 已经在CAL里被实现了。

您可能还会对下面的文章感兴趣: