仓酷云

 找回密码
 立即注册
搜索
热搜: 活动 交友 discuz
查看: 490|回复: 7
打印 上一主题 下一主题

[学习教程] ASP网站制作之甚么才是进步ASP功能的最好挑选(续)

[复制链接]
柔情似水 该用户已被删除
跳转到指定楼层
楼主
发表于 2015-1-16 22:45:56 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
缺点:正版成本价格贵(盗版就不说了)、不够安全,大多数服务器用windows系统,没有linux安全功能
  在本文的第一部分中,我回忆了有关ASP开辟的一些基础成绩,先容了一些功能测试的了局,以了解我们安排在页面中的代码大概对运转功能形成甚么样的影响。在这个系列的第二部分,我们将切磋经由论证的ASP最普遍的用处,即经由过程ActiveX数据工具(ADO)交互利用数据库内容。ADO是Microsoft通用并复杂的数据库界面。

  ADO有良多的功效设置,因而筹办这篇文章时最年夜的应战即是限定测试成绩的局限。思索到读取年夜数据会议为web服务器施加很年夜的负载,我决意将研讨的内容范围在为利用ADO纪录集寻觅最优化设置的方面。可是这个限定仍是提出了一个应战,由于ADO为实行统一个功效供应了多种体例。好比说,纪录集能够从Recordset类中恢复,也能够从Connection和Command类中恢复。别的,一旦你有了一个纪录集,那末有良多个选择会戏剧性地影响功能。因而,同第一部分一样,我将尽量地多触及一些详细成绩。
目标
  我研讨的目标是猎取充足的信息以找到以下成绩的谜底:
  *是不是应当利用ADOVBS.inc包括文件?
  *当利用一个纪录集时,是不是应当创立一个独自的Connection工具?
  *恢复一个纪录集最好的办法是甚么?
  *指针和锁的范例中,哪些是最无效的?
  *是不是应当利用断开的纪录集?
  *设置纪录集(Recordset)属性的最好办法是甚么?
  *援用纪录会合域值的最无效办法是甚么?
  *利用一时字符串能够较好地取代缓冲器吗?
测试是怎样设立的?
  为举行这项研讨中的测试,我们共组装了21个ASP页面(包括在本文下载内容中)。每一个页面都被设置成用3个分歧的查询前往纪录集运转,这些纪录会合分离有0、25、250笔记录。这能够匡助我们将装载纪录集的成绩和在纪录会合轮回上的功能成绩断绝开。
  为满意这些变更的前提,数据库毗连字符串和测试SQL字符串都作为使用程序变量存储在Global.asa中。由于我们的测试数据库是在MicrosoftSQLServer7.0上运转的,因而我们的毗连字符串指定OLEDB作为毗连供给者、Northwind样本数据库(包括在SQL服务器中)作为以后数据库。SQLSELECT语句请求NorthwindOrders表格中的7个特定域。
  <SCRIPTLANGUAGE=VBScriptRUNAT=Server>
  SubApplication_OnStart
  Application("Conn")="Provider=SQLOLEDB;"&_
  "Server=MyServer;"&_
  "uid=sa;"&_
  "pwd=;"&_
  "DATABASE=northwind"
  Application("SQL")="SELECTTOP0OrderID,"&_
  "CustomerID,"&_
  "EmployeeID,"&_
  "OrderDate,"&_
  "RequiredDate,"&_
  "ShippedDate,"&_
  "Freight"&_
  "FROM[Orders]"
  EndSub
  </SCRIPT>
  alternatesql?25records
  Application("SQL")="SELECTTOP25OrderID,"&_
  "CustomerID,"&_
  "EmployeeID,"&_
  "OrderDate,"&_
  "RequiredDate,"&_
  "ShippedDate,"&_
  "Freight"&_
  "FROM[Orders]"
  alternatesql?250records
  Application("SQL")="SELECTTOP250OrderID,"&_
  "CustomerID,"&_
  "EmployeeID,"&_
  "OrderDate,"&_
  "RequiredDate,"&_
  "ShippedDate,"&_
  "Freight"&_
  "FROM[Orders]"
  我们的测试服务器是一个双450MHzPentium,512MB的RAM,在其上运转着NTServer4.0SP5,MDAC2.1(数据会见组件)和MicrosoftScriptingEngine的5.0版本。SQL服务器在一个一样规格的独自呆板上运转。同第一篇文章一样,我利用Microsoft的Web使用程序重点工具纪录从最后的页面哀求到传输最初一个字节(TTLB)的工夫,准确到服务器上的毫秒级。这个测试剧本运转20小时,挪用每一个页面1300次以上。显现的工夫是session的均匀TTLB。要记着的是,同第一篇文章一样,我们只是试图触及功能方面的成绩,而非伸缩性和容量的成绩。
  还请注重,我们在服务器上开启了缓冲器。别的,我把一切的文件名都定为一样长度,因而文件名中就会有一个或多个下划线来衬垫。
