随笔 - 3, 文章 - 152, 评论 - 17, 引用 - 0
数据加载中……

究竟什么是MVC

1 解释一 http://dev.csdn.net/article/52/52575.shtm

 
模型-视图-控制器(MVC)是Xerox PARC在八十年代为编程语言Smalltalk-80发明的一种软件设计模式,至今已被广泛使用。最近几年被推荐为Sun公司J2EE平台的设计模式,并且受到越来越多的使用 ColdFusion 和 PHP 的开发者的欢迎。模型-视图-控制器模式是一个有用的工具箱,它有很多好处,但也有一些缺点。

MVC如何工作

MVC是一个设计模式,它强制性的使应用程序的输入、处理和输出分开。使用MVC应用程序被分成三个核心部件:模型、视图、控制器。它们各自处理自己的任务。

视图
视图是用户看到并与之交互的界面。对老式的Web应用程序来说,视图就是由HTML元素组成的界面,在新式的Web应用程序中,HTML依旧在视图中扮演着重要的角色,但一些新的技术已层出不穷,它们包括Macromedia Flash和象XHTML,XML/XSL,WML等一些标识语言和Web services.

如何处理应用程序的界面变得越来越有挑战性。MVC一个大的好处是它能为你的应用程序处理很多不同的视图。在视图中其实没有真正的处理发生,不管这些数据是联机存储的还是一个雇员列表,作为视图来讲,它只是作为一种输出数据并允许用户操纵的方式。

模型
模型表示企业数据和业务规则。在MVC的三个部件中,模型拥有最多的处理任务。例如它可能用象EJBs和ColdFusion Components这样的构件对象来处理数据库。被模型返回的数据是中立的,就是说模型与数据格式无关,这样一个模型能为多个视图提供数据。由于应用于模型的代码只需写一次就可以被多个视图重用,所以减少了代码的重复性。

控制器
控制器接受用户的输入并调用模型和视图去完成用户的需求。所以当单击Web页面中的超链接和发送HTML表单时,控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求,然后用确定用哪个视图来显示模型处理返回的数据。

现在我们总结MVC的处理过程,首先控制器接收用户的请求,并决定应该调用哪个模型来进行处理,然后模型用业务逻辑来处理用户的请求并返回数据,最后控制器用相应的视图格式化模型返回的数据,并通过表示层呈现给用户。

为什么要使用 MVC

大部分Web应用程序都是用像ASP,PHP,或者CFML这样的过程化语言来创建的。它们将像数据库查询语句这样的数据层代码和像HTML这样的表示层代码混在一起。经验比较丰富的开发者会将数据从表示层分离开来,但这通常不是很容易做到的,它需要精心的计划和不断的尝试。MVC从根本上强制性的将它们分开。尽管构造MVC应用程序需要一些额外的工作,但是它给我们带来的好处是无庸质疑的。

首先,最重要的一点是多个视图能共享一个模型,正如我所提及的,现在需要用越来越多的方式来访问你的应用程序。对此,其中一个解决之道是使用MVC,无论你的用户想要Flash界面或是 WAP 界面;用一个模型就能处理它们。由于你已经将数据和业务规则从表示层分开,所以你可以最大化的重用你的代码了。

由于模型返回的数据没有进行格式化,所以同样的构件能被不同界面使用。例如,很多数据可能用HTML来表示,但是它们也有可能要用Macromedia Flash和WAP来表示。模型也有状态管理和数据持久性处理的功能,例如,基于会话的购物车和电子商务过程也能被Flash网站或者无线联网的应用程序所重用。

因为模型是自包含的,并且与控制器和视图相分离,所以很容易改变你的应用程序的数据层和业务规则。如果你想把你的数据库从MySQL移植到Oracle,或者改变你的基于RDBMS数据源到LDAP,只需改变你的模型即可。一旦你正确的实现了模型,不管你的数据来自数据库或是LDAP服务器,视图将会正确的显示它们。由于运用MVC的应用程序的三个部件是相互对立,改变其中一个不会影响其它两个,所以依据这种设计思想你能构造良好的松偶合的构件。

