。当控制器连接到model的时候@Refreshable annotation可以被用来让这个控制器随时了解其model的状态。当一个view连接到这个框架时，它必须在当前model的状态下被更新。因此，dispatcher扫描model寻找@Refreshable annotations并且生成与view它本身从model普通接受到的相同的事件。这些事件接着被之前讨论过的绑定机制分派。 分布式MVC网络 　　Dispatcher有一个很重的负担那就是它负责处理事件的传送周期中所有重型信息的传递： ·        Model激发一个事件用来确定它已经经历过的一些改变, dispatcher处理通知model. ·        Dispatcher扫描所有注册在它那里的views, 寻找@ModelDependent annotations, 这些annotations明确了views希望通知的改变及当每个model事件发生时,需要在views上调用的method. ·        如果需要,转化将会被用于事件数据上. ·        view method在被调用时会从被激发的事件里抽取参数,接着view会更新自己. 　　从另一个方面来讲,当一个新view在dispatcher上注册时: ·        View告诉dispatcher有关modelKey的信息,modelkey能确定它将被连接到哪一个model上(该model的事件将负责组装view) ·        如果需要，dispatcher扫描model寻找@Refreshable annotations并使用他们来生产将要及时更新view假的model事件 ·        这些事件将通过使用上述的顺序被分派, 接着view被更新. 　　所有这些既不涉及view也不涉及model的工作,他们站在他们各自的信息通信渠道的两端.无所谓这些信息是在一个本地JVM内部传输还是在多个远程主机上的JVM之间传输.如果想将本地应用程序转化成Client/Server应用程序所需的只是简单地改变dispatcher里面的逻辑,而model和view都不会受影响.下图就是一个示例: 图4. 一个基于分布式网路建立的MVC,点击缩略图查看全图 　　如上图所示,单一的dispatcher被一个与model处在同一个host上的transmitter(it.battlehorse.stamps.impl.BroadcastDispatcher的一个instance)和一个(或多个) 与view处在同一个host上的receiver(it.battlehorse.stamps.impl.FunnelDispatcher)所取代. Stamps 框架默认的实现使用了一个创建于JGroups上的消息传送层, JGroups是一个可靠的多点传送通信的工具包,象网络传输机制(但是不同的实现和使用)一样工作. 通过使用它可以获得一个稳定可靠的, 多协议的, 失败警觉的通信. 　　对我们应用程序(dispatcher)初步建立的一个改变, 使我们从一个单一用户界面的独立运行的应用程序转移到一个多用户分布式的应用程序.当model进入或离开这个网络(想象一个通信失败)的时候,框架可以通知无数的监听接口, 于是远程views可以采取适当的响应.例如,显示一个警告信息给用户. 这个框架也可以提供有用的methods来帮助将本地的controllers转化成远程的. 总结和摘要 　　仍有许多元素需要被探索,就像设计controllers的方式一样,它在目前和dispatchers具有一致的普遍性.该框架假设普通的controller-model绑定,由于前者需要知道如何去驱动后者.未来的开发方向将是支持不同类型的views,例如使用一个Web浏览器, 网络警觉的applets,和Java与JavaScript的通信. 　　已经讨论的Stamps库说明如何在一个MVC架构中降低views和models之间的耦合以及这个框架可以有效的利用Java annotations将绑定信息从实际开发程序组件分离开.拥有隔离的绑定逻辑允许你在物理上将元件分离开并且能提供一个本地和一个client/server结构而不需要改变应用逻辑或者表示层. 这些目标提供对由一个象MVC一样坚固的设计模式与由annotations提供的功能强大的元数据结合在一起所提供的可能性的洞察.   上一页  [1] [2] [3] [4] [5]