入手下手
  在第一个测试中,我们利用典范MicrosoftASPADO样本文件中的典范场景来恢复一个复杂的纪录集。在这个例子(ADO__01.asp)中,我们起首创立一个Connection工具,然后创立一个Recordset工具。固然,我在剧本中举行了一些修正,以反应在本系列的第一部分中触及到的一些好的做法。
  <%OptionExplicit%>
  <!--#Includefile="ADOVBS.INC"-->
  <%
  DimobjConn
  DimobjRS
  Response.Write(_
  "<HTML><HEAD>"&_
  "<TITLE>ADOTest</TITLE>"&_
  "</HEAD><BODY>"_
  )
  SetobjConn=Server.CreateObject("ADODB.Connection")
  objConn.OpenApplication("Conn")
  SetobjRS=Server.CreateObject("ADODB.Recordset")
  objRS.ActiveConnection=objConn
  objRS.CursorType=adOpenForwardOnly
 objRS.LockType=adLockReadOnly
  objRS.OpenApplication("SQL")
  IfobjRS.EOFThen
  Response.Write("NoRecordsFound")
  Else
  writeheadings
  Response.Write(_
 "<TABLEBORDER=1>"&_
  "<TR>"&_
  "<TH>OrderID</TH>"&_
  "<TH>CustomerID</TH>"&_
  "<TH>EmployeeID</TH>"&_
  "<TH>OrderDate</TH>"&_
  "<TH>RequiredDate</TH>"&_
  "<TH>ShippedDate</TH>"&_
  "<TH>Freight</TH>"&_
  "</TR>"_
  )
  writedata
  DoWhileNotobjRS.EOF
  Response.Write(_
  "<TR>"&_
  "<TD>"&objRS("OrderID")&"</TD>"&_
  "<TD>"&objRS("CustomerID")&"</TD>"&_
  "<TD>"&objRS("EmployeeID")&"</TD>"&_
  "<TD>"&objRS("OrderDate")&"</TD>"&_
  "<TD>"&objRS("RequiredDate")&"</TD>"&_
  "<TD>"&objRS("ShippedDate")&"</TD>"&_
  "<TD>"&objRS("Freight")&"</TD>"&_
  "</TR>"_
  )
  objRS.MoveNext
  Loop
  Response.Write("</TABLE>")
  EndIf
  objRS.Close
  objConn.Close
  SetobjRS=Nothing
  SetobjConn=Nothing
  Response.Write("</BODY></HTML>")
  %>
  了局是如许的:
.......
  如今先来看看每栏中的数字代表甚么:
  0代表运转前往0个纪录的查询时的TTLB,单元毫秒。在我们一切测试中,这个数字用来标记页面的负载或装载页面创立工具但不在数据中轮回所用的工夫。
  25装载并显现25笔记录的TTLB(毫秒)。
  tottime/25TTLB除以25笔记录(毫秒)。代表每笔记录的总均匀工夫。
  disptime/25以毫秒计的TTLB减往“0”那栏的TTLB,并除以25笔记录。代表在纪录会合轮回显现每笔记录的工夫。
  250装载并显现250笔记录的TTLB(毫秒)。
  tottime/250TTLB除以250笔记录(毫秒)。代表每笔记录的总均匀工夫。
  disptime/250以毫秒计的TTLB减往“0”那栏的TTLB,并除以250笔记录。代表在纪录会合轮回显现每笔记录的工夫。
  我们将用上面测试的了局与这些值比拟较。