对我来说,控制器的也提供了一个好处,就是可以使用控制器来联接不同的模型和视图去完成用户的需求,这样控制器可以为构造应用程序提供强有力的手段。给定一些可重用的模型和视图,控制器可以根据用户的需求选择模型进行处理,然后选择视图将处理结果显示给用户。

MVC的缺点
MVC的缺点是由于它没有明确的定义,所以完全理解MVC并不是很容易。使用MVC需要精心的计划,由于它的内部原理比较复杂,所以需要花费一些时间去思考。

你将不得不花费相当可观的时间去考虑如何将MVC运用到你的应用程序,同时由于模型和视图要严格的分离,这样也给调试应用程序到来了一定的困难。每个构件在使用之前都需要经过彻底的测试。一旦你的构件经过了测试,你就可以毫无顾忌的重用它们了。

根据我个人经验,由于我们将一个应用程序分成了三个部件,所以使用MVC同时也意味着你将要管理比以前更多的文件,这一点是显而易见的。这样好像我们的工作量增加了,但是请记住这比起它所能带给我们的好处是不值一提。

MVC并不适合小型甚至中等规模的应用程序,花费大量时间将MVC应用到规模并不是很大的应用程序通常会得不偿失。

MVC是一条创建软件的好途径
MVC设计模式是一个很好创建软件的途径,它所提倡的一些原则,像内容和显示互相分离可能比较好理解。但是如果你要隔离模型、视图和控制器的构件,你可能需要重新思考你的应用程序,尤其是应用程序的构架方面。如果你肯接受MVC,并且有能力应付它所带来的额外的工作和复杂性,MVC将会使你的软件在健壮性,代码重用和结构方面上一个新的台阶。


2解释二  http://www.ask321.com/ask8/ask151598.htm
Model-View-Controller

a.       问题

如果开发一个企业级应用,只需要一种客户端的话,那么一切都非常容易解决。但真实情况是,我们必须面对运行在各种设备上客户端,象PDA,WAP浏览器以及运行在桌面上的浏览器,我们不得不开发不同的应用程序来处理来自不同客户端的请求。数据访问与现实将混淆在一起,可能会出现重复的数据访问,导致整个开发周期没有必要的延长。



b.      建议的解决方法

Model-View-Controller (MVC) 开发模式被证明是有效的处理方法之一。它可以分离数据访问和数据表现。你可以开发一个有伸缩性的,便于扩展的控制器,来维护整个流程。如图1所示为整个模式的结构。MVC模式可以被映射到多层企业级的J2EE应用上。

§         所有的企业数据以及商业逻辑可以作为模式。

§         视图可以通过模式访问数据,并根据客户端的要求来显示数据。视图必须保证当模式改变的时候,数据显示也必须同时改变。

§         控制器用来结合模式和视图,把客户端来的请求转换成模式能够理解并执行的请求,并且根据请求以及执行结果来决定下一次显示那一个视图。

根据以上的逻辑,你可以象这样建立一个应用:

§         应用的商业逻辑由MVC中的模式也就是EJB来表现。模式必须处理由控制器传递过来的对数据的访问请求。

§         多个页面组成了MVC中的视图,这些视图必须随模式一起更新。

§         控制器是一系列接收用户动作的对象,他们把用户的请求转换成模式可理解的请求,并决定显示那一个页面当模式处理完请求后。



图 1

c.       要点

§         MVC结构适用于那些多用户的,可扩展的,可维护的,具有很高交互性的系统。

§         MVC可以很好的表达用户的交互和系统模式。

§         很方便的用多个视图来显示多套数据,是系统很方便的支持其他新的客户端类型。

§         代码重复达到最低。

§         由于分离了模式中的流控制和数据表现,可以分清开发者的责任,另外,也可以加快产品推向市场的时间

3 解释三 http://www.chinaunix.net/bbsjh/14/1135.html
[转帖]了解MVC架构对于用Struts构建的强大的Web应用程序很重要

作者:cinc     发表时间:2002/12/03 08:48am

