基于MVC模式的J2ME应用程序框架设计

1 J2ME应用程序框架的现状

Sun公司在1999年6月推出了J2ME(Java 2 MicroEdition，Java 2袖珍版)。J2ME是专门为那些使用有限电源、有限网络连接以及有限图形用户界面能力的设备开发的，满足了消费电子和嵌入式设备开发的需要。

而7年后的今天，消费电子和嵌入式设备发展迅速。硬件设备速度越来越快，存储容量也越来越大，这也就自然带动了软件的发展。MIDP 2.0和CLDC 1.1也相继问世，各种各样的JSR也层出不穷。

硬件平台和软件平台的飞速发展自然带动了人们需求的增长，也就使得现在的应用程序越来越复杂。以手机游戏为例：以前的手机游戏，一般代码必须限制在64 KB以内；而现在，大部分手机的这种限制已经取消。上百KB的游戏已很常见，甚至有的J2ME游戏已经超过2 MB。

通常来说，J2ME程序都是比较小的，多数在100 KB以下。而且其中大部分是图片和声音，代码只占其中很少一部分。在J2ME程序比较小时，为了提高程序的执行效率，通常的做法是只用一个类完成整个应用程序，在回调函数commandAction()中完成所有界面切换的工作。例如：

这种模式的好处在于代码量最小，能得到最小的jar包尺寸，执行起来效率也最高；而且，因为所有界面都在同一个类中，它们可以很方便地共享数据。

但如果界面很多，程序很大，这种模式就体现出它的劣势了。一方面，几千行的代码集中在一个类里，调试和维护非常不方便。另一方面，由于很多界面都在同一个类中共享数据，使得它们的耦合度大大提高。如果要替换或修改其中某个界面，很可能会影响到其他界面。这就给开发程序带来了很大的不便。

随着嵌入式硬件的发展，J2ME软件的复杂度也越来越大，上述设计模式已不能适应嵌入式发展的需求。这就需要一个更好的设计模式来取代以前的简单设计模式。下面就介绍一下如何把MVC设计模式应用到J2ME程序设计中。

2 MVC模式的简介

MVC由Trygve Reenskaug提出，首先被应用在SmallTalk-80环境中，是许多交互和界面系统的构成基础，Microsoft的MFC基础类也遵循了MVC的思想。目前这种模式已经非常成熟，并在WEB Application的开发中广泛使用，apache的开源项目struts就是典型的例子。

MVC的英文全称是Model-View-Controller，即把一个应用的输入、处理、输出流程按照Model、View、Con-troller的方式进行分离。这样一个应用被分成3个层——模型层、视图层和控制层。

模型、视图与控制器的分离，使得一个模型可以具有多个显示视图。如果用户通过某个视图的控制器改变了模型的数据，那么所有其他依赖于这些数据的视图都应反映出这些变化。因此，无论何时发生了何种数据变化，控制器都会将变化通知所有的视图，实现显示的更新。这实际上是一种模型的变化一传播机制。模型、视图、控制器三者之间的关系和各自的主要功能如图1所示。

3 基于MVC模式的J2ME应用程序框架

MVC是一种很好的客户端软件设计模式，但目前一般只用于PC上。以JAVA为例，目前已经可以看到MVC大量地应用在J2EE和J2SE上，可是几乎还很少见到在J2ME上使用MVC模式。这是为什么呢?有以下两点原因：

① 大部分的J2ME应用都很简单，开发周期也很短，很多开发人员偏爱把所有代码写在一个类中，认为没有必要使用复杂的设计模式；

② 使用MVC模式在某种程度上会增大代码的体积，并且有可能在一定程度上影响程序的执行效率，这在资源相对有限的J2ME系统上是一个不可忽视的问题。

可是随着嵌入式硬件的发展，移动设备的性能有了很大的提高，从而带动了应用软件的发展。J2ME应用软件变得越来越复杂，如果还像以前那样使用一个类来完成所有的代码，必将使得程序可读性差、扩展性差、可维护性差。然而，如果把MVC模式应用在J2ME应用程序设计中，就可以解决以上的问题。下面列举并分析几种在J2ME中比较适合的MVC模式。

3.1 单一控制器的MVC模式

