j2ee期末论文

J2EE期末论文
模型介绍
1、MVC
1．基本概念MVC 开发模式是一种分而治之的思想，它将数据的访问和数据的表现进行了分离。

通过这种模式，可以开发一个具有伸缩性、便于扩展、便于整个流程维护的平台。

MVC 主要由三个部分组成：模块( Model ) 、视图(View) 和控制器( Controller) 。

模块，即相关的数据，它是对象的内在属性，是整个模型的核心，它表示的是解决方案空间的真正的逻辑。

它采用面向对象的方法，将问题领域中的对象抽象为应用程序对象。

在这些抽象的对象中封装了对象的属性和这些对象所隐含的逻辑。

视图是模型的外在表现，一个模型可以对应一个或者多个视图。

视图具有与外界交互的功能，主管应用系统与外界的接口：一方面它为外界提供输入手段，并触发应用逻辑运行; 另一方面，它又将逻辑运行的结果以某种形式显示给外界。

控制器是模型与视图的联系纽带，控制器提取通过视图传输进来的外部信息，并将其转化成相应事件，对模型进行更新; 同时，模型的更新与修改也将通过控制器来通知视图，从而保持视图与模型的一致性。

2.MVC设计模式的优势
MVC 设计模式具有设计清晰，易于扩展，运用可分布的特点，因此在构建Web 应用中具有显著的优势。

(1)MVC 模式结构可适用于多用户的、可扩展的、可维护的、具有很高交互性的系统，如电子商务平台、CRM系统和ERP 系统等。

(2)MVC 可以很好的表达用户与系统的交互模式，以及整个系统的程序架构模式。

(3)MVC 模式可以很方便的用多个视图来显示多套数据，从而可以使系统能方便的支持其它新的客户端类型。

除了运行桌面型的浏览器外，还可以运行在PDA，WAP 浏览器上。

(4)对于开发人员来讲，由于MVC 分离了模式中的数据的控制和数据表现，从而可以分清开发者的责任，后台开发人员可以专注业务的处理，前台开发人员专注于用户交互的界面，从而加快产品开发以及推向市场的时间。

2 、J2EE 技术
SUN 公司的J2EE( Java2 企业版) 是一种利用Java 语言的标准体系结构定义的，它提供中间层集成框架用来满足高可用性、高可靠性以及可扩展性的应用的需求。

利用它，各公司可以更为方便地在中间层加速分布式部署。

开发中利用这种体系结构，开发者可以不必担心运行关键商务应用所需的“管道工程”，从而可以集中精力重视商业逻辑的设计和应用的表示。

J2EE 技术主要有：EJB，Servlets，JSP，JNDI 等。

J2EE平台的应用主要由构件构成，应用系统的开发就是设计这些构件并组装成整个企业应用。

1. JSP
JSP 技术与ASP 技术类似，是一种在服务器端进行解析，动态生成网页传递给客户端Web 技术; 它是基于Java 技术，将Java 代码嵌入HTML 页面中实现的。

本质上，JSP 是一种高层的Servlet。

它与其它网页编写脚本有很大的相似性，但是在执行时有所不同。

JSP 引擎将它和它所在的HTML 文件一起合成
Servlet 的代码，然后它的执行就与Servlet 的一样：先编译成. class 文件，最后由支持Java 虚拟机的服务器来执行，最后输出结果。

在使用JSP 中如果结合使用JavaBean 技术，那么对于处理就会更加方便灵活。

2 。

Servlet
Servlets 是Java 210 中新增的一个全新功能，Servlets是一种采用Java 技术来实现CGI 功能的一种技术。

Servlet 和CGI 一样都是运行在Web 服务器上，用来生成Web 页面。

与传统的CGI 或其它CGI 类似替代技术来说，Java Servlets 效率更高，使用更方便，功能更强大，更
小巧也更便宜。

Java Servlet 提供了如下许多优势：
(1) Servlet 可以和其它资源( 文件、数据库、Applet，Java应用程序等) 交互，以生成返回给客户端的响应内容。

如果需要，还可以保存请求- 响应过程中的信息。