是不是应当利用ADOVBS.inc包括文件?
  这个成绩我想快点办理。Microsoft供应的ADOVBS.inc文件包括270行代码,代表能够使用于ADO属性的年夜部分常量。我们的例子中只援用了这个文件中的2个常量。因而关于这个测试(ADO__02.asp),我作废了包括文件的援用,并用属性枚举中的实践数字取代了常量。
  objRS.CursorType=0adOpenForwardOnly
  objRS.LockType=1adLockReadOnly
  我们能够看到装载工夫削减了23%。这与每笔记录的显现工夫有界说上的分歧,由于这类改动关于在纪录会合轮回不该该有影响。这个成绩有几种办理举措。我倡议利用ADOVBS.inc文件作为参考,需要时利用正文来说明数字。要记着,就好像在第一部分所分析的一样,正文是不必要害怕的,由于只需利用过度,它们不会给功能带来年夜的影响。另外一种办法是只从文件中将你所必要的常量复制到页面中。
  办理这个成绩有一个很酷的办法,经由过程将ADO类库毗连到你的使用程序,使一切的ADO常量都可用。将以下代码增添到你的Global.asa文件,你就能够间接利用一切的常量。
  <!--METADATATYPE="typelib"
  FILE="C:ProgramFilesCommonFilesSYSTEMADOmsado15.dll"
  NAME="ADODBTypeLibrary"-->
  或
  <!--METADATATYPE="typelib"
  UUID="00000205-0000-0010-8000-00AA006D2EA4"
  NAME="ADODBTypeLibrary"-->
  以是,这里是我们的第一个划定规矩:
  *制止包括ADOVBS.inc文件,用别的办法来利用常量。当利用一个纪录集时,是不是应当创立一个独自的Connection工具?

  要想准确回覆这个成绩,必要在两个分歧情形下查验测试了局:第一是每页实行一个数据库处置的情形,第二是每页实行多个数据库处置的情形。
  在后面的例子中,我们已创立了一个独自的Connection工具,并将它传送到纪录集的ActiveConnection属性。可是也有大概仅仅把毗连字符串传送到这个属性中,从而能够制止一个分外的步骤,即在剧本(ADO__03.asp)中例示和设置一个独自的组件:
  objRS.ActiveConnection=Application("Conn")
  只管我们仍旧在纪录会合创立了一个毗连,但它是在十分优化的情形下创立的,以是刚一入手下手我们就看到启动工夫比之前的测试削减了23%,同意料中一样,同每一个纪录的显现工夫几近没有甚么不同。
  因而,我们的第二个划定规矩是:
  *当利用一个单个纪录集时,将毗连字符串传送到ActiveConnection属性中。
  上面要断定当在一个页面上创立多个纪录集时,这个逻辑是不是仍然建立。为测试这个情形,我引进了FOR轮回,将后面的例子反复10次。在这个测试中,我们还将研讨3种选择:
  第一,我们在每一个轮回中创立并烧毁Connection工具(ADO__04.asp):
  Dimi
  Fori=1to10
  SetobjConn=Server.CreateObject("ADODB.Connection")
  objConn.OpenApplication("Conn")
  SetobjRS=Server.CreateObject("ADODB.Recordset")
  objRS.ActiveConnection=objConn
  objRS.CursorType=0adOpenForwardOnly
  objRS.LockType=1adLockReadOnly
  objRS.OpenApplication("SQL")
  IfobjRS.EOFThen
  Response.Write("NoRecordsFound")
 Else
  writeheadings
  ...
  writedata
  ...
  EndIf
  objRS.Close
  SetobjRS=Nothing
  objConn.Close
  SetobjConn=Nothing
  Next
  第二,在轮回外创立一个独自的Connection工具,并与每一个纪录集共享它(ADO__05.asp):
  SetobjConn=Server.CreateObject("ADODB.Connection")
  objConn.OpenApplication("Conn")
  Dimi
  Fori=1to10
  SetobjRS=Server.CreateObject("ADODB.Recordset")
  objRS.ActiveConnection=objConn
  objRS.CursorType=0adOpenForwardOnly
  objRS.LockType=1adLockReadOnly
  objRS.OpenApplication("SQL")
  IfobjRS.EOFThen
  Response.Write("NoRecordsFound")
  Else
  writeheadings
  ...
  writedata
  ...
  EndIf
  objRS.Close
  SetobjRS=Nothing
  Next
  objConn.Close
  SetobjConn=Nothing
  第三,在每一个轮回中将毗连字符串传送到ActiveConnection属性(ADO__06.asp):
  Dimi
  Fori=1to10
  SetobjRS=Server.CreateObject("ADODB.Recordset")
 objRS.ActiveConnection=Application("Conn")
  objRS.CursorType=0adOpenForwardOnly
  objRS.LockType=1adLockReadOnly
  objRS.OpenApplication("SQL")
  IfobjRS.EOFThen
  Response.Write("NoRecordsFound")
  Else
  writeheadings
  ...
  writedata
  ...
  EndIf
  objRS.Close
  SetobjRS=Nothing
  Next
  你大概已猜到了,在每一个轮回中创立并烧毁Connection工具是一个低效力的办法。可是使人受惊的是,仅仅在每一个轮回中传送毗连字符串比共享单连续接工具的效力只低一点点。
  只管云云,我们的第3条划定规矩是:
  *在一个页面上利用多个纪录集时,创立一个Connection工具,在ActiveConnection属性中反复利用它。
