在技术分享课上，小组成员比较了Thinkjs与Express，说Thinkjs的分层设计更好，而Express的MVC框架更容易理解，当时我打断了他的讲述并提问，Express没有分层吗？MVC不能分层吗？MVC到底分几层？

      MVC到底分几层？其实，这是一个混淆逻辑的说话，MVC是一种复合的设计模式，而分层则是一种降低耦合的架构设计思想，这两者本来风牛马不相及，然而随着Struts、Spring MVC等WEB框架的兴起，加上一群辅导老师的推泼助澜，把它们强行堆积在一起，在面试JAVA程序员时，经常听到这样的说法，MVC分为三层，控制器C是第一层，业务模型M是第二层，数据访问是第三层，如果我继续问，那视图V在哪一层？应试者一般都哑口无言。

      在大部分的WEB应用中，我们一般都划分为三层，WEB控制层、业务逻辑层与数据访问层，见下图所示。但这并不意味着，我们只能划分为三层，划分为多少层完全取决于业务的需要，比如还可以添加基础服务层、数据集成层等，并且还可以切面分层，如安全控制层、系统日志层等。 

      需要注意的是，这里的分层跟MVC真没什么关系，如果有，那还破坏了分层思想的设计原则，分层思想的核心就是不能进行跨层调用，并且调用的方向是不可逆的，MVC能满足这样的设计原则吗？当然不能！无论把控制器C放到哪一层，它都要进行双层调用，分别调用业务模型M与视图模型V，如下图所示。 
 
      最后，需要重点说明的，业务模型M与视图模型V并不是没有联系，而只是没有直接的联系，以Spring MVC为例，业务模型M与视图模型V至少还需要验证器、数据格式花器以及转换器，否则视图既无法显示模型的内容，模型也无法根据视图的变化自动更新。原因？原因当然是视图只能接受基本类型的数据了。

       在大部分的WEB应用中，我们一般都划分为三层，WEB控制层、业务逻辑层与数据访问层，见下图所示。但这并不意味着，我们只能划分为三层，划分为多少层完全取决于业务的需要，比如还可以添加基础服务层、数据集成层等，并且还可以切面分层，如安全控制层、系统日志层等。

MVC系统中的模型从概念上可以分为两类――系统的内部状态和改变系统状态的动作。模型是你所有的商业逻辑代码片段所在。本文为模型提供了业务实体对象和业务处理对象：所有的业务处理对象都是从ProcessBase类派生的子类。业务处理对象封装了具体的处理逻辑，调用业务逻辑模型，并且把响应提交到合适的视图组件以产生响应。业务实体对象可以通过定义属性描述客户端表单数据。所有业务实体对象都EntityBase派生子类对象，业务处理对象可以直接对它进行读写，而不再需要和request、response对象进行数据交互。通过业务实体对象实现了对视图和模型之间交互的支持。实现时把"做什么"（业务处理）和"如何做"（业务实体）分离。这样可以实现业务逻辑的重用。由于各个应用的具体业务是不同的，这里不再列举其具体代码实例。MVC（模型Model-视图View-控制器Controller）是一种设计模式，我们可以用它来创建在域对象和UI表示层对象之间的区分。 同样是架构级别的，相同的地方在于他们都有一个表现层，但是他们不同的地方在于其他的两个层。 在三层架构中没有定义Controller的概念。这是我认为最不同的地方。而MVC也没有把业务的逻辑访问看成两个层，这是采用三层架构或MVC搭建程序最主要的区别。当然了。在三层中也提到了Model，但是三层架构中Model的概念与MVC中Model的概念是不一样的，“三层”中典型的Model层是以实体类构成的，而MVC里，则是由业务逻辑与访问数据组成的。在ASP NET中的MVC架构编写的，具有极其良好的可扩展性。它可以轻松实现以下功能： ①实现一个模型的多个视图；②采用多个控制器；③当模型改变时，所有视图将自动刷新；④所有的控制器将相互独立工作。这就是MVC架构的好处，只需在以前的程序上稍作修改或增加新的类，即可轻松增加许多程序功能。以前开发的许多类可以重用，而程序结构根本不再需要改变，各类之间相互独立，便于团体开发，提高开发效率。下面讨论如何实现一个模型、两个视图和一个控制器的程序。其中模型类及视图类根本不需要改变，与前面的完全一样，这就是面向对象编程的好处。对于控制器中的类，只需要增加另一个视图，并与模型发生关联即可。该模式下视图、控制器、模型三者之间的示意图如图2所示。同样也可以实现其它形式的MVC例如：一个模型、两个视图和两个控制器。从上面可以看出，通过MVC架构实现的应用程序具有极其良好的可扩展性，是ASP NET面向对象编程的未来方向。MVC的不足体现在以下几个方面：（1）增加了系统结构和实现的复杂性。对于简单的界面，严格遵循MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。（2）视图与控制器间的过于紧密的连接。视图与控制器是相互分离，但确实联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。3）视图对模型数据的低效率访问。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。（4）目前，一般高级的界面工具或构造器不支持MVC架构。改造这些工具以适应MVC需要和建立分离的部件的代价是很高的，从而造成使用MVC的困难。

