关于B/S中代码分离的个人观点

　　“代码分离”似乎并非一个明确的概念。在B/S领域提到的“代码分离”，大部分情况是指美工和程序的分离。多么美好的愿望！先进的人们都在为更好地实现它而努力。可是，就算是现在最能代表B/S潮流的JSP和ASP.net，在代码分离方面仍然存有许多悬念。本文旨在阐述我个人对代码分离的看法，望高手批评指正，同时初学者能从中获益。

　　首先，我们要明确提出代码分离的原因。
　　通俗地说，“术业有专攻”，我们最好还是不要要求程序人员能做出美观的网页来，也不要指望美工人员能顺利操控已经和程序融合在一起的页面，所以我们提出代码分离来优化B/S开发和维护，这就是最朴素的原因。当你把“代码分离”提高到更高的层次上来，就会发现它会给我们带来更多的好处，但这是后话了。

　　然后，我们必须认识到代码分离的两个事实。

　　事实一：代码分离并非技术特性，而是技术实现。
　　你会发现，ASP.net的特性列表上会有“Code-Behind”，2.0可能还有“Code-Beside”，但不会有“代码分离”。你完全可以不进行代码分离，写出逻辑和呈现混杂的ASP.net代码来。也就是说，有一些现行的代码分离实现机制供你采用，但是否采用这些机制来实现代码分离仍然是由你自己决定的。从另外一个角度，你也可以自己制定代码分离的实现机制，比如ASP本身并没有提供代码分离机制，但仍然有一些高手编写了自己的ASP模板来实现代码分离。这就充分说明了，代码分离是技术实现的事实。

　　事实二：代码分离的概念不是建立在绝对意义上的，它只能用程度来衡量，并且其实现中必然存在融合点。
　　没有绝对意义上的代码分离，因为代码分离的实现必然存在融合点。你会发现，ASP.net中会有Inherit、控件标签会有runat="server"、后端代码中会有lblHint.Text="<span style='color: red'>Error Occurs!</span>"等等，这些都是融合点，它们中有些是可以避免的，而有些是必须的。所以，代码分离只能用程度来衡量，实现机制，无论是现行的还是自定义的，都只提供了一个分离程度的上限，但实际的分离程度仍然要看程序作者的水平和意愿。

　　接着说说代码分离的实现的两个基本方向：其一是以模板和自定义标签为代表的前端主导方向，其二是以服务器控件和页面模型抽象为代表的后端主导方向。

　　前端主导方向，比如自定义ASP模板，其机理大概就是在前端页面上有意识地引入一些非标准或者非必须的页面元素，然后将页面代码传入后端的解释程序进行分析并把那些有意识引入的页面元素替换为相应的后端逻辑代码段，分析替换结束后运行并将最后结果返回给客户端浏览器。这样说可能有些生涩，举个例子好了：
　　在前端页面上，我们假如要输出Northwind数据库中表Orders中最新的一条记录，那么我们假设可以引入这样一段代码：
　　<!--DataBase="NorthWind" Table="Orders" Order="OrderDate" Rows="1"-->
　　然后，后端的解释程序接收到这些代码，用某种方法，比如正则表达式匹配搜索，按意义找出我们指定的值，然后构造连接字符串、T-SQL语句，结合ADO完成输出语句。这些输出语句将替换掉上面那条注释，在WEB服务器上执行后返回相应地结果给客户端！
　　现行的TagLib、PHP Template等估计大概也是这个机理，不同之处在于后台的解释程序埋藏的深浅不同，或者说封装程度高低不同而已。如果说你的解释程序，或者被叫做解释引擎，埋藏得够深，比如达到ISAPI过滤器和处理器级别，而不是ASP中用VBS写的分析函数，那么你的技术就还是挺值得炫耀的，呵呵。

　　后端主导方向，当然就是以ASP.net为典型的情况了。这里就不用多说了！不过，要实现这个方向的自定义实现机制，好像不容易。

　　比较看来，前端主导方向的方案，重用性要强一些，但灵活性远不如后端主导方向。其原因在于前端主导方向要实现页面级的事件逻辑比较困难，所以往往不考虑页面事件逻辑，这样却保证了使用起来更容易和独立，所以重用性强，但它却难以满足复杂逻辑的应用要求；而后端主导方向的实现方案，由于独立性被削弱，所以使用起来相对困难，但一旦掌握透彻，威力难以限量！

　　刚才提到了TagLib和PHP Template，就不得不说说页面生成技术，比如XML+XSLT以及我最近才听说的fastm等！你仔细一想就会发现，它们也都服务于代码分离，虽然取得的效果不尽相同。特别是XML+XSLT，它更是将本文中的“代码分离”拓展到数据和呈现分离的范畴。现今网站标准化的声音越来越大，数据、呈现、行为的分离也是一个非常好的方向。看起来，似乎B/S开发中各职能因素会更趋于独立，很早就流行的3层甚至多层构架，实际上主要是服务器端各职能要素的独立；现在独立的革命又在客户端蔓延开了！不过，无论如何独立，都无法逃脱融合的命运，否则独立就失去了意义。补充一下，这里提到的“独立”和“分离”意思相近。

　　说到这里，细心的朋友可能会提出这样的问题：在设计中，我们是否应该更高程度的代码分离呢？
　　我个人的观点是，不一定，坚持具体问题具体分析才是最合适的。前面也说了，代码分离的程度要看程序作者的水平和意愿。一味追求更高程度代码分离，虽然可能会给程序带来许多好处，但就开发来说引入的不利因素可能更多一些，比如分离程度过高带来的开发成本上升、水平跟不上带来的开发难度提高等，很可能得不偿失。君不见，愿意按标准化设计网站的职业开发者比例不大，很大程度上也是这个原因！退一步，按标准化设计网站的人，大部分采用XHTML+CSS而非XML+CSS，也是基于以上原因的过渡。但过渡总归是过渡，技术在进步，社会也要进步！把握趋势、跟上潮流仍然是非常必要的！

　　对于代码分离为我们带来的好处，我这里并不打算列举了，相信大家也都耳熟能详了！

　　最后，我想说三点：
　　一、技术是无止境的，就好像编程无止境一样，永远不要觉得自己已经完全掌握了某技术！把眼光放宽一点，你就会发现自己的渺小。换个角度，意识到自己的渺小就说明自己还有发展空间——关键在于你是否意识到自己渺小了？
　　二、个人以为，作为B/S开发中的程序员，与其研究如何提高代码分离程度，减小自己对页面呈现细节的依赖，还不如花时间好好去和美工人员沟通磨合！你会发现，这样做能取得的效果更好，而且往往还有意想不到的收获——是什么？你试试就知道了。
　　三、我是一个小菜鸟，技术不好（不懈努力中），但想得很多。我认为如果自己能先有所领悟，再去学习具体技术，应该会事半功倍！怕就怕自己领悟错了。所以，我大胆写出此文，希望各位高人耐心看完以后能批评指正，我定当虚心受教！也只有这样，更多初学者才能从中受益而非受害。拜托各位了！