从MVC与三层架构谈到优化架构提高Web效率
上次炮轰过了MVC，今次又来炮轰三层架构，感觉自己像是在到处贴大字报的红卫兵^_^，不过理不辨不明，希望我的砖头能引来更加精辟的阐述。
说道3层架构，MVC其实是因为看到某男给我看他的概要设计书引出来的，因为此君很能够代表很多的刚入门的开发者，他所经历的误区，可能很多开发者都会经历（也包括我自己，当年干过很多傻事）。从历史沿革上来说，MVC和分层设计是没有交集的，很多时候很多人会觉得这样也好，那样也好，于是就把两个概念混淆起来，于是某君的概要设计书就写成这样子：
......本系统是典型的3层架构设计，采用MVC模式......
这里不是说3层不好或者是MVC不好，不过起码需要先搞清楚何为3层，何为MVC才能说两者能不能结合起来或者怎么结合起来，不过在这个ORM（其实ORM也是个概念而已，不管你是代码生成器，组件还是自己动手写）横行的年代，3层的意义已经被淡化了。我们首先来看看3层架构的概念是怎么回事。一般意义上的3层就是表现层，业务逻辑层，数据操作层。没层之间是一种垂直的关系，换言之可以很直观的表现在很厚的调用栈上。其实是从网络分层的概念上借用来的。在网络每个层次都是一个协议栈，上层协议和下层协议因为层次间的接口的稳定而存在一种弱耦合的情况，上层协议是不会关心底层协议是什么的。所以程序上的3层架构就是为了实现弱耦合而出现的，对于页面来说业务逻辑的实现是透明的，对于业务逻辑来说，数据操作的细节是透明的，然后可以分开让不同的程序员去实现。so，看起来是个不错的馅饼，不过面临的问题也很简单，长长的调用栈，效率的降低，和扩展的复杂，每次扩展功能我们都需要重新编译部署整个业务逻辑层的Dll，和Site，但是这时要看适用范围的，很多时候，网站的逻辑都是相当的简单的，读表，填充Grid完毕。这样子的逻辑都要在业务逻辑里跑一次，其实协议个方法出来里面却只有一行，或者几行代码，其实就是转发一下数据层的结果。老实说如果是做个新闻发布的系统的话，业务逻辑层几乎通篇都是转发的代码，结果当修改了数据库的时候还要多改几个地方，简直是没事找事啊。还有种情况就是大量使用存储过程，逻辑都在存储过程里去了，结果业务逻辑层武功尽废，彻底沦为一个传声筒。有人说可以在这里验证数据阿，看来也就这点事情了，犯得着写一层膜嘛，是男的都知道多层膜不爽，那你为什么还要用？
再来看MVC，虽然上次炮轰过MVC（MVP），不过相对千层饼来说，MVC还是要可爱得多。起码更加符合实际情况一些，对于Web来说也比分层更加的合理，MVC是典型的平行关系，没有说谁在上谁在下的关系，模型负责业务领域的事情，视图负责显示的事情，控制器把数据读取出来填充模型后把模型交给视图去处理。而各种验证什么的应该是在模型里处理了。在Web下稍微修改一下也还是比较自然的。很多人把MVC，多层混合起来用，在没搞清楚的情况下很容易就高的不伦不类，其实这个倒不重要，主要是效率和灵活性都降低了，那才是致命的问题。
Web应用程序执行的效率相关的因素很多，我们这里只来看看架构的改变对数据库操作的影响。
一种是多层的，每个业务对象都有自己的数据连接，然后造成了什么后果呢，在一个页面上依次打开关闭了N次数据库连接，而这些都是有消耗的，而Web并不是一个用户使用，加入一个页面上有10个连接，同时1000人访问就会在短时间内造成10000次数据库连接开闭的操作。还有一种是趋向单数据库连接（之前有位老兄在http://www.cnblogs.com/ayuan/archive/2007/03/24/686594.html 这篇POST里提过，不过貌似那位老兄把IIS的连接数限制概念搞错了，回头我再去提醒他）。其实这个也是不可取的，这样子会造成在多人访问的时候效率严重下降，因为始终只有一个Connection，在很多人请求的时候就会排起常常的挂起队列，得不偿失。其实我们仔细分析一下Web的工作模式的时候就会发现，首先，对于整个Web应用程序来说，是一个多线程环境，每个Session都有一个工作线程去Handle，每个线程都是隔离的，只有Application是线程间的公共区（所以就算是ASP都对Application提供了Lock和unlock机制，why？线程安全那），但是我们的代码除了静态的部分都是针对每个Session的，所以就这点来说，我们的程序可以看作是单线程的（除开Application和静态相关的代码）。那么其实我们针对每个Session之需要有一个Connection就能达到最优化Connection资源的目的，但是很多时候这样子会牺牲整个站点的结构，而且还有个问题在这里，如果在Session里一直存个打开的连接的话，如果这个用户的Session不回收就无法关闭连接，这个时候就是说，50个用户就要占用50个连接，一般来说SqlServer的连接数是有限的，到时候就不是慢的问题了，再有用户进来就没连接可用了，所以我比较倾向于每个页面放一个Connection，在初始化页面的时候打开，在执行页面结束的时候关闭，这个样子基本上就能达到效率的最优化了，至于业务逻辑我倾向于平行化，成为一系列逻辑的Helper类，里面只处理领域模型（MVC的M，实体类or DataSet），数据操作还是在Controler里，要换数据库怎么办？现在DAAB3.1还有N多的ORM都是支持多数据库的，这里就不用操心了。
继续给自己的组件打广告：
http://www.cnblogs.com/Alexander-Lee/archive/2007/03/30/694049.html 带缓存的哦，巴适得很哦
说道3层架构，MVC其实是因为看到某男给我看他的概要设计书引出来的，因为此君很能够代表很多的刚入门的开发者，他所经历的误区，可能很多开发者都会经历（也包括我自己，当年干过很多傻事）。从历史沿革上来说，MVC和分层设计是没有交集的，很多时候很多人会觉得这样也好，那样也好，于是就把两个概念混淆起来，于是某君的概要设计书就写成这样子：
......本系统是典型的3层架构设计，采用MVC模式......
这里不是说3层不好或者是MVC不好，不过起码需要先搞清楚何为3层，何为MVC才能说两者能不能结合起来或者怎么结合起来，不过在这个ORM（其实ORM也是个概念而已，不管你是代码生成器，组件还是自己动手写）横行的年代，3层的意义已经被淡化了。我们首先来看看3层架构的概念是怎么回事。一般意义上的3层就是表现层，业务逻辑层，数据操作层。没层之间是一种垂直的关系，换言之可以很直观的表现在很厚的调用栈上。其实是从网络分层的概念上借用来的。在网络每个层次都是一个协议栈，上层协议和下层协议因为层次间的接口的稳定而存在一种弱耦合的情况，上层协议是不会关心底层协议是什么的。所以程序上的3层架构就是为了实现弱耦合而出现的，对于页面来说业务逻辑的实现是透明的，对于业务逻辑来说，数据操作的细节是透明的，然后可以分开让不同的程序员去实现。so，看起来是个不错的馅饼，不过面临的问题也很简单，长长的调用栈，效率的降低，和扩展的复杂，每次扩展功能我们都需要重新编译部署整个业务逻辑层的Dll，和Site，但是这时要看适用范围的，很多时候，网站的逻辑都是相当的简单的，读表，填充Grid完毕。这样子的逻辑都要在业务逻辑里跑一次，其实协议个方法出来里面却只有一行，或者几行代码，其实就是转发一下数据层的结果。老实说如果是做个新闻发布的系统的话，业务逻辑层几乎通篇都是转发的代码，结果当修改了数据库的时候还要多改几个地方，简直是没事找事啊。还有种情况就是大量使用存储过程，逻辑都在存储过程里去了，结果业务逻辑层武功尽废，彻底沦为一个传声筒。有人说可以在这里验证数据阿，看来也就这点事情了，犯得着写一层膜嘛，是男的都知道多层膜不爽，那你为什么还要用？
再来看MVC，虽然上次炮轰过MVC（MVP），不过相对千层饼来说，MVC还是要可爱得多。起码更加符合实际情况一些，对于Web来说也比分层更加的合理，MVC是典型的平行关系，没有说谁在上谁在下的关系，模型负责业务领域的事情，视图负责显示的事情，控制器把数据读取出来填充模型后把模型交给视图去处理。而各种验证什么的应该是在模型里处理了。在Web下稍微修改一下也还是比较自然的。很多人把MVC，多层混合起来用，在没搞清楚的情况下很容易就高的不伦不类，其实这个倒不重要，主要是效率和灵活性都降低了，那才是致命的问题。
Web应用程序执行的效率相关的因素很多，我们这里只来看看架构的改变对数据库操作的影响。
一种是多层的，每个业务对象都有自己的数据连接，然后造成了什么后果呢，在一个页面上依次打开关闭了N次数据库连接，而这些都是有消耗的，而Web并不是一个用户使用，加入一个页面上有10个连接，同时1000人访问就会在短时间内造成10000次数据库连接开闭的操作。还有一种是趋向单数据库连接（之前有位老兄在http://www.cnblogs.com/ayuan/archive/2007/03/24/686594.html 这篇POST里提过，不过貌似那位老兄把IIS的连接数限制概念搞错了，回头我再去提醒他）。其实这个也是不可取的，这样子会造成在多人访问的时候效率严重下降，因为始终只有一个Connection，在很多人请求的时候就会排起常常的挂起队列，得不偿失。其实我们仔细分析一下Web的工作模式的时候就会发现，首先，对于整个Web应用程序来说，是一个多线程环境，每个Session都有一个工作线程去Handle，每个线程都是隔离的，只有Application是线程间的公共区（所以就算是ASP都对Application提供了Lock和unlock机制，why？线程安全那），但是我们的代码除了静态的部分都是针对每个Session的，所以就这点来说，我们的程序可以看作是单线程的（除开Application和静态相关的代码）。那么其实我们针对每个Session之需要有一个Connection就能达到最优化Connection资源的目的，但是很多时候这样子会牺牲整个站点的结构，而且还有个问题在这里，如果在Session里一直存个打开的连接的话，如果这个用户的Session不回收就无法关闭连接，这个时候就是说，50个用户就要占用50个连接，一般来说SqlServer的连接数是有限的，到时候就不是慢的问题了，再有用户进来就没连接可用了，所以我比较倾向于每个页面放一个Connection，在初始化页面的时候打开，在执行页面结束的时候关闭，这个样子基本上就能达到效率的最优化了，至于业务逻辑我倾向于平行化，成为一系列逻辑的Helper类，里面只处理领域模型（MVC的M，实体类or DataSet），数据操作还是在Controler里，要换数据库怎么办？现在DAAB3.1还有N多的ORM都是支持多数据库的，这里就不用操心了。
继续给自己的组件打广告：
http://www.cnblogs.com/Alexander-Lee/archive/2007/03/30/694049.html 带缓存的哦，巴适得很哦
