ASP.NET错误处理和程序优化

使用验证控件
• 编程处理
– 校验语句
– try...catch...finally
– Page_Error
– Application_Error
• 在应用程序配置文件中，为应用程序执行
的声明性错误处理
校验(checked)和非校验

• 所有异常对象的基类
• 属性：
– HelpLink:到一个文件的链接，该文件包含关于错误
的更详细的信息
– InnerException:一个内部异常的引用。如果一个异
常被捕获，并被传递给另外一个异常处理程序，则
该属性返回到第一个异常的引用
– Message：描述异常的消息
– Source：一个字符串，其中包含引起错误的对象的
名称
– StackTrace：返回一个指出错误原因的栈跟踪
– TargeSite：引起错误的方法

使用模板
void Page_Error(object sender,EventArgs e)
{
Response.Write(“发生错
误:”+Server.GetLastError().ToString());
Server.ClearError();
}
private void WebForm1_Error(object sender, System.EventArgs e)
        {
            string strMessage = Server.GetLastError().Message;
            //Response.Write(strMessage);
            Server.ClearError();
            //以下把信息写入windows日志
            //要把aspnet用户添加到管理员组中，以便有写注册表权限
            if(!EventLog.SourceExists("mySource"))
                EventLog.CreateEventSource("mySource","myLog");
            EventLog Event = new EventLog();
            Event.Source = "mySource";
            Event.WriteEntry(strMessage,EventLogEntryType.Warning);
            //EventLog.Delete("myLog");
            throw new Exception("我处理不了，请最高人民法院处理！");

        }
应用程序中任何页面抛出异常都会调用
• 在global.asax中
• 形式为：
void Application_Error(object sender,EventArgs
e)
{
...
}
protected void Application_Error(Object sender, EventArgs e)
        {
            //把错误信息发送到作者
            string strPageUrl = Request.Path;
            Exception ErrorInfo =Server.GetLastError();
            //Server.ClearError();
            string strMessage = "Url:" + strPageUrl + "</br>";
            strMessage = strMessage + " Error: ";
            strMessage = strMessage + ErrorInfo.ToString() + "</br>";

            MailMessage Mymessage = new MailMessage();
            Mymessage.To = "shaozhd@263.net";
            Mymessage.From = "shaozhd@263.net";
            Mymessage.Subject = "ASP.NET Error";
            Mymessage.BodyFormat = MailFormat.Text;
            Mymessage.Body = strMessage;
            SmtpMail.Send(Mymessage);

        }