指针和锁的范例中,哪些是最无效的?
  到今朝为止,我们一切测试都只用了只向前(ForwardOnly)的指针在纪录会合轮回。可是,ADO还为纪录集供应了3品种型的指针:Static,Dynamic和Keyset。每种都供应了分外的功效,好比向前和向后挪动和当他人创建数据时能够看到修正情形的功效。不外,会商这些指针范例的内在不是本文会商的局限。我把这些留给你本人。上面是各类范例的对照剖析。
  与它们的同类ForwardOnly比拟,这些分外的指针都分明地形成了更年夜的负载(ADO__03.asp)。别的这些指针在轮回时代也更慢。我想与你一同分享的一条忠言是要制止这类设法:“我不时地必要一下Dynamic指针,以是爽性老是用它算了。”
  从实质上说,一样的成绩也合用于锁的范例。后面的测试中只利用了ReadOnly(只读)范例的锁。可是,另有三品种型的锁:LockPessimistic、LockOptimistic和LockBatchOptimistic。同指针的选择一样,这些锁也为处置纪录会合的数据供应了分外的功效和把持。一样,我将进修每种锁设置的得当用处的内容留给你本人。
  以是引诱我们思索划定规矩4的逻辑很复杂:利用最合适你的义务的最复杂的指针和锁的范例。
猎取一个纪录集最好的体例是甚么?
  到今朝为止,我们只是经由过程Recordset工具来恢复纪录集。可是ADO还供应了一些猎取纪录集的直接办法。下一个测试就将ADO__03.asp中的值与间接从一个Connection工具中创立一个纪录集工具(CONN_01.asp)来对照。
  SetobjConn=Server.CreateObject("ADODB.Connection")
  objConn.OpenApplication("Conn")
  SetobjRS=objConn.Execute(Application("SQL"))
  我们看到,负载有一个稍微的增添,显现每笔记录的工夫没有变更。
  然后,我们看看从一个Command工具中间接创立一个Recordset工具(CMD__01.asp):
  SetobjCmd=Server.CreateObject("ADODB.Command")
  objCmd.ActiveConnection=Application("Conn")
  objCmd.CommandText=Application("SQL")
  SetobjRS=objCmd.Execute
  我们再次看到负载有一个稍微的增添,每一个纪录的显现工夫有一个名义上的区分。固然最初这两种办法对功能的影响很小,却有一个年夜成绩必要思索。
  经由过程Recordset类创立一个纪录集关于把持怎样处置纪录集供应了最年夜的天真性。固然别的办法也没有提出一个压服性的功能成绩,可是你会被默许形态下前往何种指针范例和锁范例而狐疑,这些关于你的特定需求来讲纷歧定是最优的。
  以是,除非由于某种特别缘故原由你必要别的办法的话,请遵守第5条划定规矩:经由过程ADODB.Recordset类例示纪录集以取得最好的功能和最年夜的天真性。
是不是应当断开纪录集?
  ADO为断开一个纪录集供应了一种选择,纪录集要在一个向前查询中恢复一切数据、封闭毗连、利用一个当地(或客户)指针在数据会合挪动。这还供应了一个初期开释毗连的时机。这类情形关于处置远程数据服务是需要的,由于这类情形下数据必需从数据库断开。可是关于一般的用处,如许做有优点吗?
  上面我们增添了CursorLocation属性,翻开纪录集后封闭毗连(CLIENT1.asp):
  SetobjRS=Server.CreateObject("ADODB.Recordset")
  objRS.CursorLocation=3adUseClient
  objRS.ActiveConnection=Application("Conn")
  objRS.LockType=1adLockReadOnly
  objRS.OpenApplication("SQL")
  objRS.ActiveConnection=Nothing
  从实际上说,这个手艺应当招致功能更快。缘故原由有两个:起首,在纪录会合挪动时,制止了经由过程毗连的反复哀求;其次经由过程较早地作废毗连加重了资本需求。可是,在利用客户端指针时,效力低得很分明。多是因为当利用客户指针地位时,不论你的设置是甚么,CursorType都被修正成Static。
  划定规矩6是如许的:除非是一个断开的情况中所请求的,制止利用断开的纪录集。
甚么是设置纪录集属性的最好办法?
  后面一切的测试都是经由过程独自的属性设置来间接设置纪录集的属性的。可是Recordset.Open函数能够为我们所必要的全体属性吸收分外的参数。固然关于每一个属性来讲,独自的代码行易于浏览和保护,它们仍是要分离实行一个独自函数挪用,必需经由过程COM界面来汇合(ADO__07.asp):
  SetobjRS=Server.CreateObject("ADODB.Recordset")
  objRS.OpenApplication("SQL"),Application("Conn"),0,1
  adForwardOnly,adLockReadOnly
  这些办法在负载上带来得不同小得惊人,因而我们失掉划定规矩7:不要对独自设置纪录集属性感应忧虑。援用纪录会合域值的最无效办法是甚么?

  到今朝为止,我都是用名字援用纪录会合的域值的。这多是一种效力很低的办法,由于每次挪用都必要查找域。为了证实这一点,上面的测试就要经由过程纪录会合域的汇合的指针来援用域(ADO__08.asp):
 writedata
 DoWhileNotobjRS.EOF
  Response.Write(_
  "<TR>"&_
  "<TD>"&objRS(0)&"</TD>"&_
  "<TD>"&objRS(1)&"</TD>"&_
  "<TD>"&objRS(2)&"</TD>"&_
  "<TD>"&objRS(3)&"</TD>"&_
  "<TD>"&objRS(4)&"</TD>"&_
  "<TD>"&objRS(5)&"</TD>"&_
  "<TD>"&objRS(6)&"</TD>"&_
  "</TR>"_
  )
  objRS.MoveNext
 Loop
  正如我们所意料的,装载工夫的变更很小(差别多是因为代码上的稍微削减引发的)。可是这类手艺在无效显现工夫上却带来了分明的削减。
  鄙人面的例子中,我们将给每一个域指定一个独自的变量。这类办法制止了在表格轮回内的一切查找(ADO__09.asp):
 IfobjRS.EOFThen
  Response.Write("NoRecordsFound")
 Else
  writeheadings
  ...
  Dimfld0
  Dimfld1
  Dimfld2
  Dimfld3
  Dimfld4
  Dimfld5
  Dimfld6
  Setfld0=objRS(0)
  Setfld1=objRS(1)
  Setfld2=objRS(2)
  Setfld3=objRS(3)
  Setfld4=objRS(4)
  Setfld5=objRS(5)
  Setfld6=objRS(6)
  writedata
  DoWhileNotobjRS.EOF
  Response.Write(_
  "<TR>"&_
  "<TD>"&fld0&"</TD>"&_
  "<TD>"&fld1&"</TD>"&_
  "<TD>"&fld2&"</TD>"&_
  "<TD>"&fld3&"</TD>"&_
  "<TD>"&fld4&"</TD>"&_
  "<TD>"&fld5&"</TD>"&_
  "<TD>"&fld6&"</TD>"&_
  "</TR>"_
  )
  objRS.MoveNext
  Loop
  Setfld0=Nothing
  Setfld1=Nothing
  Setfld2=Nothing
  Setfld3=Nothing
  Setfld4=Nothing
  Setfld5=Nothing
  Setfld6=Nothing
  Response.Write("</TABLE>")
 EndIf
  到今朝,这类办法构成的了局是最好的。每笔记录的显现工夫下落成了.45毫秒。
  如今,一切测试剧本的设置都请求对了局纪录集有一些懂得。好比说,我们一向在栏题目中给域名编码,独自地援用这些域的值。上面的例子供应了一个静态的办理计划,在域的汇合中轮回,不但失掉数据,也失掉域的题目(ADO__10.asp):
 IfobjRS.EOFThen
  Response.Write("NoRecordsFound")
 Else
  writeheadings
  Response.Write("<TABLEBORDER=1><TR>")
  ForEachobjFldinobjRS.Fields
  Response.Write("<TH>"&objFld.name&"</TH>")
  Next
  Response.Write("</TR>")
  writedata
  DoWhileNotobjRS.EOF
  Response.Write("<TR>")
  ForEachobjFldinobjRS.Fields
  Response.Write("<TD>"&objFld.value&"</TD>")
  Next
  Response.Write("</TR>")
  objRS.MoveNext
  Loop
  Response.Write("</TABLE>")
 EndIf
 能够看到,我们在功能上有一个丧失,可是这个办法仍是比ADO__07.asp要快一些。
  上面的测试是在最初两个测试之间举行一些折衷。经由过程在一个静态分派数组中保留域的援用,既保持了静态的天真性,也挽回了一些功能上的丧失。
 IfobjRS.EOFThen
  Response.Write("NoRecordsFound")
 Else
  DimfldCount
  fldCount=objRS.Fields.Count
  Dimfld()
  ReDimfld(fldCount)
  Dimi
  Fori=0tofldCount-1
  Setfld(i)=objRS(i)
  Next
  writeheadings
  Response.Write("<TABLEBORDER=1><TR>")
  Fori=0tofldCount-1
  Response.Write("<TH>"&fld(i).name&"</TH>")
  Next
  Response.Write("</TR>")
  writedata
  DoWhileNotobjRS.EOF
  Response.Write("<TR>")
  Fori=0tofldCount-1
  Response.Write("<TD>"&fld(i)&"</TD>")
  Next
  Response.Write("</TR>")
  objRS.MoveNext
  Loop
  Fori=0tofldCount-1
  Setfld(i)=Nothing
  Next
  Response.Write("</TABLE>")
 EndIf
  固然它其实不比最好值快,可是比后面的几个例子要快了良多,而且有一个上风就是可以静态地体现任何纪录集。
  鄙人一个测试中,我们将对之前的计划做一个完全的改动,利用纪录集的GetRows指令创立一个轮回用的数组,而不是在纪录集自己举行轮回。注重,挪用GetRows以后,立即就将纪录集设置为Nothing,如许就可以更快地开释体系资本。别的还要注重数组的第一个维数代表域,第二个维数代表行(ADO__12.asp):
 IfobjRS.EOFThen
  Response.Write("NoRecordsFound")
  objRS.Close
  SetobjRS=Nothing
 Else
  writeheadings
  ...
  setarray
  DimarrRS
  arrRS=objRS.GetRows
  closerecordsetearly
  objRS.Close
  SetobjRS=Nothing
  writedata
  DimnumRows
  DimnumFlds
  Dimrow
  Dimfld
  numFlds=Ubound(arrRS,1)
  numRows=Ubound(arrRS,2)
  Forrow=0tonumRows
  Response.Write("<TR>")
  Forfld=0tonumFlds
  Response.Write("<TD>"&arrRS(fld,row)&"</TD>")
  Next
  Response.Write("</TR>")
  Next
  Response.Write("</TABLE>")
 EndIf
  经由过程利用GetRows指令,就能够猎取全部纪录集并将其装载到数组中。当恢复出格年夜的纪录集时,这类办法有大概会形成资本成绩,可是数据的轮回快多了,由于相似于MoveNext的函数挪用和EOF的检测都能够作废了。
  不外速率的提拔的确是有价值的,由于纪录集的元数据不再与数据在一同。环绕这个成绩,我在挪用GetRows之前用纪录集来恢复题目名。别的还能够提早提取数据范例和别的信息。还要注重,在我们的测试中,功能上的上风只要在利用年夜一些的纪录集时才干看到。
  在这部分最初的测试中,我们更进一步,利用纪录集的GetString指令。这个办法将全部纪录集提取到一个年夜的字符串中,同意你指定本人的分开符(ADO__13.asp):
 IfobjRS.EOFThen
  Response.Write("NoRecordsFound")
  objRS.Close
  SetobjRS=Nothing
 Else
  writeheadings
  ...
  setarray
  DimstrTable
  strTable=objRS.GetString(2,,"</TD><TD>","</TD></TR><TR><TD>")
  closerecordsetearly
  objRS.Close
  SetobjRS=Nothing
  Response.Write(strTable&"</TD></TR></TABLE>")
 EndIf
  固然这类办法已靠近了最高程度,可是它只合适于最复杂的计划,由于它基本就不克不及使用于数据的特别情形。
