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

原创 2006年05月25日 17:24:00
使用验证控件
编程处理
校验语句
– 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();

asp.net ajax中的错误处理

• 服务器端ScriptManager设置 – AllowCustomErrorsRedirect属性:遇到错误是否 自动根据web.config中的设置跳转,默认值为True – AsyncPo...
  • houxh86
  • houxh86
  • 2011年09月25日 13:20
  • 260

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

  • 2008年12月01日 15:03
  • 8.77MB
  • 下载

ASP.NET的错误处理机制

对于一个Web应用程序来说,出错是在所难免的,因此我们应该未雨绸缪,为可能出现的错误提供恰当的处理。事实上,良好的错误处理机制正是衡量Web应用程序好坏的一个重要标准。试想一下,当用户不小心在浏览器输...
  • wnety
  • wnety
  • 2011年09月28日 13:50
  • 403

自定义 ASP.NET UpdatePanel 控件的错误处理

http://msdn.microsoft.com/zh-cn/library/bb398934(v=vs.100).aspx 如果在 UpdatePanel 控件中更新部分页时...
  • usoa
  • usoa
  • 2015年01月05日 11:14
  • 698

ASP.NET的错误处理机制

  • 2010年03月13日 10:02
  • 29KB
  • 下载
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:ASP.NET错误处理和程序优化
举报原因:
原因补充:

(最多只允许输入30个字)