| 面向对象的设计模式是经验的总结，MVC思想是原先用于构建用户界面的。这篇文章主要论述了如何在新的Web应用领域中使用设计模式和MVC架构。文章首先介绍了设计模式的概念和特点，以及MVC架构的设计思想，并分析了MVC架构中包含的几种主要的模式。然后根据Web应用系统的特点，就如何应用模式和MVC架构提出了一些设计思路。
1. 引言
1.1 设计模式
面向对象技术的出现和应用大大提高了软件的重用性和软件的质量。面向对象的编程也比以往的各种编程模式要简单和高效，但是面向对象的设计方法要比以往的设计方法要复杂和有技巧得多，一个良好的设计应该既具有对问题的针对性，也充分考虑到对将来问题和需求有足够的通用性。在过去的十几年中，人们在对面向对象技术的研究探索和实际应用中针对某些问题创造了一些良好的解决方案,即所谓的面向对象的设计模式。面向对象技术的目的之一就是提高软件的重用性，而对设计模式、设计方案的重用则从更深的层次上体现了重用的意义和本质。
人们对设计模式有很多定义，其中被引用的最多是Christopher Alexander的设计模式的定义：每一个设计模式是一个三方的规则，它表达了一个上下文环境（Context）,一个问题和一个解决方案。设计模式一般有如下几个基本要素：模式名称，问题，目的，解决方案，效果，样例代码和相关设计模式。
设计模式的分类有好几种，可以根据其目的分为创建型(Creational)，结构型(Structural)和行为型(Behavioral)三种。创建型模式主要是用来创建对象，结构型模式主要是处理类或对象的组合，行为型模式则主要用来描述对类或对象怎样交互和怎样分配职责。也可以根据范围将设计模式分为类模式和对象模式，类模式处理类和子类之间的关系，这些关系通过继承建立，在编译时刻就被确定下来，是属于静态的。对象模式是处理对象间的关系，这些关系在运行时刻变化，更具动态性。
模式的特点：是通过经验获取的，以某种结构化的格式书写下来，避免了遇到相同的问题重头设计，存在于不同的抽象层，在不断完善的，是可重用的人工产物，使设计和最好的练习交互，以被组合起来解决更大的问题。
1.2 MVC架构
MVC最初是在Smalltalk-80中被用来构建用户界面的。M代表模型Model,
V代表视图 View， C代表 控制器Controller。
MVC的目的是增加代码的重用率，减少数据表达，数据描述和应用操作的耦合度。
同时也使得软件可维护性，可修复性，可扩展性，灵活性以及封装性大大提高。
单用户的应用通常是以事件驱动的用户界面为组织结构的。开发人员用一个界面工具画了一个用户接口界面，然后编写代码根据用户输入去执行相应的动作，许多交互式的开发环境鼓励这么做，因为它强调先有界面然后再有功能。一些软件设计模式策略是这样的，然后经常将固定后的代码融入最后的系统当中。导致的结果就是，程序组织围绕用户界面元素和用户在那些界面元素上的动作，数据的存储，应用的功能以及用来显示的代码都杂乱无章的缠绕在一起。在单用户的系统里代码结构是可以这样的，因为系统需求不会频繁变化。但是对一个大的系统如大型Web系统，或电子商务系统来说就不太适用了。
通过把数据模式从各种可以被存取和控制的数据中分离出来可以改善分布式系统的设计。MVC设计模式由三部分组成。模型是应用对象，没有用户界面。视图表示它在屏幕上的显示，代表流向用户的数据。控制器定义用户界面对用户输入的响应方式，负责把用户的动作转成针对Model的操作。Model
通过更新View的数据来反映数据的变化。
三者关系如图：
对MVC关系图的理解
图2 MVC的分工与协作
2. MVC中的设计模式
一个以MVC为架构的系统包含了很多的设计模式，但是与MVC最为密切相关的是下面三种模式：Observer,
Composite和Strategy。
2.1 Observer模式
MVC通过使用定购/通知的方式分离了Model和View。View要保证自己显示能正确地反映出Model的内容和状态。一旦Model的内容发生变化，必须有一个机制来使得Model能够通知相关的View，使得相关的View可以在适当的时机刷新数据。这个设计还可以解决更一般的问题，将对象分离，使得一个对象的改变能够影响到另一些对象，而这个对象并不知道那些被影响的对象的细节。这就是被描述为Observer的设计模式。
模式类型：Observer模式是对象型模式，同时它也是行为型模式。
模式目的：定义对象间的一对多的依赖关系，当一个对象的值或状态发生改变时，所有与它有依赖关系的对象都得到通知并自动更新。某一数据可能有多种显示方式，并且可能同时以不同的方式显示（如图2）。当通过某一种方式改变了数据，那么其他的显示都应该能立即知道数据的改变和做相应的调整。
模式结构：
图 3. Observer模式的结构图
效果：
1. 抽象耦合。目标对象只知道它有一些观察者，每个观察者都符合抽象的Observer类的简单接口，并不知道它们具体属于哪个类。这样使得目标和观察者之间的耦合最小且抽象。
2. 支持广播通信。目标发送通知不用指定观察者，如何处理通知由观察者决定。
3. 可能的意外更新。要处理好更新逻辑，避免错误更新。
2.2 Composite模式
MVC的一个重要特征就是View可以嵌套。嵌套的组合视图可用于任何视图可用的地方，而且可以管理嵌套视图。这种思想反映出将组合的视图与其组件平等对待的设计。这种设计思想在面向对象领域内被描述成为Composite的设计模式。
模式类型：Composite模式是对象型模式，同时它也是结构型模式。
模式目的：将对象组合成树形结构以表示"部分-整体"层次结构。Composite使组合对象的使用和单个对象的使用具有一致性。
模式结构：
图4. Composite模式的结构图
效果：
1. 定义了包含简单对象和组合对象的类层次结构。简单对象可以被组合到复杂对象中，而组合的对象可以再被组合。这样客户端代码中用到简单对象的地方都可以使用组合对象。
2. 简化客户端代码。客户端不用知道某对象是简单对象还是组合对象，可以以一致的方式使用这些对象。
3. 更容易增加新类型的组件。新的组件可以方便地加入已有组合对象中不用改变客户端代码。
2.3 Strategy模式
MVC的另一重要特征是可以在不改变View的情况下改变View对用户输入的响应方式。这对一个经常需要变更响应逻辑的系统来说是非常重要的。MVC把响应逻辑封装在Controller中。有一个Controller的类层次结构，可以方便地对原有Controller做适当改变，创建新的Controller。View使用Controller子类的实例来实现一个特定的响应策略。要实现不同的响应策略，只要用不同种类的Controller实例替换即可。还可以在运行时刻通过改变View的Controller来改变View对用户输入的响应策略。这种View-Controller的关系是被描述为Strategy的设计模式的一个例子。
模式类型：Strategy模式是对象型模式，同时它也是行为型模式。
模式目的：定义一系列的算法，并且把它们封装起来，使它们可以互相替换，使得算法可以独立于使用它的客户端而变化。
模式结构：
图5. Strategy模式的结构图
效果：
1. Strategy类层次为Context定义了可重用的相关算法或行为。
2. 替代继承的方法。如果直接继承Context，给以不同的行为，会将行为加到Context中，从而将算法的实现与Context混合起来，使Context难以理解，维护和扩展，而且不能动态地改变算法。将算法封装在独立的Strategy类，可以使得算法独立于Context改变，容易切换扩展。
3. 可以提供相同行为的不同实现。
4. 客户端必须了解Strategy之间有何不同。
5. Context和Strategy之间的通信开销。
6. 增加了对象的数目。
3. MVC在 Web系统中的应用
现在的一些基于Web的分布式系统如B2B电子商务系统，就适合采用MVC架构。
通过分析，从高层次的角度可以将一个应用的对象分为三类。一类就是负责显示的对象，一类对象包含商业规则和数据，还有一类就是接收请求，控制商业对象去完成请求。这些应用的显示是经常需要变换的，如网页的风格，色调，还有需要显示的内容，内容的显示方式等。而商业规则和数据是相对要稳定的。因此，表示显示的对象View经常需要变化的，表示商业规则和数据的对象Model要相对稳定，而表示控制的Controller则最稳定。
通常当系统发布后，View对象是由美工，HTML/JSP设计人员或者系统管理员来负责管理的。Controller对象由应用开发人员开发实施，商业规则对象和商业数据对象则由开发人员，领域专家和数据库管理员共同完成的。显示逻辑在Web层或客户端控制，可以是Servlet
或JSP，动态地生成Html。一般来说采用JSP要比采用Servlet要好。JSP更好地将代码与Html部分分开，有利于页面设计人员和代码开发人员的分离，提高效率。同时JSP可以完成所有Servlet完成的功能，实际上JSP最终也转换成一个Servlet。与控制有关的对象存在于系统的每一个层次，协调跨层动作。包含商业规则和数据的对象存在于EJB层（以EJB为中心的模式）或Web层（以Web为中心的模式）。
3.1 View在Web系统中的应用
View代表系统的显示，它完全存在于Web层。一般由JSP, Java
Bean和Custom Tag组成。JSP可以动态生成网页内容，Custom Tag 更方便了使用Java
Bean，而且它可以封装显示逻辑，更有利于于模块化和重用。一些设计良好的Custom Tag可以在多个JSP甚至可以在不同的系统里重复使用。Java
Bean用来控制JSP和Model对象。JSP通过Java Bean 来读取Model对象中的数据，Model和Controller对象则负责对Java
Bean的数据更新。一般来说，可以先要设计出所有可能出现的屏幕，即用户使用系统时可以看到的所有内容。然后根据这些内容，找出公共部分，静态部分和动态变化部分。可以考虑使用模板方法，把公用的内容单独生成JSP，需要变化的也各自生成Html或JSP,
由一个模板JSP, 把这些不同部分动态地引入（include方法）。还有一个要考虑的问题就是屏幕的选择问题，当处理完用户请求，模板被自动调用来显示，这个显示一定要知道用户关心的屏幕是有哪些部分组成。所以可以考虑把所有屏幕的定义放在一个集中的文件里，如一个java文件或文本文件。由于考虑到屏幕定义文件将来的变更可能性，最好使用文本文件如一个XML文件，这样将来更改不用重新编译。可以根据用户输入的URL和参数可以映射到某一个结果屏幕，当然有可能还要根据动作的执行结果选择不同的结果屏幕内容。所以需要一个请求与资源的匹配文件（XML），如果一个URL请求有几种不同结果，则要在该文件中指明是否需要流控制（一种controller对象）以及不同流向的对应屏幕。
3.2 Model在Web系统中的应用
Model对象代表了商业规则和商业数据，存在于EJB层和Web层。在J2EE的规范中，系统有些数据需要存储于数据库中，如用户的账号信息（account
model），公司的数据(company model)等，也有一些不需要记录在数据库里的，如某用户浏览的当前产品目录(catalog
model)，他的购物内容(shopping cart model)等。这些model数据存在于哪一层要根据它们的生命周期和范围来决定。在Web层有HttpSession和ServletContext及Java
Bean对象来存储数据，在EJB层则有EJB来存储数据和逻辑。Web层的Java Bean的model对象存储了EJB层model对象的数据的拷贝。因为EJB层有很多不同的model对象，所以Web层可以通过一个ModelManager来控制EJB层的各model对象，在ModelManger中可以封装使用后台model对象的方法。
在EJB层把所有的数据和规则都模式化为EJB也是不恰当的。如可以把存取数据库的对象模式化为DAO对象。DAO中可以封装与具体数据库的交互细节，如可以读写不同的表，多个数据库，甚至多种数据库。如定单的model对象可以是一个OrderDAO,
它可能要同时处理Order表，OrderStatus表和OrderItemLines表。
还有可以考虑使用Value对象。一个Value 对象可以封装远程对象，因为每一个读远程对象的属性都可能是一个远程过程调用，都会耗费网络资源。可以在EJB的远程对象中使用Value对象.
在远程对象中一次性得到Value对象来得到所有属性的值。
3.3 Controller在Web系统中的应用
Controller对象协调Model与View，把用户请求翻译成系统识别的事件。在Web层，一般有一个MainServlet(或Main.jsp)，接收所有请求，它可以调用屏幕流管理器（ScreenFlowManger）决定下一个屏幕。一般还有一个请求处理器RequestProcessor，包含所有请求都需要做的处理逻辑，如把请求翻译成系统事件（RequestToEvent）。请求处理器通常还包含一个代理对象ClientControlWebImpl，它是EJB层的逻辑处理的在Web层的代理。在EJB层，有一个ClientController提供Web
层对EJB层的只读访问。还有一个StateMachine用来建立和删除ejb，处理Web层送来的事件。
Controller还有一个重要的功能就是同步View和Model的数据。在ModelManger中包含一个ModelUpdateManger，它把系统事件转换为一个Model的集合，即所有需要同步的Model，然后通知Listeners去做同步操作。 |
