MVC是一个架构，或者说是一个设计模式，它就是强制性使应用程序的输入，处理和输出分开。将一个应用程序分为三个部分：Model，View，Controller。
具体的话就是：
视图
视图就是负责跟用户交互的界面。一般就是由HTML，css元素组成的界面，当然现在还有一些像js，ajax，flex一些也都属于视图层。 在视图层里没有真正的处理发生，之负责数据输出，并允许用户操纵的方式。MVC一个大的好处是它能为你的应用程序处理很多不同的视图。
模型
Model代表一些应用数据和业务逻辑（一般通过通过javaBean，EJB之间实现）在MVC的三个部件中，模型拥有最多的处理任务。例如它可能用象EJBs和javabean这样的构件对象来处理数据库。被模型返回的数据是中立的，就是说模型与数据格式无关，这样一个模型能为多个视图提供数据。由于应用于模型的代码只需写一次就可以被多个视图重用，所以减少了代码的重复性。
控制器
控制器接受用户的输入并调用模型和视图去完成用户的需求。所以当单击Web页面中的超链接和发送HTML表单时，控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求，然后用确定用哪个视图来显示模型处理返回的数据。
这样强制性的分开之后会有很多的优点：
第一个：分工明确：使用MVC可以把数据库开发，程序业务逻辑开发，页面开发分开，每一层都具有相同的特征，方便以后的代码维护。它使程序员（Java开发人员）集中精力于业务逻辑，界面程序员（HTML和JSP开发人员）集中精力于表现形式上。
第二个：就是松耦合，视图层和业务层分离，这样就允许更改视图层代码而不用重新编译模型和控制器代码，同样，一个应用的业务流程或者业务规则的改变只需要改动MVC的模型层即可。因为模型与控制器和视图相分离，所以很容易改变应用程序的数据层和业务规则。
这一点我感觉比较重要，像实际应用的时候，我们还会把model模块细分为：数据库抽象层，数据操作层，业务逻辑层。这些也都是出于一个送耦合的考虑，改动其中一部分，不会影响到另一部分。
第三个：重用性高。像多个视图能够共享一个模型，不论你视图层是用flash界面或是wap界面，用一个模型就能处理他们。将数据和业务规则从表示层分开，就可以最大化从用代码。
用简单的jsp servlet 和javabean来举个注册的例子来说的话：首先是视图层注册的jsp文件，用户填写完用户信息后，提交一个请求，这个请求同过配置文件找到相应的servlet，servlet就相当于控制器，根据不同的用户请求类型，进而调用不用的业务逻辑层进行处理。处理完成之后又将结构信息反馈给jsp文件也就是视图层文件。最最简单的mvc大体上就是这个流程了。
不过MVC也有一定的缺点：
MVC的缺点是由于它没有明确的定义，所以完全理解MVC并不是很容易。使用MVC需要精心的计划，由于它的内部原理比较复杂，所以需要花费一些时间去思考。
你将不得不花费相当可观的时间去考虑如何将MVC运用到你的应用程序，同时由于模型和视图要严格的分离，这样也给调试应用程序带来了一定的困难。每个构件在使用之前都需要经过彻底的测试。一旦你的构件经过了测试，你就可以毫无顾忌的重用它们了。
根据开发者经验，由于开发者将一个应用程序分成了三个部件，所以使用MVC同时也意味着你将要管理比以前更多的文件，这一点是显而易见的。这样好像我们的工作量增加了，但是请记住这比起它所能带给我们的好处是不值一提。
MVC并不适合小型甚至中等规模的应用程序，花费大量时间将MVC应用到规模并不是很大的应用程序通常会得不偿失。
总之，不要为了MVC而MVC就行了。
具体的话就是：
视图
视图就是负责跟用户交互的界面。一般就是由HTML，css元素组成的界面，当然现在还有一些像js，ajax，flex一些也都属于视图层。 在视图层里没有真正的处理发生，之负责数据输出，并允许用户操纵的方式。MVC一个大的好处是它能为你的应用程序处理很多不同的视图。
模型
Model代表一些应用数据和业务逻辑（一般通过通过javaBean，EJB之间实现）在MVC的三个部件中，模型拥有最多的处理任务。例如它可能用象EJBs和javabean这样的构件对象来处理数据库。被模型返回的数据是中立的，就是说模型与数据格式无关，这样一个模型能为多个视图提供数据。由于应用于模型的代码只需写一次就可以被多个视图重用，所以减少了代码的重复性。
控制器
控制器接受用户的输入并调用模型和视图去完成用户的需求。所以当单击Web页面中的超链接和发送HTML表单时，控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求，然后用确定用哪个视图来显示模型处理返回的数据。
这样强制性的分开之后会有很多的优点：
第一个：分工明确：使用MVC可以把数据库开发，程序业务逻辑开发，页面开发分开，每一层都具有相同的特征，方便以后的代码维护。它使程序员（Java开发人员）集中精力于业务逻辑，界面程序员（HTML和JSP开发人员）集中精力于表现形式上。
第二个：就是松耦合，视图层和业务层分离，这样就允许更改视图层代码而不用重新编译模型和控制器代码，同样，一个应用的业务流程或者业务规则的改变只需要改动MVC的模型层即可。因为模型与控制器和视图相分离，所以很容易改变应用程序的数据层和业务规则。
这一点我感觉比较重要，像实际应用的时候，我们还会把model模块细分为：数据库抽象层，数据操作层，业务逻辑层。这些也都是出于一个送耦合的考虑，改动其中一部分，不会影响到另一部分。
第三个：重用性高。像多个视图能够共享一个模型，不论你视图层是用flash界面或是wap界面，用一个模型就能处理他们。将数据和业务规则从表示层分开，就可以最大化从用代码。
用简单的jsp servlet 和javabean来举个注册的例子来说的话：首先是视图层注册的jsp文件，用户填写完用户信息后，提交一个请求，这个请求同过配置文件找到相应的servlet，servlet就相当于控制器，根据不同的用户请求类型，进而调用不用的业务逻辑层进行处理。处理完成之后又将结构信息反馈给jsp文件也就是视图层文件。最最简单的mvc大体上就是这个流程了。
不过MVC也有一定的缺点：
MVC的缺点是由于它没有明确的定义，所以完全理解MVC并不是很容易。使用MVC需要精心的计划，由于它的内部原理比较复杂，所以需要花费一些时间去思考。
你将不得不花费相当可观的时间去考虑如何将MVC运用到你的应用程序，同时由于模型和视图要严格的分离，这样也给调试应用程序带来了一定的困难。每个构件在使用之前都需要经过彻底的测试。一旦你的构件经过了测试，你就可以毫无顾忌的重用它们了。
根据开发者经验，由于开发者将一个应用程序分成了三个部件，所以使用MVC同时也意味着你将要管理比以前更多的文件，这一点是显而易见的。这样好像我们的工作量增加了，但是请记住这比起它所能带给我们的好处是不值一提。
MVC并不适合小型甚至中等规模的应用程序，花费大量时间将MVC应用到规模并不是很大的应用程序通常会得不偿失。
总之，不要为了MVC而MVC就行了。