了解MVC架构对于用Struts构建的强大的Web应用程序很重要

Struts是雅加达的一个项目,它提供了一个方法,可以在一个Web应用程序中一起使用JavaServer  
Pages(JSP)和servlets。它的目的是要解决完全由JSP或完全由servlet实现的应用程序中的固有的问
题。 例如,servelts可以生成HTML页面,但这么做很麻烦。另一方面,JSP可以很容易地用于传统的
HTML页面,但JSP页面有其它的缺点。特别是,用JSP很难将内容同内容的显示分开。 很容易将Java 代
码同HTML混在一起,结果做出的东西又慢又难以维护。

然而,因为JSP页面容易使用,所以它们成为用Java构建动态的Web应用程序的首选方法。除了容易编程
外,JSP页面也被改进了,所以现在它们克服了以前的某些局限性。JavaBeans和标记库只是在基础的
JSP技术上的几个改进。这种类型的方法——JSP页面单独负责处理输入的请求和回复客户端——被称为
Model 1架构。

JavaServer Pages是servlets的特殊情况,所以两者可以一起工作以弥补每个的不足,这似乎是合乎逻
辑的。这种类型的方法——你的Web架构包含截然不同的但又互联的处理数据模式、显示代码和程序控
制逻辑的JSP和servlet组件——被称为Model 2架构,或Model-View-Controller(MVC)架构。

为了使用Struts架构以及用JSP和servlets有效地编程,对MVC架构的了解是很必要的。Model 1和MVC架
构的主要不同就是请求是在哪里处理的。在Model 1架构中,请求通过JSP接收,主要通过JSP处理。如
果JSP页面需要来自任何其它应用程序组件的服务,如一个数据库,那么你就从页面做适当的调用,把
数据返回到页面,安排数据的格式并显示出来。你可以把一些代码放到一个或多个JavaBean中,但是这
么做本身没有将逻辑同显示完全分离。

MVC方法采用了JSP和servlet方法的最佳特性,使这两种技术可以协同工作。明确的是,servlet是处理
层(控制器)。Servlet接收请求,很像Model 1架构中JSP页面所做的那样,并确定如何满足那些请
求。这就意味着,servlet控制输入的请求和输出的回应。

商业逻辑体现了MVC架构中的模式。商业逻辑代码为页面做处理。如果进入servlet的请求是一个数据库
查询,servlet就将这个请求传送到一个SQL调用或类似的数据库代码。如果请求是一个包括输入信用卡
号的购买请求,那么事物处理代码就接管了。在某种意义上,架构的模式部分是让应用程序处于领先地
位的全部原因。

JSP页面是显示层(视图),是用户与应用程序交互的地方。它提供输入并显示结果。页面不应该包括
任何脚本。它只是将数据传送到servlet,并接收和显示返回的数据。

该架构的优势应该是很明显的。首先,它将计算和显示清楚地分开了。结果很理想,在JSP页面上没有
出现处理过程,在servlet或商业逻辑中没有数据格式。这种分离的另一个好处是Java程序员可以专注
于servlet代码,HTML编写者可以专注于JSP。 第二点,控制器servlet做页面上的所有的决定。 在你
的页面和逻辑中不会出现任何决策。这就提高了一个应用程序的性能和可扩展性,因为请求可以被导向
架构的不同的组件,甚至是不同的服务器。


运用MVC架构

MVC架构没有必要成为用于所有Java应用程序的最佳方法。 如你想象的那样,它在准备和编码时往往很
复杂——这对简单的应用程序来说是没必要的。当页面导航相对来说比较简单和固定,而且应用程序中
的页面结构可以由一个简单的目录结构管理时, Model 1架构仍然是最好的方法。这些应用程序往往将
页面流动信息嵌入到页面间的链接中。(JSP中出现forward()就告诉你,在该页中有嵌入的逻辑,让你
对显示下一页作出决定。)对于对流量或可扩展性需求有限的静态的应用程序来说,标准的JSP模式仍
然是一个可行的选择方案。

