Model:模型层
View:视图层
Controller:控制层
MVC (Modal View Controler)本来是存在于Desktop程序中的，M是指数据模型，V是指用户界面，C则是控制器。使用MVC的目的是将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式。比如一批统计数据你可以分别用柱状图、饼图来表示。C存在的目的则是确保M和V的同步，一旦M改变，V应该同步更新。
模型－视图－控制器（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，并且有能力应付它所带来的额外的工作和复杂性，MVC将会使你的软件在健壮性，代码重用和结构方面上一个新的台阶。
希望对您有所帮助！~
对MVC模式的理解是什么？, 描述一下对MVC模式的理解？Model（模型）表示应用程式核心（比如资料库记录列表）。
View（检视）显示资料（资料库记录）。
Controller（控制器）处理输入（写入资料库记录）。
下面说说简单的理解,个人感觉:
Model 实体类,例如蛋糕,奶茶,糖果
View 介面控制,例如店面
Controller 使用者介面类,使用者会首先访问这个东西,例如营业员
上面三者合起来就是 你构建了一个场景:营业员在经营食品店....然后你的客户访问你的网页就像去买糖果一样
另外,这模式就是一种划分而已,尤其是实体类多和业务逻辑复杂,中大型专案建议使用
用比较老的开发方法就是没划的这么清晰,但是小专案比MVC更方便
谈谈对MVC和Struts模式的理解
MVC方式通常在Smalltalk中用于建立使用者介面。通过对MVC中蕴藏的设计模式可以帮你理解我们所说的“模式”的含义。
MVC包括三类物件，Model是应用物件、View为其萤幕表示、Controller定义了对使用者输入的处理（反应）方式。在应用MVC方式以前，通常将这三个物件的功能合到了一起，应用MVC分离了它们，为设计提供了灵活性和可重用性。
MVC通过在view和model之间建立Subscribe/Notify协议，分离了view和model物件。View物件必须保证它的表示反应了model物件的状态，当model物件的资料改变时，model物件通知（Notify）view物件，作为对这一行为的反应，每个view物件得到了一个做出更新的机会。这种方式使得可以将多个view物件为一个model物件提供不同的表示。你也可以为model物件建立新的view物件，而不用重新编写model。下图演示了一个model和三个view：
从表面看，这一例子反应了一个将view和model分离的设计。然而，这种设计适合一类更通用的问题：减少物件之间的藕和性，这样，当一个物件改变时，将不会影响到另外的物件，甚至不需要知道另外的物件的实现细节。这种更通用的模式将在Observer模式中来描述。
MVC方式的另一个特点是，view物件是可巢状定义的。例如，button的控制板可由一个包含巢状button view物件的复杂view物件来实现；物件观察器的使用者介面可由能重用于侦错程式的巢状view物件组成。MVC方式采用CompositeView类（View的子类）来支援巢状view，其行为与view物件的行为一致，可用于view物件能使用的任何场合。
于是，我们又可以把这种对待posite view就像处理其一个元件的方式看成一种设计（方式）。同样的，这种设计可抽象出另一类更通用的问题（的解决方式）：我们在某种情形下将物件分成组，并且处理一个组就像对待物件个体。这种方式我们用Composite设计模式来描述。它允许你建立类的层次，在这一层次下，有些子类定义原始物件（如Button），而其它的类可以定义合成物件（CompositeView），合成物件可将原始物件装配成更复杂的物件。
同样，MVC也可改变检视类（view）对使用者反应的方式，而不用改变其视觉化表示。你可能想改变其对键盘响应的方式，如，使用弹出选单代替命令键。MVC将这种反应机制封装为控制物件（Controller）。控制器有一个类层次，易于实现从一个已存在的控制器建立出一个变种—一种新的控制器。
检视（view）物件通过某一控制器物件的例项（instance）来实现特定的响应策略。为了实现不同的策略，可以简单的使用不同的控制器例项来替换当前的例项。甚至可以在执行时来改变检视的控制器，以改变检视物件对使用者输入的响应（策略）。例如，一个view物件可置为disabled，即对使用者的输入不做任何响应。要达到这一目的，仅仅只需让控制器忽略所有input事件。
这种检视—控制器关系即是Strategy设计模式的一个典型例子。所谓Strategy即这样一个物件，它表示了一种演算法。这在你想要替换演算法（无论是静态替换还是动态替换）时特别有用，而这样的演算法可能有许多的变数、或者拥有复杂的资料结构。
MVC中也使用了别的设计模式，例如，使用Factory Method模式来描述检视的预设控制器类；采用Decorator模式来为检视增加滚动条等。但在MVC中的主要模式是前述的Observer、Composite、和Strategy设计模式。
如何理解spring MVC模式
1. 原理
Spring MVC按植物分类学属于Martin Flower〈企业应用模式〉里的静态配置型Front Controler，使用DispatchServlet截获所有*.do的请求，按照xml档案的配置，呼叫对应的Command物件的 handleRequest(request,response)函式，同时进行依赖物件的注入。
我们的Controller层，就是实现handleRequest(request,response)函式的普通JavaBean。
2. 优势
Spring MVC与struts相比的优势:
一是它的Controller有着从松到紧的类层次结构，使用者可以选择实现只有一个HandleRequest()函式的介面，也可以使用它有很多回调函式的SimpleFormController类。
二是不需要Form Bean，也不需要Tapestry那所谓面向物件的页面物件，对于深怕类膨胀，改一个东西要动N个地方的人最适合不过。
三是不需要强XML配置档案，宣告式程式设计是好的，但如果强制成框架，什么都要在xml里面宣告，写的时候繁琐，看的时候也要程式码配置两边看才能明白就比较麻烦了。
那Webwork呢?没有实战过，不过因为对MVC框架所求就不多，单用Spring MVC的Controller已经可以满足需求，就不多搞一套Webwork来给团队设坎，还有给日后维护，spring,ww2之间的版本升级添麻烦了。真有什么需要新增的，Spring MVC原始码量很少，很容易掌控和扩充套件。
3.化简
3.1. 直接implement Controller，实现handleRequest()函式
首先，simple form controller非我所好，一点都不simple。所以有时我会直接implement Controller介面。这个介面的唯一函式是供Front Controller呼叫的handleRequest(request,response)。
如果需要application物件，比如想用application.getRealPath()时，就要extends webApplicationObjectSupport。
3.2.每个Controler负责一组相关的action
我是坚决支援一个Controler负责多个action的，一个Controler一个action就像一个function一个类一样无聊。所以我用最传统的方式，用URL引数如msg="insert"把一组相关action交给一个Controler控制。ROR与制作中的Groovy On Rails都是这种模式，Spring也有MultiActionController支援。
以上三者都是把URL引数直接反射为Controller的函式，而Stripes的设计可用annotation标注url action到响应函式的对映。
3.3.xml宣告式程式设计的取舍
我的取舍很简单，反正Spring没有任何强制，我只在可能需要不重新编译而改变某些东西的时候，才把东西放在xml里动态注入。jsp路径之类的就统统收回到controller里面定义.
如何理解mvc模式中的model
MVC(Model/View/Controller)模式是国外用得比较多的一种设计模式，好象最早是在Smaltalk中出现。MVC包括三类物件。Model是应用物件，View是它在萤幕上的表示，Controller定义使用者介面对使用者输入的响应方式。
模型-检视-控制器（MVC）是80年代Smalltalk-80出现的一种软体设计模式，现在已经被广泛的使用。
1、模型（Model）
模型是应用程式的主体部分。模型表示业务资料，或者业务逻辑.
2、检视（View）
检视是应用程式中使用者介面相关的部分，是使用者看到并与之互动的介面。
3、控制器（controller)
控制器工作就是根据使用者的输入，控制使用者介面资料显示和更新model物件状态。
MVC 式的出现不仅实现了功能模组和显示模组的分离，同时它还提高了应用系统的可维护性、可扩充套件性、可移植性和元件的可复用性
早期的程式中，如果不注意对数功能和显示的解耦合，常常会导致程式的复杂及难以维护。很多VB,Delphi等RAD程式都有这种问题。甚至现在的C#,Java有时候也会出现把业务逻辑写在显示模组中的现象
管MVC设计模式很早就提出，但在Web专案的开发中引入MVC却是步履维艰。主要原因：一是在早期的Web专案的开发中，程式语言和HTML的分离一直难以实现。CGI程式以字串输出的形式动态地生成HTML内容。后来随着指令码语言的出现，前面的方式又被倒了过来，改成将指令码语言书写的程式嵌入在HTML内容中。这两种方式有一个相同的不足之处即它们总是无法将程式语言和HTML分离。二是指令码语言的功能相对较弱，缺乏支援MVC设计模式的一些必要的技术基础。直到基于J2EE的JSP Model 2问世时才得以改观。它用JSP技术实现检视的功能，用Servlet技术实现控制器的功能，用JavaBean技术实现模型的功能
JSP Model 1 与 JSP Model 2
SUN在JSP出现早期制定了两种规范，称为Model1和Model2。虽然Model2在一定程度上实现了MVC，但是它的应用用并不尽如人意
JSP Model 1
JSP Model 2
model2 容易使系统出现多个Controller，并且对页面导航的处理比较复杂
有些人觉得model2仍不够好，于是Craig R. McClanahan 2000年5月提交了一个WEB framework给Java Community.这就是后来的Struts.
2001年7月，Struts1.0，正式释出。该专案也成为了Apache Jakarta的子专案之一
Struts 质上就是在Model2的基础上实现的一个MVC架构。它只有一个中心控制器，他采用XML定制转向的URL。采用Action来处理逻辑
理解阐述 MVC模式 优势在哪
MVC思想将一个应用分成三个基本部分：Model（模型）、View（检视）和Controller（控制器），这三个部分以最少的耦合协同工作，从而提高应用的可扩充套件性及可维护性。
MVC模式与三层模式的区别?
晕，居然还有人说是一个意思
你所指的三层是j2ee设计中的三层，这个你很清楚，我就不说了。
MVC是java设计模式中的术语，跟这个三层说的不是一个方面的东西。
MVC ：model，view，control 表示，如果软体需要用到UI介面，那么就应该分成： 模型层，表示层，控制层三层，
原因是模型表示资料原形， 表示层用来对资料进行绘制和表示。控制用来操控这些资料，
使用者一般看到了表示层上的介面，使用控制层来控制介面，最后的结果影响到模型层。
MVC模式与工厂模式，单例模式，命令模式，等等一起共20多种合称为程式语言的设计模式，它是我们平时程式设计时的经验累积。我们在设计我们的程式时可以以它们做为参考进行程式的架框设计。
最后再说一句： MVC的要义就是显示的专业显示，逻辑的专业逻辑， 逻辑与绘图分开，不一定会是三层，可能会有更多层。只要能达到MVC要求的规则，你想几层都可以。 目的就是达到程式的各个模组之间尽量脱藕合。
可能我们说得让你有点一头雾水，所以强烈建议楼主去补习一下20多种设计模式。学了设计模式会对你的程式水平有质的提升，真的，我就是学完会爱上java的，以前把学习java当成任务，但学了设计模式后就爱上它了!
为什么要使用MVC模式，MVC模式的优势有哪些
最大的优势在于mvc可以利于维护，以前java程式码和前端程式码混在一起，很不容易维护
如何理解MVC模式还有工厂设计模式
1、MVC属于框架模式，框架与设计模式虽然相似，但却有着根本的不同。设计模式是对在某种环境中反复出现的问题以及解决该问题的方案的描述，它比框架更抽象；
2、框架可以用程式码表示，也能直接执行或复用，而对模式而言只有例项才能用程式码表示设计模式是比框架更小的元素，一个框架中往往含有一个或多个设计模式，框架总是针对某一特定应用领域，但同一模式却可适用于各种应用。
3、可以说，框架是软体，而设计模式是软体的知识。
android和ios的mvc模式的区别
在学习 iOS 应用程式开发时，需对Cocoa Touch 的几种设计模式有所了解。 谈到设计模式，有人会觉得这是纸上谈兵，故作玄虚。我们这里不谈设计模式有多么多么神奇， 只对iOS Framework 已经用到的设计模式，逐一剖析。
学习iOS 开发，以下几种设计模式，是不可不知的：
Target Action Design Pattern
Notification Pattern
MVC Pattern
KVO （Key-Value Observing）
Singleton Pattern
Delegate Pattern
MVC 设计模式
相信你对 MVC 设计模式 并不陌生。从字面意思来理解， Modal , View , Controller ，其用意在于将资料与检视分离开来。 在iOS cocoa touch 程式设计中， MVC机制被发挥得淋漓尽致。 MVC 示意图如下。 只有充分理解了MVC，才能在编写出优雅的iOS app。为充分理解 MVC， 相关的概念（比如： Delegate、 Protocol、 Notification 等）也要了然于胸。
MVC 约定， Model 不允许与View 打交道。 Model 是管理资料的， 当Model中的资料发生变化时，与之对应的检视应更新。 这就需要一种机制来支援。为此 iOS 框架提供了两种支援机制： Notification 和KVO （Key-Value Observing）。 KVO 可简单理解为，为你所关注的 Key 物件注册一个监听器。 当有资料发生变化时，就会发出广播给所有的监听器。
MVC 也约定， View 不允许直接引用Modal， 它只能被Controller 所控制。 Controller 控制 View 显示什么资料。我们知道，View 所要显示的资料是来源于 Modal， View 上产生的事件 （ 比如 Touch事件）需要通知 Controller。 既然MVC 不允许直接打交道，就需要提供一种机制。
不错， iOS 确实提供了一种机制， 名曰： Delegate。 Delegate 这个词， 有人将它译为“委托”，也有人将它译为“代理”。名称上的差异没有什么，重要的是如何理解 Delegate。 Delegate设计模式的引入，就是为了解决UIView与Controller松耦合互动问题。
为便于理解， 这里撷取一张来iOS MVC 示意图：
我们在详细介绍下这张图的内涵：
1. 图中，绿色的箭头表示直接引用。 对View 的直接引用体现在 IBOutlet 上。 当引用一个View 时，比如Button。 需要在ViewController
中宣告一个 IBOutlet UIButton * btn；
2. 然后，我们看View 是怎么向 Controller 通讯的。对于这个， iOS 有三种常见的模式：
设定View对应的Action Target。如设定UIButton的Touch up inside的Action Target。
设定View的Delegate，如UIAlertViewDelegate, UIActionSheetDelegate，UITextFieldDelegate等。
设定View的data source, 如UITableViewDataSource。
通过以上三种模式，View既能向Controller通讯，又无需知道具体的Controller是谁，这样，View 就与Controller解耦了。
除此之外， iOS 还提供了 Action-Target 模式来让Controller 监听View 触发的事件。 View 又是如何获取资料呢？ iOS提供了 Data source 的概念，其实也就是Protocol 的应用。
综上所述， 正是在iOS MVC框架的驱使下， 才需要深入理解 Delegate、Protocol等概念。
MVC是一种通用的编程思想，独立于语言。MVC意思是Model(模型)+View(视图)+Controller(控制器)。其中Model指的就是数据模型，负责封装数据、处理数据；View负责展示用户界面；Controller用于协调模型和视图，负责接收用户请求。
