企业级Rich Client的设计模式

最新推荐文章于 2024-05-30 16:11:34 发布

iteye_12551

最新推荐文章于 2024-05-30 16:11:34 发布

阅读量88

点赞数

分类专栏： Design Patterns 文章标签：设计模式企业应用 MVC Swing 软件测试

Design Patterns 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

现在的软件越来越大，越来越复杂，体现在用户交互上尤为明显，导致相关设计开发不再像使用 IBM RPG 那样简单。开发人员需要了解很多的相关知识才能够开发出一个健壮的 Rich Client, 本文就以设计模式为切入点，对此展开讨论，目的是让大家通过本文对 GUI 设计领域里的一些设计模式有个大概的了解。

看到这个题目，我估计绝大部分朋友会第一时间想到 model-view-controller （ MVC ）模式。的确这个是在 GUI 设计领域里应用最为广泛的模式了， 3 个模块相互之间交互，大家耳熟能详，我就不多费笔墨了，不了解的朋友请察看相关资料。本文主要介绍一些大家可能还不太熟悉的模式，让大家对 GUI 设计领域相关的设计模式有个大概的了解。本文只会对所有的模式进行粗略的介绍，文章末尾列出了每一个模式的原出处，如果哪位朋友对某个模式特别感兴趣可以进行深入的解读。

Autonomous View

软件开发总是从小逐渐演变到大，从简到繁。最初，一个 Frame 可能只包括一个 Panel, 上面只有几个输入栏，几个按钮。可能包含一些展示逻辑（ presentation logic ），但是这些逻辑是非常简单的，这个时候我们应该使用 Autonomous View 模式，也就是只用一个类来实现所有的功能。具体来说就是每个 window 或 frame 一个类，把实现展示逻辑的代码直接写到 view 类中。这样做的好处就是方便快捷，缺点就是不太方便测试 , 一个类实现了多种功能，任何一个功能的改变都导致类的改变。

随着软件的成长，当 view 及其相关的展示逻辑变得比较复杂时， view 和展示逻辑就需要分开了，就好像当年 business logic 从 service 层脱离出来一样。这样做的好处是 view 和逻辑分离，代码易于共享，易于管理；逻辑功能可以重复使用，易于测试。还有很多其他的好处，介绍 MVC 的相关书籍已做了详细说明，我就不在这里展开了。

在进行 view 和逻辑分离的工作中，到目前为止有三种模式可以采用，她们分别是 MVC, Model-View-Presenter (MVP), 以及我会重点介绍的 Presentation Model.

MVC

我在文章开始就提到了不会对她进行展开，不了解的朋友请参考相关书籍。

MVP

由 Martin Fowler 发现并进行研究，从根本上来说，她只是个 MVC 的变种。在 MVC 中 view 直接处理相关的 GUI event ，比方说，键盘鼠标事件， checkBox 被选中，按钮被按等等。而在 MVP 中 view 接收到事件，然后会将它们传递到 Presenter, 如何具体处理这些事件，将由 Presenter 来完成。从 class diagram 上来看，就是 Presenter 有 View 和 Model 的引用， Presenter 负责来管理其他两个模块。跟据两者不同来看， MVC 比较适合用来开发 components, 而 MVP 比较适合进行 applications 的开发 , 因为使用 MVP 导致绝大部分逻辑代码集中在 Presenter, 而 view 变得非常简单 , 适当采用良好的编码风格，可以让毫无经验的编码人员稍加培训立刻上岗，大大加速开发 view 的速度，

Presentation Model

也是由 Martin Fowler 发现并进行研究，从根本上来说就是把所有的逻辑功能完全浓缩到 model 模块里去，这样我们就只有 2 个模块： View 和 Presentation Model 。其中 View 和 MVP 中的 View 一样，具有上面提到的所有优点，而 Presentation Model 则起着承上启下的作用，她连接 domain object 并将其展现在 view 上。看到这里聪明的读者可能会发现这个模式有个缺点，就是在 view, presentation model, 和 domain object 之间一定要保持同步。在其他两个模式中，这个功能可以由 Controller 和 Presenter 来完成。而在 presentation model 模式中却没有一个合适的地方来实现，在 view 里肯定不行，在 model 里也不太合适。也就是说当我们使用 presentation model 进行开发时，我们所使用的框架必须要提供这种同步功能。在 windows 世界里 .Net data binding 就是这种功能的实际实现。如果我们使用 Swing 开发，很抱歉， Swing 没有这种功能。而作为 Swing 的扩展， JGoodies binding 比较完美的解决的这个遗憾。

选择

模式已经介绍完了，到了选择的时候了。其实看到这里大家应该已经有个比较清晰的 big picture 了。那么当我们进行 GUI 开发时，何时选用什么模式呢？我的建议是：

对于简单的 view ，直接使用 Autonomous View.
开发 component 级别的 GUI, 至少要使用 MVC.
开发 applications, 则应该采用 MVP 或者是 Presentation Model

那么如果是开发 application 到底应该使用 MVP 还是 Presentation Model 呢？这应该是绝大部分开发人员关心的问题。 Martin fowler 在他的文章中说是 it really comes down to how easy it is to do the pattern in your GUI environment and on your own personal tastes. 我觉得不完全对。还记得前面说 presentation model 有个缺点吧 , 就是那个同步的问题。问题总是有两面性的，当我们换个角度来考虑这个问题时缺点就变成了优点了！简而言之，如果再开发中使用了像 JGoodies 这样的 framework ，她提供了完善的同步服务，那么我们应该毫不犹豫的使用 presentation model, 因为同步问题已被 framework 解决，应用开发人员不需要投入时间在这些问题上。而相反，使用 MVP 的话，应用开发人员却不得不面对这些问题，直接导致开发周期延长。另外还有一个使用 presentation model 原因就是在 swing 中 presentation model 已经比较完善（请注意，是比较完善而非完美）得到了实现，比方说 ListModel, TableModel ，并且针对每一个 model 也都实现了同步。美中不足就是 swing 提供的每一个 model 都是针对具体 GUI component 的，而且没有提供一个全局同步策略。而 JGoodies binding 比较完美的解决的这个问题。

最后还要提到一个比较小的模式就是 value model ，她是 value object 的变种，她提供了一种 set ， get ，和 observe 某个对象功能，这个对象通常是个 Java Bean ，当然也可以是其他的对象类型。这个模式在 JGoodies 中应用非常广泛，我会在以后的文章中作深入讲解。