ASP.NET MVC 2.0——宏观认识

ASP.NET MVC是Microsoft开发的Web开发框架，不同于Web Form的开发框架，无需关注Page, controls, post back和ViewState，甚至包括复杂的事件机制，需要关注的只是Controller, Action和View。

Model-View-Controller(MVC)这个思想并不是Microsoft创造的，而是由Smalltalk社区贡献，例如Java社区的Struts，Ruby社区的Rails等Web开发框架也都是基于MVC思想的。

需要指出的是，MVC和三层结构，二者不是一个概念，但是三层结构中的UI层可以使用MVC的思想来实现，当然也可以用其他方式，如：Web Form实现。

对于UI层来说，通常由两个部分组成，一个是客户端展现的HTML，另一个就是请求处理逻辑（控制HTML输出或者请求重定向等）。在MVC框架里包含三个部分：

View：     页面的HTML

Controller：请求处理

Model：这里又可以分成两个Model，一种是页面的Model，可以认为是页面数据结构，另一种是业务的Model。

当用户请求一个页面时，首先Controller会根据上下文参数，执行代码逻辑，例如向BL层获取业务Model，然后将此Model转换成页面的Model并绑定到该View上，Controller执行完毕后View就根据被绑定上的Model渲染页面，渲染成功后返回HTML给客户端；有时也会不需要向BL层获取业务Model而是直接生成页面Model绑定到View上，这取决于具体的情况。一般来说，如果Controller能够独立产生所需的数据，则不需要向BL层获取，如果不能则需要向BL层获取Model以便产生页面的Model。

这里有个问题了，如果Controller直接使用BL层的Model作为页面的Model如何？好处和坏处都会有一些：

好处：

1. 避免Model转换            

   不要小看Model转换，尤其是业务Model结构复杂时，花在转换上的时间是绝对不能被忽略的，会对性能产生影响，而且很难调优。

2. 整个Web应用只有一个Model    

   这样的程序一致性较好，最明显的就是枚举的统一性，可以提高开发效率，减小风险。

坏处：

1. 容易破坏业务Model的结构    

   如果需要在View上增加一个元素，则需要在业务Model上添加数据项，有时这些数据和业务本身是没有关联的，譬如一些提示信息。

2. View的变更收到限制        

   对于Web类应用View的变更比较频繁，常常会发生一些UI改版等等，如果使用业务Model作为View的Model，则制约了View变更。

综合来看，对于View变化比较频繁的应用最好给View单独的Model，不过这要付出一些性能上的损失和增加Model管理上的复杂；如果View相对稳定，譬如RIA类应用Flash向服务器请求数据，实际上服务器是把该请求产生的View返回给Flash，这时的View与UI无关，只是单纯的数据，仅使用一种Model应该是较好的方案。