在一些情况下,你可能想把一个JSP应用程序移植到MVC架构中。例如,你可能开始时用的是Model 1,
简单的JSP架构,随着你的需求的增加,你会发现维护起来太复杂或太难了。如果你花很长的时间对应
用程序做相对来说较简单的修改,或者如果你经常在你的代码中发现bug,那么你的JSP导向的应用程序
也许就不再是合适的方法了。

随着应用程序的发展和变化,页面的流动和商业逻辑也增加了。应用程序变得难以维护,因为页面流动
逻辑跨多个页面分布,而且商业逻辑可能开始存在于未计划的地方。从Model 1转到MVC的最佳时机就是
当这些类型的维护问题出现的时候。

你也可以预先计划将你的应用程序从一个架构移植到另一个架构。当你的应用程序中的JSP页面包含脚
本元素,定制标记或JavaScript来执行一个forward()操作时,你可能想调整你最初的设计,变成一种
用MVC架构的设计。

Refactoring用在这儿是个不错的术语。它指的是以一种高度严谨的方式重建代码结构的一种技术。当
你的代码变得难以理解、修改和调试时,你通常就开始考虑调整了。你可以用几种方式来调整代码:你
可以简单地重新命名变量和方法,或者将部分代码移植到不同类型的执行模式中。更多的关于调整及其
技术方面的信息,请访问Martin Fowler的网站www.refactoring.com 或者阅读他写的书  
Refactoring: Improving the Design of Existing Code。

在许多情况下,一开始就选择MVC架构是很有意义的,例如你的应用程序是为广泛的企业应用而设计
的,或者在几年内,你的应用程序可能扩展到一个相当高的流量。 设计一个MVC架构需要有深谋远虑。
大多数程序员发现写逻辑脚本或JavaBeans,以及用HTML显示很容易。当你设计一个MVC架构时,你必须
首先进行一个完整的设计。这就意味着,分析需要处理的请求的类型,确定哪些组件(JavaBean、数据
库或其它servlets)将处理这些请求,以及对那些请求的回应是如何显示给用户的。 该设计的关键就
是请求和数据的流动性。为MVC架构设计应用程序组件只是对你现在用JSP和servlets所做工作的扩展。
面临的挑战就是构建一个servlet,它接收请求并把那些请求分到应用程序的不同的组件。将一个数据
库请求传送到一个数据库,或将一个处理请求传送到一个JavaBean是很容易的,但是如果一个请求包含
这两种元素,会怎样呢?或者如果请求的性质在一些处理出现前不能确定,又怎样呢?


Struts 构架

该挑战使我们又回到Struts构架。Struts提供了一个实现MVC架构的高度自动化的方式。它的结构实现
了MVC,并包括一个控制器servlet、一组JSP页面和应用程序的商业逻辑。控制器将用户请求打包,并
把它们导向架构中的其他对象。

Struts构架是围绕一个ActionMapping 结构的。控制器用 ActionMapping 把HTTP消息形式的用户请求
转换成应用程序的动作。ActionMapping指定请求的路径、计划处理请求的对象以及任何服务该请求需
要的其它信息。ActionMapping创建了一个 Action 对象来处理请求。一旦Action对象完成了一个任
务,它就通过在一个JSP页面上写结果来直接回应一个用户请求,或者它可以让一个应用程序流动到其
它地方做回应。

http://www.chinaunix.net/bbsjh/14/1135.html
http://www.huihoo.com/java/java_web/java-web-6.html
http://www.jdon.com/idea/application.htm
http://sunrise.x168.net/java/020712,15,02,45.html
http://www-900.ibm.com/developerWorks/cn/java/l-struts-mvc/index.shtml
http://www.fawcette.com/china/Java/2002_04/article.asp?page=1&xml=StrutStuff

http://jakarta.apache.org/struts/

http://dev.csdn.net/article/58/58688.shtm

posted on 2005-02-17 15:33 阅读(200) 评论(0)  编辑  收藏 所属分类: J2ee


只有注册用户登录后才能发表评论。


网站导航: