回 帖 发 新 帖 刷新版面

主题:[原创]两年开发ASP程序心得体会

各位同仁:
    大家好!ASP众所周知是最早的应用于动态服务器端页面的处理技术.以至在早期就得到了大量的应用.相比现在各种语言盛行,源代码公开的年代,可能昔日的光环已有些褪色.面向对象的发展包括java,php5等在内也出现在web应用领域.微软又主推.net,可能ASP现在看上去是很微不足道的了.以至有些人说一些无用论等等.本人对此大为不满,但趋势如此也不是你我能左右的.
    两年来,本人用它开发程序也有很多了,大小项目都有.谈不上什么高深只是不断学习罢了.虽然java方面也还可以,可本着对Asp的深深眷恋,以至再做一些小项目时还是会用到它.虽然简单的servlet也可以实现,但是还是觉得ASP有一种很亲切的感觉.所以在这主要向大家说一下自己的心得体会.本人水平有限,写得不好,还请各位高手多多指教!
    基础略过.网上资源丰富.主要说一下关于ASP程序怎样才能更好的复用和维护.通过Struts和Spring我了解了MVC多层架构的应用,以及在大项目中带来的种种好处.现就其java思想应用于ASP.经过一段时间的测试和改进可以说大体上完成了所需的任务。而且也很好的利用了ASP的一些特性.
    以下是自己写的一个简单的ASP小框架.当然离真正框架还远远不够,但用它也很灵活.它只实现了Struts的部分方案.如下:

    1.当客户端请求时.(此时没有采用Struts的统一入口主控处理方案)由于ASP本身的特性,要实现此功能需要一个IISREWRITE组件来帮助实现,这样程序就与组件结合紧密不利用程序的扩展和移植.所以此处还是采用快捷的ASP传统处理方案由一个对应的后台处理文件进行处理.当然也可以多个请求同时映射到同一处理文件其中用Action进行分别处理即可.当然此方案有待更新中...
  
    2.针对客户端提交的数据包括GET和POST由相应的ActionForm处理.由于ASP本身的特性(此时没有采用Struts的ActionForm来处理)采用一个自定义类HashTable来进行处理它是对系统Dictionary对象的封装.这样可以将提交数据用此类来进行存储方便程序使用,如果需要传递给其它页面或者视图可以导出到Dictionary即可.(由于ASP不支持自定义类的传递,而系统对象可以.)
  
    3.以下实现则是自己模拟Struts的程序来进行处理的.如下:
一个处理视图上面的包含文件可以统一为这样的结构,当然可以根据需要添加,但是主结构不变.
  
  <!--#include file="include/checkSession.asp"-->
  检查验证用户信息的文件,用于检查用户是否合法,也可以防止用户从本地提交等.
也可以想做一些通过功能都可以.对于一个会话应用程序来说是必须的.
  
  <!--#include file="include/conn.asp"-->
  数据库连接文件用于在后台进行读取操作,独立出来是由于可以随进更换和调整应用的数据库.

  <!--#include file="include/AdoTemplate.asp"-->
  上面是一个自定义的数据通用访问类,用于简化数据库操作,也是对常用操作的一种封装.有些功能有待扩展.放在这里是必须的.其中就包含了HashTable.asp这个类。这个访问类其实是模访了Spring中的JdbcTemplate类.HashTable.asp就是对客户端提交数据封装类.
 
  <!--#include file="include/RequestProcessor.asp"-->
  模拟Struts的RequestProcessor类的实现只提供了一个抽象主方法process(),其内部方法实现由下面具体实现文件来完成。调用时只调用这个主函数。当然针对不同情况可以进行不同考虑,如特别情况下此函数不返回值给调用端而直接进行跳转和发送也可以.
在此文件中增加了一些步骤过程的默认实现,由于ASP本身会将以后也就是子类的方法实现进行覆盖的特性,所以采用此方案,方便不同处理程序进行扩展.就相当于定义一些可扩展方法.
  
  <!--#include file="include/workFunc.asp"-->
  process()的实现文件.此处定义了必须的实现方法。也可以定义一些扩展方法实现.
业务逻辑在此处实现,包括与后台数据访问也利用AdoTemplate来完成,便于集中管理.在此处最好是将业务逻辑层单独划分,封装该模块下所有数据访问。当然可根据需要而定。(此处没有采用Struts中独立一个数据访问层用于业务逻辑代理组件进行调用.)兼顾了ASP的简单快捷. 还有它定义了ActionForm也就是参数提取对象.便于集中管理和维护.
  
  4.调用视图页可以这样写: 
    dim datalist
    datalist=process() 然后应用就可以了.至于返回值是什么是由具体程序需要来实现的.灵活性很大,它可以封装视图用的数据,也可以返回一个布尔值,也可以不返回任何值.不返回值时只需直接调用 process 即可.对Struts的一个灵活实现.直接跨越了ActionForward.

  5.以上是在总结Struts的基础上并从实际情况出发处处以ASP执行环境特性为核心,来完成ASP的实现交互.

下面是核心的RequestProcessor.asp中源代码并加了注释:

'functionName: process
'parameters: null
'returnValue:processAction的返回类型
'description:通用抽象主执行方法.并加入了方法前后before,after切入方法,来Spring中Aop思想.
'extend:false 不可扩展方法
Function process()
on error resume next
processBeforeProcess
processActionForm
if not processValidate() then 
     processException
     exit function
end if
process=processAction()
if Err.Number > 0 then
     processExceptionForDefault
end if
processAfterProcess
End Function


'subName: processBeforeProcess
'parameters: null
'returnValue:null
'description:执行具体过程前的预处理函数
'extend:true 可扩展方法
Sub processBeforeProcess()
End Sub

'subName: processAfterProcess
'parameters: null
'returnValue:null
'description:执行具体过程后的预处理函数
'extend:true 可扩展方法
Sub processAfterProcess()
End Sub

'subName: processActionForm
'parameters: null
'returnValue:null
'description:创建一个参数集合并读取客户端数据
'extend:true 可扩展方法
Sub processActionForm()
End Sub

'functionName: processValidate
'parameters: null 可以操作全局参数集合parameters
'returnValue: boolean true or false
'description:验证参数的合法性并根据结果进行处理.
'extend:true 可扩展方法
Function processValidate()
processValidate=true'默认实现
End Function

'functionName: processAction()
'parameters: null,可以调用parameters,errors
'returnValue:任何类型.通常指数组和单个类型
'description:主要执行过程相当于Action.execute().
'extend:true 可扩展方法
Function processAction()
processAction="" '默认实现
End Function

'subName: processException
'parameters: null 可以操作全局错误集合errors
'returnValue: null
'description:对异常进行处理并抛出按程序进行处理.
'extend:true 可扩展方法
Sub processException()
processExceptionForDefault
End Sub

'subName: processExceptionForDefault
'parameters:  null
'returnValue: null
'description:对全局错误进行默认处理
'extend:false 不可扩展方法
Sub processExceptionForDefault()
response.write "<h1><font color=red>程序运行出现异常...</font></h1>"
response.end
End Sub

    以上是部分源代码。它描述了一个客户端请求发出后服务器的处理过程. 具体的实现源代码例子可以参看压缩包.   
    采用此小框架组合写出后的程序在视图显示View端就看不到太多的ASP代码了,方便了视图的开发和维护.同时对结构进行很好的整理,方便后台人员进行维护。本人只是在此抛砖引玉,雕虫小技.希望能得到高手们的指点.在此主要是强调一下设计思路,一种结构.大家可以在此基础上自由发挥.
    总之ASP宗旨:简单,快捷,灵活,强大.时时都要以此为中心进行改进和拓展。
    愿ASP的天空更蓝,朋友们能更好地使用并了解它.
                                              shiwei2006 2007-10-30 17:30 
                                     (希望能得到版主鉴定,申请置顶共同学习^o^)

回复列表 (共5个回复)

沙发

ASP还是让他简单的就好。没必要用MVC把ASP变得复杂化。

“强调简单直接·反对过分灵活” —— 我的ASP开发宗旨

关于“简单直接”的说明:基本上,我在地址栏上见到的ASP文件名,就可以在此文件中找到我想要的代码,并且包含文件的深度不超过两层。

下面举例说明“简单直接”的开发宗旨:

以简陋的“文章添加”为例,暂时先不考虑表单验证等问题。
首先,设计一个“文章添加”的表单HTML页面,代码如下:
文件名: Article.Add.htm



<html>
<head>
<title>文章添加</title>
</head>
<body>
<form action="Article.Add.asp" method="post">
 <input name="title" type="text" >
 <textarea name="content" cols="" rows=""></textarea>
 <input name="" type="submit" value="添加" >
</form>
</body>
</html>


那么,上面这个页面提交后就交给一个Article.Add.asp文件来将的数据保存到数据库;
如果是一个ASP菜鸟的代码可能如下:
文件名: Article.Add.asp


<!--#INCLUDE FILE="conn.asp"-->
<%
 Dim title
 Dim content
 title=Request.Form("title")
 content=Request.Form("content")

 SQL = "SELECT * FROM Article WHERE 1=0"
 Set rs=Server.CreateObject("ADODB.Recordset")
 rs.Open SQL,conn,1,3
 rs.AddNew
 rs("title")=title
 rs("content")=content
 rs.Update
 rs.Close
 Set rs = Nothing
%>


如果使用我的框架,其代码就如下:
文件名: Article.Add.asp



<!--#INCLUDE FILE="acp/acp.asp"-->
<!--#INCLUDE FILE="conn.asp"-->
<%
 db.Insert "Article"
 db.FS("")="title"
 db.FS("")="content"
 db.Exec ""
%>

由上可见,我的框架强调“简单直接”的开发宗旨!

板凳

我写这个东西就充分兼顾了ASP本身的特性,所以没有太多的进行全部模拟,只是将其主要应用提取了出来,有些做法可能欠考虑但是从一个整体上看它要说明的是一个结构,因为面对比较复杂的逻辑处理页面不是写一两个函数就能解决的,所以代码多的时候这样写更加容易维护和调试,一些日志调试类我都去了,正式时不用.也不可生要套用此种结构,可以更加灵活的运用,我强调的是一种解决问题的方法思路.况且在我做的项目中就应用到了它,只是在不断的改进它.
    楼上思路很直接简单这样很好很符合一些初学者的思路.但是函数和类不是这样用的,它和java不一样,如果只是为了类的写法而实现类,那执行效率还不如简单的函数调用来的快.函数也不是想当然的将任意的逻辑都加到一起执行,而是要从全局角度去思考和抽取出来的.写一些小的应用你可以随意写,但是到一些大的应用上你就体会出来了.

3 楼

从管理维护的角度来说,我觉得主要是如何用好“文件、目录、文档”来组织管理整个工程的开发过程。至于框架只是个有用的辅助而已。

4 楼


学习。。。

5 楼

3楼说得没错,一个工程对其做出很清晰文档,结构划分的确有利于管理和维护,包括前台视图部分和后台实现部分,以及一些整个工程的其它部分图片样式表脚本文件等等.但我不建议将视图处理和后台逻辑写在一起那样不利于维护尤其是视图或逻辑部分要改动的时候不利于各小组的开发.而应该尽量的抽取出来尽可能在视图部分不出现任何业务层逻辑以及数据访问层的代码。说白了就是避免太多的<%%>出现.所以采用上述方法后可以做到后台结构很清晰,当然也不是非要用它,也可以自己实现.可能自己习惯了不当之处请讨论.

我来回复

您尚未登录,请登录后再回复。点此登录或注册