一年前就学过这个问题，可是没有好好深入下去，重新来过。
1 解释一 http://dev.csdn.net/article/52/52575.shtm
模型－视图－控制器（MVC）是XeroxPARC在八十年代为编程语言Smalltalk－80发明的一种软件设计模式，至今已被广泛使用。最近几年被推荐为Sun公司J2EE平台的设计模式，并且受到越来越多的使用 ColdFusion 和 PHP 的开发者的欢迎。模型－视图－控制器模式是一个有用的工具箱，它有很多好处，但也有一些缺点。
MVC如何工作
MVC是一个设计模式，它强制性的使应用程序的输入、处理和输出分开。使用MVC应用程序被分成三个核心部件：模型、视图、控制器。它们各自处理自己的任务。
视图
视图是用户看到并与之交互的界面。对老式的Web应用程序来说，视图就是由HTML元素组成的界面，在新式的Web应用程序中，HTML依旧在视图中扮演着重要的角色，但一些新的技术已层出不穷，它们包括MacromediaFlash和象XHTML，XML/XSL，WML等一些标识语言和Webservices.
如何处理应用程序的界面变得越来越有挑战性。MVC一个大的好处是它能为你的应用程序处理很多不同的视图。在视图中其实没有真正的处理发生，不管这些数据是联机存储的还是一个雇员列表，作为视图来讲，它只是作为一种输出数据并允许用户操纵的方式。
模型
模型表示企业数据和业务规则。在MVC的三个部件中，模型拥有最多的处理任务。例如它可能用象EJBs和ColdFusionComponents这样的构件对象来处理数据库。被模型返回的数据是中立的，就是说模型与数据格式无关，这样一个模型能为多个视图提供数据。由于应用于模型的代码只需写一次就可以被多个视图重用，所以减少了代码的重复性。
控制器
控制器接受用户的输入并调用模型和视图去完成用户的需求。所以当单击Web页面中的超链接和发送HTML表单时，控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求，然后用确定用哪个视图来显示模型处理返回的数据。
现在我们总结ＭVC的处理过程，首先控制器接收用户的请求，并决定应该调用哪个模型来进行处理，然后模型用业务逻辑来处理用户的请求并返回数据，最后控制器用相应的视图格式化模型返回的数据，并通过表示层呈现给用户。
为什么要使用 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/
