对BS开发技术发展的一点理解（微软体系）

在我的软件从业工作中，真正写BS架构的程序比较少，大部分时间都是写桌面程序，但对BS的了解和介入还是比较早，我在学校读书的时候就做过网页，不过那个时候主要以静态网页为主，动态网页，特别是与数据库结合的动态网页才刚刚出现。中间也做过几个BS的程序，但基本都是玩的性质，从去年开始才真正进入BS商务应用开发，通过大半年的实践，获得了不少认识，总结一下，也希望对各位朋友有所帮助。

BS模式发展到现在已经非常丰富，但BS最初的本质，从系统布局架构上来讲是终端模式，浏览器仅负责交互，并不负责计算（逻辑处理），浏览器的地位就是一个终端，还不能叫做客户端，大部分处理逻辑处理都在Web服务器完成。由于开始的时候基本都是静态网页，主要用于信息的发布，基本是一种单向的应用，这个时候的BS（浏览器服务器模式）是实至名归的。这是BS架构的第一个阶段。由于当时BS模式的定位，BS具有两个最明晰的特征：无连接，无状态。对于BS的应用来讲，采用无连接网络协议，至少就我的理解来讲是非常明智的。而无状态管理，则多多少少是个弊病，到现在为止也是这样。这是HTML时代。

但随着发展，静态网页很快就不能满足需要了，因此出现了动态网页，这里的动态有三个方面，一是交互，二是动画，三是数据。由于交互的需要，改变了BS的单向信息发布的定位，这算是一个比较大的进步，加上在服务器端对数据管理的引入（与文件系统，数据库系统结合）使得商务应用的开发成为可能。而动画的出现也使得页面呈现变得更加丰富。这个时候的BS还是以信息发布为主，但由于交互的出现，以及浏览器的功能增强，部分计算功能已经转移到浏览器进行，B就变成了客户端，因为逻辑处理有限，因此叫瘦客户端。这个时候虽然出现了Cookie和服务器状态管理，但对状态管理的支持还是十分有限。BS最初的定位和应用的特殊性，HTTP协议中并没有提供对状态管理的基本支持，现在最基本的服务器端状态管理的Session，其实也是一个变通的手法，我们来看看它是怎么变通实现的：

首先当新开一个浏览器窗口时，在向服务器端发生请求时，会产生一个随机的Session标识串，这个信息要么包含在Cookie中发送给服务器,要么包含在请求的URL中(客户端禁用Cookie的情况下),当然这个信息也会存在于浏览器中，一般情况下，服务器端不会保存这个SessionID,但一旦服务器程序在保存了Session变量，服务器就会将它加入到服务器的Session管理中，这样客户端和服务器就以这个session标识建立了一种“连接”(这部分只是我根据实践推理而得，具体的实现细节我不清楚，有谁知道，请不吝赐教），对于IE6而言，由这个浏览窗口打开的窗口，都自动拥有这个SessionID.而独立打开的新窗口，则是新的sessionid.（对于其它浏览器的机制，应该类似，但页签式浏览器，新开页签，是否新建Sessionid，我没有测试） 这里提醒一下各位TX，这种会话是建立在浏览器和服务器端的，不是建立在用户上的，因此在做系统的时候，大家一定要特别小心，要防止一个用户登录后，没有注销或者注销时程序没有清Session，而下一个用户从当前浏览器窗口重新登录，那么这个用户将可以看到前一个用户的Session。这是一个潜在的安全隐患。

由于Session管理的数据量有限，而且过多的利用Session也会使得服务器负担很重，因此这中情况下，在BS上开发商务应用系统受限很多，只能做一些简单的应用。这个时候的BS应用系统无论是体验还是性能都很难跟传统的CS程序相媲美(特别是三层CS、智能客户端以及WebService的出现),但毕竟BS易于部署和在internet上的优势地位，突破是必须的。

（由于我对Java的BS开发架构不是很了解，这里主要以DotNet为主，有不妥之处请原谅）

Dotnet的出现，使得BS在业务系统应用方面有了长足的进步，DotNet的Web框架结构巧妙的解决了服务器状态的管理，之所以我觉得很巧妙，主要有三点，一是利用了现有的技术体系（协议还是哪些协议，浏览器也不需要更改），二是服务器端的状态数据存放并没有大幅度的成长，三是程序员可以像开发CS程序那样。当然代价也会有的，比如服务器开销，网络开销，安全等，但还是瑕不掩瑜。解决这个问题的就是ViewState。其实从技术和原理上来讲，ViewState的实现并不复杂，思路就是将页面需要缓存的数据保存到页面Form的隐含域中，然后在下次提交上来时再传回来。这里的技术关键点我觉得主要是：反射机制，类的序列化以及控件树。当然，这些都是框架已经做好了，对于程序员而言都是透明的。如果能理解中间的机制，对编程，特别是页面控件动态生成处理还是有很大帮助的，比如，服务器动态产生的控件，利用this无法访问,但用其控件id和request.form可以获得回传的值。但如果动态控件仅在Get模式下产生，则在回发时这个控件不再存在，但值可以利用前面的方法提取，再次回写后的回发则无法取值和访问控件。

在Dotnet下利用现有的技术开发CS模式下的那种复杂交互界面也不再是一件难以企及的事情。至于Aspx技术的出现，不能算是一种传统的BS开发，它已经可以算是一种富客户端开发，只是利用了浏览器作为客户端载体。如果Aspx大量运用，且将服务器端很多逻辑移到客户端处理，这实际上就是CS三层模式。对于一般应用我觉得还可以，但对于大的系统开发，大规模应用，我觉得不利，我比较赞同有些网友的意见，Aspx开发使得服务器端的开发变成了函数式开发，但作为传统开发的一种补充，以提高用户体验还是很好的。如果你一定要大规模利用Aspx技术，我觉得你还不如做三层CS结构的智能客户端程序（桌面客户端+WebService+数据库）。

总的来讲，我觉得BS跟CS一直在相互取长补短，界限也越来越模糊。在大型系统中，同时使用也越来越多。（当然现在的BS本质上也是一种CS，但这是广义上的CS).单纯的争论哪个好哪个差没什么实际意义，按需而选，综合利用才是关键。