2005年8月4日星期四

我不懂 ASP.NET

这真是个严重的问题,而且我越来越发觉其严重性。要懂得ASP.NET语法非常容易,要学习MS提供给你那种RAD开发方法也很容易,但是你无法做大东西,或者说你只能够按照ASP的老路去做大东西,并不能“享受”ASP.NET带来的“优越性”。

要做到“优秀”的Web应用,最重要的就是“分离”(“正交设计”就是老生常谈的问题了)。首先就是Web Standards里面鼓催的内容(Content)与布局(Layout)分离,暂且不说“终极目标”是HTML只容纳内容CSS只容纳布局对于现在的浏览器来说有多么过分(特别是你要兼容多个浏览器的话),我们就现把这几下来作为“第一分离”。然后,就是ASP.NET里面3层式设计,对于ASP.NET来说就应该划分为“编译部分”和“不编译/动态编译部分”,这个算是“第二分层”。这样2*2就已经组合出4个部分,在编写代码的时候某一段代码应该属于哪个部分,一个部分如何引用另一个部分,这就是个非常头痛的问题。

要说明这个事情,我们需要从以前的做法说起。

在“古老”的时代,我们存在一些“古老的假设”。首先,当时没有很明确的布局、内容、行为分离理论,其次当时假设所有这些都属于不编译部分,编译部分都是相对固定的逻辑层和数据层代码(相对小型的系统当然就什么都不编译,因为ASP引用COM组件还是要一定的权限的)。那个时候HTML是个大杂烩,我们控制了HTML就控制了天下,而不编译部分就是控制天下的最重要部分,你写的ASP代码已经完全决定了用户看到的布局、内容、行为。不过即使在不编译代码中,我们也分离出了相对固定代码,这就是我们的include技术欣欣向荣的原因了。一个良好设计的ASP系统里面有良好的include体系,固定的代码都是通过include重复使用。如果你对于为什么要include有疑问的话,那就真应该看看《程序员修炼之道》里面的DRY(Don't Repeat Yourself)规则,任何事情在程序代码中都应该仅仅被描述一次,一旦被两次描述那么你就必须保持两边的同步更新了,一旦出现同步失败你的代码就可能出现不可预料的问题。

然后ASP.NET出现了,它带来了“立体化”的Web模型,最重要的是它提出了Code-Behind和WebControl这两种编译代码的存在方式。Code-Behind代码和WebControl代码都是必须先显式编译后使用的(其实不编译的Code-Behind是可以的,就是<%@Page Src=""%>方式,但是这不是我现在要讨论的东西)。Code-Behind的页面或者UserControl实际上是被编译了两次的,第一次是编译后台代码,生成的类就是<%@Page Inherit=""%>中Inherit指向的Page/UserControl派生类,第二次是在页面被访问的时候即时编译出来的Page/UserControl派生类的派生类,这其中第一次编译就属于上面所说的“编译部分”。至于WebControl则是必须先编译再用<%@Register%>指令引用的,整个都属于“编译部分”。为什么MS要在.NET Framework里面设置编译部分?我想它是相信有一些UI部分的逻辑能够在很高的层次存在一定的共性,这些共性就应该被编译。例如WebControl中最突出的DataGrid,就是一种数据载体需要列表、需要分页甚至对于有些数据字段需要特殊显示(例如一个“真/假”字段需要显示为一个CheckBox是否被选中)的共性。我们也可以归纳自己网站中的一些显示共性的逻辑,自己制作WebControl(甚至TemplateControl或者Control,HtmlControl当然也行不过意义不大),或者继承现有的各种Control(继承HtmlControl是有意义的)。至于Page的后台代码编译有什么意思,这个我就不清楚了。诚然,你可以把Page看作一种Control,但是这种编译是不可复用的,编译来干什么呢?我唯一的解释就是这仅仅属于一种RAD(Rapid
Application Development:快速应用程序开发)开发方式,程序员可以随便拖放控件让后写后台代码并且编译,美工之后再来处理aspx页面,只要美工不毁坏控件tag那么他可以任意添加新tag或者移动现有tag。

然而这种编译方式并没有解决我们原来用include带来的各种问题(至少要考虑什么颗粒度的代码应该include,什么颗粒度的就让它在各处重复),我们变成了考虑什么层次的UI逻辑应该“统一起来”把它们变成编译好的WebControl。关于这个事情我暂时还在摸索之中,我喜欢的做法是把每个页面的核心固定内容封装成为WebControl(其实我早在TextGem的时候,就已经是每个页面的主要内容封装到一个function里面),例如一个登录表单的两个TextBox和一个Button就封装起来。同时一些公共元素例如Header这种以前习惯include的东西有时候也封装为WebControl(不过我现在更加喜欢封装为ascx,因为这部分应该属于容易编辑的UI代码,不应该被编译死)。封装为WebControl的东西大多数是样式无关(仅使用全局样式)的,样式有关的或者我考虑到以后要修改HTML的东西我都仅仅封装为ascx,或者封装为TemplateControl以后必要时能够通过改Template部分修改输出的HTML。这就是我们现在能够做到的事情。

至于未来,ASP.NET 2.0会为我们提供WebPart和MasterPage等优秀功能。WebPart能够让我们轻松实现Sharepoint才拥有的门户页面效果,每一个信息栏都是一个WebPart,能够被所以拖动和缩放。至于MasterPage则能够制作一个固定的模板页,制定其中几个地方为ContentContainer,然后在aspx里面引用这个MasterPage并且用同ID的Content控件对应填充ContentContainer(Content控件里面可以放置任何东西),这对于使用少数模板覆盖全站的设计非常有用。不过其实我非常需要一样东西,暂时看起来没有的。我希望有一种松散型复合控件,例如我订一个登录表单控件,派生自HtmlForm,然后必须包含用户名和密码两个输入框(HtmlInputText的派生类,或者是实例)以及一个提交按钮,然后我可以按任意方式布局它们,例如:

<LoginForm:Form runat="server">
  <span class="inputSubject">UserName:</span>
  <LoginForm:UserName class="inputText" runat="server" />
  <br />
  <span class="inputSubject">Password:</span>
  <LoginForm:Password class="inputText" runat="server" />
  <br />
  <LoginForm:Submit class="inputButton" runat="server" />
</LoginForm:Form>

这会是一种很好的控件结构,因为我定义了一个<LoginForm:Form>必须包含<LoginForm:UserName>、<LoginForm:Password>、<LoginForm:Submit>各一个,然后选择上述布局或者Table布局或者其他布局方式就在aspx中定义,那就有效实现了布局代码不编译逻辑代码编译的分离。布局代码方面,既然是融入在aspx文件中,那么我不喜欢的话可以随意改,可以放心地交给美工改,至于逻辑代码则是编译好的我不用担心以后会被自己不小心改动了。或许这种设计与Page的Code-Behind编译有什么不同,关键就在于它强制规定了什么包含什么,包含多少个,而且这些被包含的控件的一些属性的默认值可能也在编译代码中,你看我上面的代码就没有指定<LoginForm:Submit>的value为“提交”或者“登录”,我的意思就是在编译代码中这个已经指定好了,这个指定好可能是指代码中为属性指定了默认值,甚至可能是那已经是一个派生类该派生类已经被指定了属性默认值。

没有评论:

发表评论