你说的的model，view，Controller吧

三层作用：1.视图：视图是用户看到并与之交互的界面。对老式的Web应用程序来说，视图就是由HTML元素组成的界面，在新式的Web应用程序中，HTML依旧在视图中扮演着重要的角色，但一些新的技术已层出不穷，它们包括Macromedia Flash和像XHTML，XML/XSL，WML等一些标识语言和Web services. 　　如何处理应用程序的界面变得越来越有挑战性。MVC一个大的好处是它能为你的应用程序处理很多不同的视图。在视图中其实没有真正的处理发生，不管这些数据是联机存储的还是一个雇员列表，作为视图来讲，它只是作为一种输出数据并允许用户操纵的方式。2.模型：模型表示企业数据和业务规则。在MVC的三个部件中，模型拥有最多的处理任务。例如它可能用像EJBs和ColdFusion Components这样的构件对象来处理数据库。被模型返回的数据是中立的，就是说模型与数据格式无关，这样一个模型能为多个视图提供数据。由于应用于模型的代码只需写一次就可以被多个视图重用，所以减少了代码的重复性。3.控制器：控制器接受用户的输入并调用模型和视图去完成用户的需求。所以当单击Web页面中的超链接和发送HTML表单时，控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求，然后确定用哪个视图来显示模型处理返回的数据。 　　现在我们总结MVC的处理过程，首先控制器接收用户的请求，并决定应该调用哪个模型来进行处理，然后模型用业务逻辑来处理用户的请求并返回数据，最后控制器用相应的视图格式化模型返回的数据，并通过表示层呈现给用户。

视图层用jsp，javascript

作用--显示数据，接受用户输入数据

控制层用servlet

作用--接收视图层数据，传输 给业务逻辑层（即模型层）

模型层用普通java class

作用--业务类的实现，如：数据库操作

MVC到底分几层？其实，这是一个混淆逻辑的说话，MVC是一种复合的设计模式，而分层则是一种降低耦合的架构设计思想，这两者本来风牛马不相及，然而随着Struts、Spring MVC等WEB框架的兴起，加上一群辅导老师的推泼助澜，把它们强行堆积在一起，在面试JAVA程序员时，经常听到这样的说法，MVC分为三层，控制器C是第一层，业务模型M是第二层，数据访问是第三层，如果我继续问，那视图V在哪一层？应试者一般都哑口无言。

      在大部分的WEB应用中，我们一般都划分为三层，WEB控制层、业务逻辑层与数据访问层，见下图所示。但这并不意味着，我们只能划分为三层，划分为多少层完全取决于业务的需要，比如还可以添加基础服务层、数据集成层等，并且还可以切面分层，如安全控制层、系统日志层等。

      需要注意的是，这里的分层跟MVC真没什么关系，如果有，那还破坏了分层思想的设计原则，分层思想的核心就是不能进行跨层调用，并且调用的方向是不可逆的，MVC能满足这样的设计原则吗？当然不能！无论把控制器C放到哪一层，它都要进行双层调用，分别调用业务模型M与视图模型V，如下图所示。

      最后，需要重点说明的，业务模型M与视图模型V并不是没有联系，而只是没有直接的联系，以Spring MVC为例，业务模型M与视图模型V至少还需要验证器、数据格式花器以及转换器，否则视图既无法显示模型的内容，模型也无法根据视图的变化自动更新。原因？原因当然是视图只能接受基本类型的数据了。