ASP.NET同以前的ASP一样，当服务器上发生了一个运
行时间或编译时间错误时，就会生成一个html 错误页面。
但是与ASP不同，ASP.NET格外关注的是：要确保在默
认状态下，不会因为这个错误的发生而泄露“安全”信息。
• ＜system.web>
<customErrors defaultRedirect="url" mode="RemoteOn
ly">
<error statusCode="code" redirect="url"></error>
</customErrors>
＜/system.web>
是
– XmlDocument LoadXML(string strFileID) //加
载XML
– bool CheckIDExisit(string strFileID,string strID)
//判断节点是否存在
• 还是
– bool CheckIDExisitByXml (string strXml,string
strID) //判断节点是否存在
– 或bool CheckIDExisitByXml (XmlDocument
objXml,string strID) //判断节点是否存在
采用3层逻辑模型
– Pages (.aspx) and User Controls (.ascx) UI
– Business and Data Access classes in /bin dir
– Data within a SQL Database via SPROCs
ADO.NET 可支持多个Provider：
– System.Data.SqlClient
– System.Data.OracleClient
– System.Data.OleDb
– System.Data.Odbc
• 所有Provider的编程模型相同
– 但是性能方面存在明显差异
• 建议：使用最佳Provider
– 在访问MSDE/SQL 时始终使用SqlClient
– 在访问Oracle 时始终使用OracleClient
DataReader
– 对查询的结果提供了单向读取的操作
– 轻量快速– 但在Reader为关闭之前始终处于连接状态
• DataSet
– 非链接的数据访问方式
– 内部使用DataReader用于获取数据
– 在完成DataSet的获取后会自动关闭DataReader
• 如何选择?
– 依赖于您的应用
– 般情况下,读取大量数据,对返回数据不做大量处理用
SqlDataReader.对返回数据大量处理用datset比较合
通常情况下DataReader比
DataSet快16%！！
ExecuteNonQuery
– 对数据的更新不需要返回结果集
– 由于不返回结果集可省掉网络数据传输。它仅仅返回受影响
的行数。如果只需更新数据用ExecuteNonQuery性能的开销
比较小。
• ExecuteScalar
– 它只返回结果集中第一行的第一列。使用ExecuteScalar 方
法从数据库中检索单个值（例如id号）。
– 与使用ExecuteReader 方法， 返回的数据执行生成单个值所
需的操作相比，此操作需要的代码较少
• 如何选择?
– 只需更新数据用ExecuteNonQuery.单个值的查询使用
ExecuteScalar
一般的绑定方法<%#
DataBinder.Eval(Container.DataItem, “字段名”)
%>用DataBinder.eval 绑定不必关心数据来源
(Dataread或dataset)。不必关心数据的类型eval
会把这个数据对象转换为一个字符串。在底层绑
定做了很多工作，使用了反射性能。正因为使用
方便了，但却影响了数据性能。
• 直接转换成DataRowView的话，将会给性能带来
很大提升：
• <@% ((DataRowView)Container.DataItem)["字
段名"] %>
• ADO.NET 拥有内置的连接池
– 自动缓存/重新使用连接
– 不必为此编写任何代码
• 代码建议：
– “在后期打开代码中的连接，然后在早期将其
关闭”
– 切勿长时间保持连接状态
– 完成后应立即显示地关闭数据库连接，以将其返
回至池中
优化提示：
– 不同的连接字符串可以生成多个不同的连接池
– 在Web.Config 中存储单个连接字符串
– 使用ConfigurationSettings.AppSettings，以在运
行时采用编程形式对其进行访问
• 始终应明确关闭数据连接，避免连接泄漏
– 否则连接将在下一次垃圾收集之前保持打开状态
– 泄露连接会显著降低性能
建议将SPROC 用于数据存取
– 通过DBA 进行更轻松的性能调试
– 通过使用数据库事务处理避免出现分布事务成本
– 有助于防止SQL 注入攻击
– 有助于消除应用与数据库反复调用的成本
• 有趣的提示：
– 可以通过企业管理器来关闭动态SQL 支持，以强制使用
SPROC
ASP.NET controls 能够维护页面Control元素的状态
– 状态以“viewstate” hidden field进行传递
• 负面影响:
– 增加网络负荷(both on render and postback)
– 额外的服务器性能消耗（serialize values to/from viewstate）
• Viewstate灵活性:
– 页面级（Can disable viewstate entirely for a page）
– 控件级（Can disable viewstate usage on a per control basis）
• 建议:
– 认真审核该功能的使用
– 若不使用PostBack功能，请在页面级屏蔽ViewState
– PostBack时每次都重新生成控件，请对控件级的ViewState屏蔽
– 使用<%@ Page Trace=“true” %>跟踪ViewState的大小
如果您希望更明确的限制viewstate 的使用，可将
ASP.NET 配置为默认情况下处于关闭状态
• Machine.config：
<configuration>
<system.web>
<pages enableViewState=“false”/>
</system.web>
</configuration>
• 之后需要viewstate 的页将在页面指令中手动对其进
行设置：
– <%@ Page EnableViewState=“true” %>
页面上的每个服务器控件的生成都存在固定的
成本
–每个控件的成本通常可以忽略不计
• 复合控件有时可以屏蔽使用的控件数量，尽管
会出现以下情况
–聚集成本有时可以累加
–打开ASP.NET Trace即可查看实际计数
1、什么是缓存技术？
缓存是计算机快速地再次获得数据地方式。
2、缓存原理
将经常访问地数据存储到计算机可以更快、
更容易地读取地位置。
ASP.NET有两种用于WEB应用的缓冲技术：输
出缓冲和数据缓冲。
– 输出缓冲指：把一次请求所产生的动态输出保存于内
存中。
– 数据缓冲指：按照一定的策略把事先不确定的对象保
存于内存中。
• 输出缓存的使用
– 使用@OutputCache指令
– 例如(添加在页头)
<%@ OutputCache Duration=“10” VaryByParam=“None” %>
ASP.NET提供了一个相当出色的缓存引擎
机制，它允许页面保存和索引HTTP请求所
要求的各种各样的对象。ASP.NET的缓存
对各个应用来说是私有的，是存储各种对
象的存储器。缓存的生存周期取决于应用
的生存周期，也就是说，当应用重新启动
时，缓存实际上也已重建。
数据缓冲
– 使用（类似于Session变量的使用）
Cache[“userName”] = “MeMe”;
Response.Write(Cache(“userName”));
– 注意不能通过下标访问缓存中的变量，如
Response.Write(Cache[0]);是错误的。
– 缓存的删除
Cache.Remove(“userName”);
使用缓存依存关系
– 缓存变量的添加
• Cache.Add()
• Cache.Insert()
它们功能相同，但Insert更加灵活一些
– Insert
（key,value,dependencies,absoluteExpiration,
slidingExpiration,priority,priorityDecay,onRem
oveCallBack）
1. “腐烂搜索”（Scavenging）
• 当内存变得比教紧张时，缓存机制会找出最
不常用和最不重要的对象，把它从内存中移
出，以减轻系统压力。
2. “到期控制”（Expiration）
• 编程者可以指定缓存对象的生存周期，这种
指定的时间可以是绝对的也可以是相对的。
3. “文件和键值依赖”
• 从外部文件或者是其他缓存键值是否改变，
来决定本身键值是否有效。
• 不要使用不必要的Session，和ASP中一样，
在不必要的时候不要使用Session
• 不使用不必要的Server Control
• 不使用不必要的ViewState
• 不要用Exception控制程序流程
• 禁用VB和Jscript动态数据类型
• 使用存储过程完成数据访问
• 只读数据访问不要使用DataSet
• 关闭ASP.NET的Debug模式
• 使用ASP.Net Output Cache缓冲数据
• 尽量用SQL返回DataGrid需要绑定的DataSet,尽量不
要对DataSet进行二次加工，特别不要对DataSet进
行大量删除，实践证明这很慢。不如复制部分数据。
• 尽量把查询数据的数据库操作次数压缩到最少，尽量
1-2次数据库操作就可完成；
• 注意优化数据库查询操作
• 不要在页面加载时默认选择全部数据，尽管可以方便
后续操作，但用户会以为“还没有操作就这么慢”
• 建议尽量用比较高效的SQL代替后续复杂的DataSet
二次加工
• 仅在需要的时候打开数据库连接
• 一旦数据库操作完毕，一定关闭连接
• 在关闭连接时记得删除临时对象
• 在关闭连接前，确保关闭任何用户定义事务
• 显示非交互性数据，使用SQLDataReader可以获得
最佳性能
• 注意共享那些经过复杂处理或漫长查询才得到的数据
• 在页面跳转时记得终止当前页面的处理
• 有大量连接的字符串操作不要使用+，改用
StringBuilder

缓存是否可以完全替代以往的Cookies，缓存在客户端硬盘上默认的保存位置是哪里？

A：用@ OutputCache设置输出缓存时，可以设置通过将 Location 属性包括在@ OutputCache 指令中并指定一个 OutputCacheLocation 枚举值，您可以以声明方式设置页输出的可缓存性。

l          Any 输出缓存可位于产生请求的浏览器客户端、参与请求的代理服务器（或任何其他服务器）或处理请求的服务器上。

l          Client 输出缓存位于产生请求的浏览器客户端上。

l          Downstream 输出缓存可存储在任何 HTTP 1.1 可缓存设备中，源服务器除外。这包括代理服务器和发出请求的客户端。

l          None 对于请求的页，禁用输出缓存。

l          Server 输出缓存位于处理请求的 Web 服务器上。

通过以上操作，您可以设置缓存的位置。

代码控制缓存
//
            Response.Cache.SetExpires(DateTime.Now.AddSeconds(10));
            Response.Cache.SetCacheability(HttpCacheability.Public);
            lbTime.Text = DateTime.Now.ToLongTimeString();