察看
  在我们入手下手这套测试之前,实行每笔记录的工夫一向在.83毫秒摆布震惊。这套测试中的年夜多半办法都将这个数字削减了一半。固然有些办法分明地供应了更快的速率,可是价值是天真性的下降。
  上面的划定规矩是以主要水平为按次的:
*当纪录会合的值不必要用一种特别体例来看待而且可以格局化为一种一致的格局时,利用GetString办法来提取数据。
*当你在计划上必要更年夜的天真性,可是又不必要用纪录集的元数据举行事情,利用GetRows办法将数据提取到一个数组中。
*当你必要计划的天真性和元数据时,在进进一个数据恢复的轮回之前,将你的域束缚在当地变量中。制止用名字援用域。
利用一时字符串能够较好地取代缓冲器吗?
  这是针对我上一篇文章提交的一些注解所激发的一个小小的切题。要会商的成绩是环绕着缓冲器的利用及利用一时字符串作为替换来搜集输入,如许就同意Response.Write只挪用一次。为了测试,我从ADO_11.asp的代码入手下手,将了局附加到一个字符串中,而不是在每一个轮回都挪用Response.Write,当全部操纵都停止后,在字符串上挪用Response.Write(STR__01.asp):
  DimstrTable
  strTable=""
  writeheadings
  strTable=strTable&"<TABLEBORDER=1><TR>"
  Fori=0tofldCount-1
  strTable=strTable&"<TH>"&fld(i).name&"</TH>"
  Next
  strTable=strTable&"</TR>"
  writedata
  DoWhileNotobjRS.EOF
  strTable=strTable&"<TR>"
  Fori=0tofldCount-1
  strTable=strTable&"<TD>"&fld(i)&"</TD>"
  Next
  strTable=strTable&"</TR>"
  objRS.MoveNext
  Loop
  Fori=0tofldCount-1
  Setfld(i)=Nothing
  Next
  strTable=strTable&"</TABLE>"
  Response.Write(strTable)
  看起来实行得不是很好。大概正象很多人倡议的,我们应当用Space指令为这个字符串指定一些空间,如许它就不必要在轮回时代老是为本人从头分派空间(STR__02.asp):
  DimstrTable
  strTable=Space(10000)
  大概Space指令其实不象倡议的那样事情。我们最初的划定规矩是:不要用一时字符串来搜集输入。划定规矩的总结

  如今我们来从头总结一下这些划定规矩:
  *制止包括ADOVBS.inc文件,用别的办法来利用常量。
  *当利用一个单个纪录集时,将毗连字符串传送到ActiveConnection属性中。
  *在一个页面上利用多个纪录集时,创立一个Connection工具,在ActiveConnection属性中反复利用它。
  *利用最合适你的义务的最复杂的指针和锁的范例。
  *经由过程ADODB.Recordset类例示纪录集以取得最好的功能和最年夜的天真性。
  *除非是一个断开的情况中所请求的,制止利用断开的纪录集。
  *不要对独自设置纪录集属性感应忧虑。
  *当纪录会合的值不必要用一种特别体例来看待而且可以格局化为一种一致的格局时,利用GetString办法来提取数据。
  *当你在计划上必要更年夜的天真性,可是又不必要用纪录集的元数据举行事情,利用GetRows办法将数据提取到一个数组中。
  *当你必要计划的天真性和元数据时,在进进一个数据恢复的轮回之前,将你的域束缚在当地变量中。制止用名字援用域。
  *不要用一时字符串来搜集输入。