(2) 采用Servlet，服务器可以完全授权对本地资源的访问( 如数据库) ，并且Servlet 自身将会控制外部用户的访问数量及访问性质。

(3) Servlet 可以是其它服务的客户端程序，例如它们可以用于分布式的应用系统中。

(4) 可以从本地硬盘，或者通过网络从远端硬盘激活Servlet。

(5) Servlet 可被链接(Chain) 。

一个Servlet 可以调用另一个或一个系列Servelt，即成为它的客户端。

(6) 采用Servlet Tag 技术，可以在HTML 页面中动态调用Servlet。

(7) Servlet API 与协议无关。

它并不对传递它的协议有任何假设。

(8)像所有的Java 程序一样，Servlet 拥有面向对象Java 语言的所有优势。

三、J2EE 平台上MVC设计思想的实现
MVC系统模型构建
J2EE 技术结合MVC 设计模式在构建企业级Web 应用的实现中，JSP 对应于视图，因为整个应用系统主要通过JSP 来与外界进行交互; Servlet 对应于控制类，作为JSP 与EJB 之间的中间枢纽; EJB 和JavaBean 对应于模块，主要进行数据业务的处理。

MVC 系统模型明确的将数据的显示和数据业务的处理分开，从而使得逻辑结构更为清晰。

如果数据的显示方式有所改变，只需更改JSP 视图页面，而并不要求相应更改数据处理模块; 反之，如果业务要求发生变化，也只需更改相应的处理数据模块。

因而系统可以很容易加入新的业务，可以灵活适应各种需求的变化。

MVC 设计模式应用于Web 应用程序，其整个流程如下：当Web 客户端的HTML 或JSP 网页向服务器提交时，服务器端的控制器Servlet 统一处理这些提交请求。

这个控制器Servlet 根据提交的业务不同，将请求传递给相应的业务Bean 操作处理，然后将业务Bean 的处理结果再传递给视图JSP。

视图JSP 在服务器上处理之后以HTML 的方式回显给客户端。

这里的业务Bean 是一系统处理业务逻辑的Java Bean，每个Java Bean 处理一种业务。

会话Bean 和实体Bean 都是具体的与数据库的操作，在整个数据模块中供各种业务的Bean 进行调用。

四、使用分层模型改进MVC 设计架构
1、MVC 模式的缺点
虽然MVC模式很好地实现了职能分工，但它本身也有一定的问题，主要包括：
(1)视图和控制器之间的紧密连接视图和控制器是分离的但又是紧密相关的组件，它妨碍了它们的单个重用。

一个视图离开其控制器使用好像是不可能的，而反之亦然，例外情况是共享忽略所有的输入的控制器的只读视图。

(2)视图和控制器与模型的紧密耦合视图和控制器组件都是直接调用模型。

它表明模型接口的改变很可能使视图和控制器的代码无效。

如果系统使用多个视图和控制器，这个问题就被放大了。

控制器接收来自浏览器的请求，然后调用业务逻辑，由业务逻辑来和底层的Model 打交道。

在这个过程中用数据传递对象(DTO)来进行参数的传递。

在Struts 中，有一个ActionForm的类，它与视图的表单对应，这样表单的数据就能从View 传到Controller，在到Business Logic 最后到Model，这样做的一个缺点就是：一点业务逻辑发生了变化，相关的类就要修改。

但是与后续相关的Action、Business Logic、Model 都要发生变化，这是我们所不想看到的。

在设计软件系统的架构，我们希望：
(1) 仅限于对解决方案的某一部分进行更改以便尽量降低对其它部分的影响，从而减少调试和纠错的工作量，使应用程序易于维护，并增强应用程序的总体灵活性；
(2) 组件应该可被多个应用程序重用；
(3) 独立的团队应该能够在处理解决方案的各个部分时尽量减少对其它团队的依赖，并且应该能够针对定义明确的接口展开开发工作；
(4) 各个组件应保持内聚性；
(5) 无关的组件应保持松散耦合。

针对这样的问题我们的解决方案，就是用耦合性低的层来改进MVC 模式。

2、分层模型对MVC 的改进
2.1 分层模型的概念
从广义上来说，MVC 也是一种分层模型，我们设计分层模型是为了改进MVC 而并非完全摒弃它。

