下面的这些概念很大一部分是百度大神的，我会在转述的时候加上自己的意见^^
什么是MVC
MVC翻译过来就是模型-视图-控制器模式，m=model，v=view，c=controller。常见的jsp+javabean+servlet就是典型的MVC模式。
使用MVC的目的是把m和v分离，使得一样的逻辑可以有不同的表现形式。比如同一批统计数据可以分别以柱状图和饼图来表示，c的作用是进行M与V之间的数据同步。
MVC的优点
- 低耦合性：视图层（V）和业务层（C）分离，这样就允许修改视图的同时不需要重新编译或修改控制器的代码。同样，一个应用的业务流程或者业务规则的改变只需要改动MVC的模型层即可。百度上是这样说的，我觉得有点吹牛了。在模型层代码改动的时候，相应的其他两层有很大可能是也需要修改的，使用MVC的话，带来的好处只是在修改代码的时候，思路会很清晰，不会轻易遗漏掉什么，修改后的测试也会比较容易排查（个人心得^^）。
- 高重用性和可适用性：这个作用很重要，但是觉得和第一点有点重复，感觉第一点是原因，这里是结果，又有夸大的嫌疑。低耦合带来的必然是高可重用性和高可维护性。不多说了。
- 较低的生命周期成本：百度上说MVC使降低开发和维护用户接口的技术含量成为可能。个人觉得MVC这方面的作用要看项目的规模还有要求。MVC模式开发项目的时候，第一个版本会慢一些，因为考虑到MVC给项目设计带来的复杂度，还有为了解耦而做的一些额外工作，对性能有很大要求的项目其实是不适合MVC的。但是一旦框架搭起来以后，MVC会让你觉得后续开发顺风顺水。
- 快速部署：使用MVC模式使开发时间得到相当大的缩减，他使程序员集中精力于业务逻辑，界面程序员集中于表现形式上。个人觉得有了MVC不能否定了沟通，没有完美的设计，无论是UI还是逻辑在时间阶段必然会遇到各种问题，最初设计也可能被修改，这时候，各个小组之间的同步就很重要。但是，MVC确实能省略掉很多不必要的等待。
-
可维护性：不说了，第一条带来的好处。
MVC的缺点
- 首先就是，MVC没有明确的定义，所以完全理解MVC就要靠构架师的实际经验，也就是对个人能力的过分依赖，MVC的使用，带来对设计阶段更加严格的要求，会大幅度增加复杂度和设计风险。
- 对测试有相当的要求，每个模块必须严格的经过单元测试。同时，由于解耦，调试会有些困难。
- 将一个程序分成三个组件，带来最直观的不爽就是要维护多三倍的文件数量，会增加部分工作量。但是，当你需要改动项目的时候就会发现，这些是值得的。
-
MVC不适合小项目，白白增加复杂度。
MVC如何工作
MVC是一个设计模式，它强制性的使应用程序的输入、处理和输出分开。使用MVC应用程序被分成三个核心部件：模型、视图、控制器。它们各自处理自己的任务。
- 视图
视图是用户看到并与之交互的界面。对老式的Web应用程序来说，视图就是由HTML元素组成的界面，在新式的Web应用程序中，HTML依旧在视图中扮演着重要的角色，但一些新的技术已层出不穷，它们包括Adobe Flash和象XHTML，XML/XSL，WML等一些标识语言和Web services.
如何处理应用程序的界面变得越来越有挑战性。MVC一个大的好处是它能为你的应用程序处理很多不同的视图。在视图中其实没有真正的处理发生，不管这些数据是联机存储的还是一个雇员列表，作为视图来讲，它只是作为一种输出数据并允许用户操纵的方式。
- 模型
模型表示企业数据和业务规则。在MVC的三个部件中，模型拥有最多的处理任务。例如它可能用象EJBs和ColdFusion Components这样的构件对象来处理数据库。被模型返回的数据是中立的，就是说模型与数据格式无关，这样一个模型能为多个视图提供数据。由于应用于模型的代码只需写一次就可以被多个视图重用，所以减少了代码的重复性。
- 控制器
控制器接受用户的输入并调用模型和视图去完成用户的需求。所以当单击Web页面中的超链接和发送HTML表单时，控制器(例如:servlet)本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求，然后确定用哪个视图来显示模型处理返回的数据。
现在我们总结MVC的处理过程，首先控制器接收用户的请求，并决定应该调用哪个模型来进行处理，然后模型用业务逻辑来处理用户的请求并返回数据，最后控制器用相应的视图格式化模型返回的数据，并通过表示层呈现给用户。