结论
  一样,从这些测试中我们所学到的最主要的一点是:小小的变更会在功能上形成很年夜的影响。假如我们把第一个测试与ADO__09.asp(在纪录会合轮回的最快了局)比拟,能够看到在反响工夫上最少削减了50%。
  假如我们把第一个测试与一切测试中最快的情形,即便用GetString的办法比拟较,就会发明反响工夫只是原始值的很小一部分。
  以是要记着,永久不要想固然。假如你不克不及一定,那就运转一些有针对性的测试。
本文相干材料:http://www.asptoday.com/articles/images/20000426.zip。

优点:简单易学、开发速度快、有很多年“历史”,能找到非常多别人做好的程序来用、配合activeX功能强大,很多php做不到的asp+activeX能做到,例如银行安全控件
分手快乐 该用户已被删除
沙发
发表于 2015-1-17 16:35:59 | 只看该作者
它可通过内置的组件实现更强大的功能,如使用A-DO可以轻松地访问数据库。
只想知道 该用户已被删除
板凳
发表于 2015-1-20 20:17:02 | 只看该作者
以上是语言本身的弱点,在功能方面ASP同样存在问题,第一是功能太弱,一些底层操作只能通过组件来完成,在这点上是远远比不上PHP/JSP,其次就是缺乏完善的纠错/调试功能,这点上ASP/PHP/JSP差不多。
因胸联盟 该用户已被删除
地板
发表于 2015-1-29 20:34:09 | 只看该作者
虽然ASP也有很多网络教程。但是这些都不系统。都是半路出家,只是从一个例子告诉你怎么用。不会深入讨论,更不会将没有出现在例子里的方法都一一列举出来。
不帅 该用户已被删除
5#
发表于 2015-2-15 13:20:54 | 只看该作者
封装性使得代码逻辑清晰,易于管理,并且应用到ASP.Net上就可以使业务逻辑和Html页面分离,这样无论页面原型如何改变,业务逻辑代码都不必做任何改动;继承性和多态性使得代码的可重用性大大提高。
莫相离 该用户已被删除
6#
发表于 2015-3-4 11:32:49 | 只看该作者
尽管MS自己讲C#内核中更多的象VC,但实际上我还是认为它和Java更象一些吧。首先它是面向对象的编程语言,而不是一种脚本,所以它具有面向对象编程语言的一切特性,比如封装性、继承性、多态性等等,这就解决了刚才谈到的ASP的那些弱点。
简单生活 该用户已被删除
7#
发表于 2015-3-11 19:13:52 | 只看该作者
我想问如何掌握学习节奏(先学什么再学什么)最好详细点?
精灵巫婆 该用户已被删除
8#
发表于 2015-3-27 17:08:56 | 只看该作者
接下来就不能纸上谈兵了,最好的方法其实是实践。实践,只能算是让你掌握语言特性用的。而提倡做实际的Project也不是太好,因为你还没有熟练的能力去综合各种技术,这样只能使你自己越来越迷糊。
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

QQ|Archiver|手机版|仓酷云 鄂ICP备14007578号-2

GMT+8, 2024-11-1 20:35

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表