用XML+XSLT+CSS+JQuery组建ASP.NET网站

前言

早在Web标准化风潮到来之前 ，我就考虑过XML+XSLT建站了，我以为这是一种非常优雅、 高效、低耦的方案，必将大行其道。

然而时至今日，使用这种方案建站的人依然寥寥无几，大家还都在抱着Web标准化不撒手，其实Web标准化只是 将表现（Css）分离了出来，而数据和结构仍然混杂在一起 ，它绝对不是我们最终的归宿，它只是一个过渡品。

XHtml标准的建立初衷，其实也就是为了向 XML过渡的，XML+XSLT+CSS才真正做到数据、结构、表现的完美分离，才是我们的终极目标。

诚然，XML+XSLT确实有其技术难度， 我想这是它难于普及的最大障碍所在，但我觉得随着时间的推移、观念的更新、工具的发展， 这仍旧是我们必会到达的一站。

方案简介

XML+XSLT+CSS的方案将数据、结构、表现进行 了分离，而依托JQuery我们又可以轻松地将交互也从中分离 出来，这样在客户端就达到了近乎完美的解耦。

[[2865]]

而在服务器端，我们只负责输入和输出：

输入部分使用WebService，主要用于 接收客户端提交的数据，以更新服务器数据。

输出部分即为XML，可以有两种实现方 案：

1. 动 态型。使用一个扩展名为.ashx处理程序负责输出 XML，只要通过此处理程序从数据库取出客户端需要的数据 ，并转换为XML文档输出即可。动态型的好处在于支持 Url参数查询及其他复杂查询处理。

2.静态型。放弃数据库，将所有用于呈现的数据都直接写为XML文件。静态型的好处当然就是服务器负荷极低了，在不提交数据的情况 下，服务器会比纯静态HTML网站还要轻松很多。

[[2866]]

优势

对比以往的各种开发方案，我总结出此方案具有以下优势：

1.更便于团队协作。充分解耦带来的就是细化分工及并行开发，以往的各 种开发方案中，总有许多地方界限模糊，致使前台与后台、程序员与设计师频繁磋商，延误开 发效率。

比如仅仅是一个XHTML文档， 设计师要在上面定义文档结构，以及ID、Class，前台程序员要在上面写客户端事件，后台程序员得把从数据库中取 得的数据插入到页面中的某处，三方的工作都受其牵制，这时XHTML就像是一个接口，三方共用着这一个接口。

而我们的这个方案中的情况是怎样的呢？后台程序员只管怎么跟 数据库打交道、怎么处理业务逻辑，客户端需要数据时，只要扔出个XML文档就可以了； 作为设计师，只要知道XML文档结构，就可以通过XSLT灵活地安排布局 ，即使需要大幅修改布局，也不需要劳烦后台程序员插手，简单的XSLT语法对于设计师不是什么大问题；前台程序员需要知道用户界面中有哪些交互 控件，为他们安排事件逻辑，并提交到后台的WebService中 去就可以了；这时XML、XSLT、WebService就像是三个接口，一方最多接 触其中的两个。

接口多了好，还是少了好？可以看看索爱手机的例子，索爱手机 大多是耳机、充电、数据传输都共用着一个接口，充电的时候不能插耳机听歌、插耳机听歌的 时候不能传数据、传数据的时候不能充电，而其他品牌的手机则大多是分别使用多个接口的， 哪个更方便不言自明吧。（当然，从安全角度来看的话，索爱的单接口却是更优秀的，此前曾 有新闻报道过某男用手机边听歌边充电被雷击致死的事故，那人在死前还大喊：“啊！我死啦 ！”-_-#，围观地址）

2.更节省服务器资源。带宽资源方面：此方案中，用户每次切换页面，所 需下载的都只是一个XML文档而已，其他XSLT、CSS、JS都只需下载一次，提交时也不需要表单回发，更不需要ViewState。处理器资源方面：客户端呈现完代码全由XSLT在客户端动态合成，服务器端的工作仅仅是处理业务逻辑和数据库交互，极其 轻松。此方案的资源消耗水平略高于Ajax方案，低于 MVC方案，相对于WebForm、MVP及传统脚本式的方案来说，节省的 资源非常可观。

3.更易于搜索引擎收录。首先就是此方案可以被搜索引擎收录，而 Ajax方案的弊端就在这里；其次，搜索引擎喜欢冗余少的网 站，这会一定程度上影响网站排名，而XML数据最为符合这 一要求；再者，网址较为友好，这是相对MVC而言的，具体 原因可参看我此前发表的一篇文章 。

4.更容易在其他客户端中使用。这一点Ajax方案也同样优秀，MVP方案实现起来有些困 难，其他的方案都难以实现。

弊端

没有完美的事物，此方案弊端如下：

1. 更 高的技术要求。显然相比以往的方案，此方案需要开发者掌握更多知识，并组合应用。

2.更高的客户端负荷。XSLT加重了客 户端的处理压力，虽然我们大都觉得客户端的运算资源负荷是一个可以忽视的问题，从而将尽 可能多的运算放到客户端，但并不是所有客户都使用中高端的机器，尤其是对一些上网本用户 而言，JS已经让他们头疼了。

3.更差的兼容性。HTML、 JS、CSS在各个浏览器上 本就有些兼容性问题，现在XSLT又掺合进来，开发者面临的 问题更为严峻。并且对于移动客户端、盲人阅读器及其他非常规客户端而言，XSLT是否会被解析都是个疑问。

#p#

范例

现在演示一个网站范例。

首先建立一个数据库，这里使用的Accesee 2000-2003数据库，命名为Database.mdb，在其中建 立User表：

输入一些数据，用于测试显示：

将其导入网站项目中的App_Data目录 。

添加一个ashx文件，名为 Default.ashx：

输入以下代码：

   
    
<%@ WebHandler Language="C#" Class="Default" %>

using System;
using System.Web;
using System.Data.OleDb;
using System.Data;
using System.Xml;

public class Default : IHttpHandler
{

public void ProcessRequest(HttpContext context)
{
OleDbConnection c = new OleDbConnection (string.Format(@"Provider=Microsoft.Jet.OLEDB.4.0;Data Source=""{0}"";Persist Security Info=True", HttpContext.Current.Server.MapPath(@"~\App_Data\Database.mdb")));
var ds = new DataSet ();
c.Open();
//获取Url 中的max参数
var max = 0;
Int32.TryParse(HttpContext.Current.Request.QueryString["max"],out max);
//读取数据
new OleDbDataAdapter(string.Format("select{0} * from [User]", max > 0 ? " top " + max : string.Empty), c).Fill (ds);
c.Close();
//建立XML 文档
var xml = new XmlDocument ();
xml.LoadXml(ds.GetXml ());
//添加文档声明
xml.InsertBefore(xml.CreateXmlDeclaration("1.0", "UTF-8", null), xml.DocumentElement);
//添加xslt 声明
var xsl = xml.CreateProcessingInstruction("xml- stylesheet", @"type=""text/xsl"" href=""Default.xslt""");
xml.InsertBefore(xsl, xml.DocumentElement);
//输出
context.Response.ContentType = "application/xml";
context.Response.Write(xml.InnerXml);
}

public bool IsReusable
{
get
{
return false;
}
}

}
再添加一个XSLT文件，命名为 Default.xslt，输入以下代码：
 xml version="1.0" encoding="utf-8"?>

xmlns:msxsl="urn:schemas-microsoft- com:xslt" exclude-result-prefixes="msxsl"
>