所谓分层模型就是将系统的组件分隔到不同的层中；每一层中的组件应保持内聚性，并且应大致在同一抽象级别；每一层都应与它下面的各层保持松散耦合；每一层都按照一定的规则将上一层传来的数据进行解包，进行一定的处理后再按一定的规则将数据进行打包后传递给下一层。

分层模型交互的过程如下：
从最低级别的抽象开始——称为第1 层，这是系统的基础。

通过将第J 层放置在第J-1 层的上面逐步向上完成抽象阶梯，直到到达功能的最高级别称为第N 层。

通常使用下列技术扩充基本的分层模式：
(1)层超类型。

如果一层中的组件具有相同的一组行为，就可以将这些行为提取到一个公共类或组件中，并使层中的所有组件都继承该公共类或组件。

这不仅简化了维护并提高了可重用性，还允许通过对超类型(而不是特定组件)的运行时引用来调用公共行为，从而减少了层之间的依赖性。

(2)抽象接口。

抽象接口是为较高级别中的组件所调用的某一层中的每个组件定义的。

较高层通过抽象接口(而不是直接调用组件) 来访问较低级别组件。

这使得可以在不影响较高级别组件的情况下更改较低级别组件的实现。

(3)层外观。

对于大型系统，常见的方法是使用Facade 模式来为层或子系统提供单个统一接口，而不是为每个公开的组件分别开发一个抽象接口。

这使得层之间具有最低的耦合，因为较高级别组件仅直接引用外观。

所以认真设计外观是非常重要的，在后期改变外观是非常困难的，因为有许多组件都将依赖于它。

2.2 改进的MVC 模式
根据分层模型的思想和扩充技术，我们改进原有的MVC模式，对View 层进行泛化，对Controller 用Service 来替代，而Model 我们则对它进行再分层，分为BO、DO 和DA。

我们对View 曾进行了泛化，MVC 主要针对的是Web 应用程序，而现实中的View 泛指用户的界面，他是与用户交互的接口，所以我们这里把View 命名成UI，可以是手机的WAP 页面，普通的网页，Form程序，甚至是Athlon 的显示模型。

当然，不同类型的View 采取的编码方式是不同的，对此，虽然我们可以通过配置文件等进行一系列的改进，但无法从根本上提高我们的开发效率。

MVC的Controller我们用Service这一层来提供，由Service来导引系统的流程。

Service 位于UI 的下一层，起到了承上启下的作用。

一方面，Service 层接收UI 传入的数据，根据UI 传
入的参数或者配置文件的设置，进行处理后将处理结果或者查询结果返回给UI 层，显示给用户。

为了简化UI 和Service，Service 和Model 之间的调用关系，我们使用抽象的类来调用Service，也通过抽象的类来返回结果给对应需要的层。

这样，当我增加一个业务层的时候，每一层只需要管理好内部的层即可，不需要考虑其它层的内容改变。

我们对Model 进一步的细分，分成Business Object Layer、Data Object Layer、Data Access Layer。

这3 层分别处理业务对象，数据库对象，数据库存储。

而各个层次之间也是通过抽象类来实现。

抽象类的好处是提供一种抽象的接口，模糊了各个层次之间调用的明细。

各个层次内部再自行打包和解包，然后完成各自的业务。

这样，每一层次的耦合度就降低了，而且当一个层次的内容发生修改时，其它的层次不需要做相应的变化。

这样的改进一方面改变了原先MVC 的Controller 功能过于依赖View，降低了模块间的耦合，另一方面也使得层次更加清晰化，各个层次的责任更加明确，为更好的软件复用提供有利条件。

五、总结
利用分层模型的思想改进的MVC 设计模式一方面体现了分离思想，是开发人员利用自身的特长各司其职，另一方面也降低了原来MVC 设计模式的耦合度。

这样的改进从某一个角度来说，增加了软件的可维护性、可重用性、可伸缩性、可靠性和安全性，但其本身也会提高开发的成本，而且多层的分部在增加灵活性的同时也加大了系统开发时调试的不方便。

而且，很难设计一个很好的接口，使得多层之间的交换便捷。