精简自己20%的代码
持续重构,其乐无穷。
一:发现问题
先来说如何重构业务层的try{}catch{}finally{}代码块,我看过很多代码,异常处理这一块大致分为两种情况,一种是每个方法都大量的充斥着try{}catch{}finally{},这种方式的编程已经考虑到了异常处理,还有一种就是没有try{}catch{}finally{}的代码,因为根本就没有考虑代码的异常处理。每当我看到这样的代码,我都很忧伤。从程序的健壮性来看第一种还是要比第二种情况好,至少在编程意识中,随时想到了异常情况,有一种基本的编程思想。
比如:一个业务单据的多表插入,关联修改,虚拟删除等都是一些基本的操作,但是又是比较容易引起错误的操作,在这些方法上都会加上try{}catch{}finally{}对代码进行有效的防错处理。早期的代码是这样的。
public Boolean Save(AccountModel accountData) { Boolean result = false; try { //TODO ... result = true; } catch { } finally { } return result; } public Boolean Edit(AccountModel accountData) { Boolean result = false; try { //TODO ... result = true; } catch { } finally { } return result; } public Boolean VirDelete(AccountModel accountData) { Boolean result = false; try { //TODO ... result = true; } catch { } finally { } return result; }
仅仅定义了添加,修改,删除几个空方法,就写了三四十行代码,如果业务稍微复杂些,异常处理的代码很快就会突破百行大关。虽然复制,粘贴try{}catch{}finally{}很好使,但是业务逻辑代码大量充斥着这样的try{}catch{}finally{}代码,确实显得做事不够利落。
二:解决问题
那怎样来解决这件棘手的事呢,首先定义一个公用的try{}catch{}finally{},如下如示:
public class Process { public static bool Execute(Action action) { try { action.Invoke(); return true; } catch (Exception ex) { //1,异常隐藏 //2,异常替换 //3,异常封装 //写日志 return false; } finally { } } }
上边的代码定义了公用的try{}catch{}finally{},最关键是怎么运用起来,如下代码:
protected void Page_Load(object sender, EventArgs e) { AccountModel accountData = new AccountModel(); //准备传入的参数 Boolean result = false; //接收返回的值 Process.Execute(() => result = Save(accountData)); //执行方法 } public Boolean Save(AccountModel accountData) { Boolean result = false; //TODO ... result = true; return result; } public Boolean Edit(AccountModel accountData) { Boolean result = false; //TODO ... result = true; return result; } public Boolean VirDelete(AccountModel accountData) { Boolean result = false; //TODO ... result = true; return result; }
这样的精简过的代码,是不是感觉心情很舒畅。
三:提升与扩展
对于知足者常乐的人来说,到第二个步骤就可以洗洗睡了。但是对于精益求精的人来说,问题仍然没有完。我们来说一个应用场景,在WCF中的应用,我们知道WCF服务端的异常,不经过<serviceDebug includeExceptionDetailInFaults="true"/>的设置,服务端的异常是无法抛到客户端的。但是在正式环境中,不可能对进行serviceDebug的配置。正确的处理是在服务端对异常进行隐藏,替换,或者封装。
比如我们在服务端捕获了一个已知异常,但是这个异常会暴露一些敏感的信息,所以我们对异常进行替换,抛出新的异常后,我们还要把这个异常怎样传输给客户端。首先们要明确WCF中的一些基本常识,就是WCF中的数据传递要遵循WCF的数据契约,服务端抛到客户端的异常(异常其实也是数据),所以必须要给异常定义异常契约。
[DataContract(Name = "WCFException")] public class WCFException { [DataMember(Name = "Type")] public String Type { get; set; } [DataMember(Name = "StackTrace")] public String StackTrace { get; set; } [DataMember(Name = "Message")] public String Message { get; set; } }
然后处理异常的公共方法改写为:
public static bool Execute(Action action) { try { action.Invoke(); return true; } catch (Exception ex) { //1,异常隐藏 //2,异常替换 //3,异常封装 //写日志 WCFException exception = new WCFException { Type = "Error" , StackTrace = ex.StackTrace , Message = ex.Message }; throw new FaultException<WCFException>(exception , new FaultReason("服务端异常:" + ex.Message) , new FaultCode(ex.TargetSite.Name)); } finally { } }
这样在服务端抛出的异常,就能在客户端捕捉到。现在是不是感觉自己又提升了一些,想成为编程高手是指日可待了。
四:举一反三
异常的处理也不过如此,那是不是应该举一反三,看看事务的处理应该怎么办?比如现在大量的访求都用到了事务,如下代码:
public Boolean Save(AccountModel accountData) { OracleConnection conn = new OracleConnection("连接字符串"); IDbTransaction trans = conn.BeginTransaction(); Boolean result = false; try { //TODO ... trans.Commit(); result = true; } catch { trans.Rollback(); } finally { } return result; }
特别是 trans.Commit(); trans.Rollback(); 这样的代码出现在每个与事务相关的方法中, 让我感觉到代码的臃肿,以及隐陷约约的失望。
经过我几天的翻阅资料终于实现了事务的公用访求提取。使用方法如下代码所示:
[TransactionAttribute] [ExceptionAttribute] public bool Save(DataContext dContext, Dictionary<string, string> dtoPara) { Boolean returnVal = true; //TODO ... return returnVal; }
就是在一个方法上加[TransactionAttribute]就表示这个方法写在了事务中,反之,不在事务中,加[ExceptionAttribute]就表示这个方法作了异常处理,反之,不作异常处理。通过反射或者AOP都能实现Attribute编程的效果。最后,还有什么疑惑,可以在评论中给我留言,当然别忘记了点右下角的【推荐】。
HttpClient消息处理器
Asp.Net Web API
导航
Asp.Net Web API第一课:入门http://www.cnblogs.com/aehyok/p/3432158.html
Asp.Net Web API第二课:CRUD操作http://www.cnblogs.com/aehyok/p/3434578.html
Asp.Net Web API第三课:.NET客户端调用Wep API http://www.cnblogs.com/aehyok/p/3439698.html
前言
消息处理器是一个接收HTTP请求,并返回HTTP响应的一个类。
比较有代表性的时,一系列的消息处理被链接在一起。第一个处理器接收HTTP请求,做一些处理,然后将此请求传给下一个处理器。在某个点上,这个响应被创建,被进行回溯。这种模式就叫做委托处理器。
在客户端,HTTPClient类使用一个消息处理器来处理请求。默认的处理器是HTTPClientHandler,它通过网络发送请求,并从服务器上获得响应。你可以把自定义消息处理器插入到客户端管道中。
Asp.Net Web API也可以使用服务端的消息处理器。更多的信息请参考"HTTP消息处理器"(暂未实现。)
自定义消息处理器
要编写一个消息处理器,需要从System.Net.Http.DelegatingHandler进行派生,并重写SendAsync方法。以下是该方法的签名:
System.Threading.Tasks.Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, System.Threading.CancellationToken cancellationToken);
这个方法以HttpRequestMessage参数作为输入,并异步地返回一个HttpResponseMessage。一种典型的实现如下:
1.处理请求消息。
2.调用base.SendAsync将请求发送给内部处理器。
3.内部处理器返回一条响应消息。(这一步是异步的)
4.处理响应,并把他返回给调用者。
以下示例展示了一个消息处理器,它添加了一个自定义的标头给外部的请求。
public class MessageHandler : DelegatingHandler { private int _count = 0; protected override System.Threading.Tasks.Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, System.Threading.CancellationToken cancellationToken) { _count++; request.Headers.Add("X-Custom-Header", _count.ToString()); return base.SendAsync(request, cancellationToken); } }
对base.SendAsync的调用是异步的。如果处理器在调用之后还要做一些工作,需使用await关键字,以便在方法完成之后继续执行。
以下示例展示了一个对错误码进行日志的处理器。如何进行日志没多大关系,但此例展示了如何得到处理器内部的响应。
public class LoggingHandler : DelegatingHandler { StreamWriter _writer; public LoggingHandler(Stream stream) { _writer = new StreamWriter(stream); } protected override async System.Threading.Tasks.Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, System.Threading.CancellationToken cancellationToken) { var response = await base.SendAsync(request, cancellationToken); if (!response.IsSuccessStatusCode) { _writer.WriteLine("{0} {1} {2}", request.RequestUri,(int)response.StatusCode, response.Headers.Date); } return response; } protected override void Dispose(bool disposing) { if (disposing) { _writer.Dispose(); } base.Dispose(disposing); } }
将消息处理器添加到客户端管线
要将自定义处理器添加到HttpClient,需使用HttpClientFactory.Create方法:
HttpClient client = HttpClientFactory.Create(new MessageHandler());
消息处理器是按照它们传递给Create方法中的顺序来调用的。因此处理器是内嵌的,响应消息以反方向传递。即,最后一个处理器首先得到响应消息。
总结
本文主要讲解HTTPClient消息处理器。涉及到的代码在文中都有过展示,暂时就不进行上传了。
本文参考链接http://www.asp.net/web-api/overview/web-api-clients/httpclient-message-handlers