MVC模式是大家都比较熟悉的，整个程序中使用同一个Controller来控制界面的切换和事件的处理等，如图2所示。

在J2ME应用程序中，界面的切换是比较常见的操作，利用这种单一控制器的MVC模式，可以很容易地实现界面的切换，如图3所示。

由于界面切换流程都在这个Controller中进行管理，所以程序流程制定得非常清晰。但是由于只有一个控制器，所以如果界面很多、很复杂，就会使得这个控制器十分庞大，影响到开发效率。

3.2 多个控制器的MVC模式

当应用程序界面很多时，可以改变这种情况使用多个控制器的MVC模式，如图4所示。

在这种模式下，按照程序模块把界面分成若干个部分，每个部分使用一个控制器来控制。这样做的好处是程序模块划分得很清楚，程序结构更加清晰，也不至于使得一个控制器过于庞大；缺点是程序的类数量更多，控制器之前增加了通信开销。

3.3 简化的MV模式

上面的两种程序设计模式已经很常见于PC上的应用软件设计，包括WEB应用或J2EE中的设计。但是通常来说，由于基于移动设备的J2ME应用软件复杂程度相对PC上的要低许多，有时候本来就只有几个类，如果完全照搬PC上的MVC模式，反而会使程序框架变得更加复杂。这时，可以采用以下的一种变形：MV模式(或称为MC-V或M-VC模式)，如图5所示。

在这种模式中，由于去掉了控制器，于是把控制器的功能合并到View或Model中。如果把Controller合并到View中，则可称其为M-VC模式；如果把Controller合并到Model中，则可称其为MC-V模式。

3.4 更加简化的V模式

如果认为上面这种简化的MV模式还是过于复杂，那么可以考虑下面的V模式，如图6所示。

在这种模式中，已经完全省略了Model和Controller，只剩下View了。界面的切换和数据的处理都在各个界面的View中独立完成。这样使得类的数量极大地减少，程序执行效率有一定的提高，可是从另一个方面来说，程序的耦合度也增大了。所以，一般来说并不推荐使用这种模式，只有在程序十分简单、数据量很小时才使用。

4 MVC模式应用在J2ME上的优缺点

MVC模式作为一种已成熟应用在PC客户端的设计模式，其优点是不言而喻的。这些优点同样也在J2ME上得到了很好的体现：

① MVC最大的优点就在于它把一个应用分成了3层，这样程序设计的灵活性就大大增加了。例如，一个应用的业务流程或者业务规则的改变只须改动MVC的模型层，而界面表现方式的改变则只须改动MVC的视图层。

② 将MVC分离可以让不同的专家负责不同的模块。一般情况下，M部分由熟悉数据库、网络传输的专家负责；V部分则交给对UI有研究的专家。分工意味着可以提高效率并可以按照传统的责任划分来处理软件开发过程，使开发者可以专心于一个领域，从而极大地提高了软件开发的效率。

③ 模型的部分，因为足够抽象，可以方便地重复利用，符合OO的思想。另一方面可以利用J2meUnit等单元测试工具对模型进行单元测试，以保证工程质量。

然而MVC模式也存在着一些缺点，而这些缺点在J2ME应用上体现得更加明显：

① MVC模式应用于J2ME上的最大缺点莫过于增大了代码体积。据不完全统计，使用了MVC模式后，代码体积约是不使用MVC的1.5倍。这对PC上的客户端软件来说可能不算什么，可是对于存储容量十分有限的移动设备则是致命的。

② 模型、视图与控制器分离，它们之间传递数据时会耗费一定的系统时间，这或多或少会降低程序的运行效率。而程序体积的膨胀也使得J2ME在装载类时会耗费更多的时间，也从一定程度上损害了程序的性能。

③ MVC的3个部件定义并不具体，对于3个部件的具体功能还存在着一些争议。这给初学者留下不少的陷阱，加大了使用MVC模式的难度。

结 语

综上所述，当J2ME应用程序比较庞大时，将MVC设计模式应用于程序的框架设计是一个不错的选择；而当应用程序比较简单时，MVC模式的缺点就暴露出来了，这时可以考虑使用MVC的简化模式——MV模式，甚至是V模式。目前，笔者已将MVC模式应用于J2ME手机播客软件中，取得了良好的效果。