可能是我们共同的强迫症，不要说看到，就算想到太多的try-catch也很难接受。
于是，开始了一些尝试，这些尝试都算是思维的锻炼、场面的见识、经验的积累。
Version1 —— 原始版本
一开始，在ConcreteService中，拥有了太多的try-catch，而影响码字的兴趣。
代码1 原始代码
/// <summary>
/// 契约
/// </summary>
public interface IUpdateManyManyThingContract
{
bool UpdateSth1(DataSet ds);
bool UpdateSth2(DataSet ds);
bool UpdateSth3(DataSet ds);
bool UpdateSth4(DataSet ds);
//...
}
/// <summary>
/// 服务实现
/// </summary>
public class ConcreteService : IUpdateManyManyThingContract
{
private IDao m_Dao;
public bool UpdateSth1(DataSet ds)
{
try
{
var dt = ds.First();
if (!dt.HasElements()) return true;
foreach (DataRow row in dt.Rows)
{
//构造
var entity = new Branch(row);
m_Dao.SaveOrUpdate(entity);
}
return true;
}
catch (Exception ex)
{
Logger.Log(ex);
return false;
}
}
public bool UpdateSth2(DataSet ds)
{
try
{
}
catch (Exception)
{
}
}
public bool UpdateSth3(DataSet ds)
{
throw new NotImplementedException();
}
public bool UpdateSth4(DataSet ds)
{
throw new NotImplementedException();
}
//many update methods,many try-catches...
}
如上代码，UpdateSth函数里面都需要实现一个try-catch，而觉得恶心到自己了。
Version2——(Extract Method)提取方法 + Func
于是，基于自己的积累，开始了重构的第一个版本。
针对这个服务（ConcreteService）的特殊性，定制了一个专门的方法进行控制——TrycatchBlock。
代码2 提取方法片段
/// <summary>
/// 服务实现
/// </summary>
public class ConcreteService : IUpdateManyManyThingContract
{
private IDao m_Dao;
public bool UpdateSth1(DataSet ds)
{
return TrycatchBlock(() =>
{
var dt = ds.First();
if (!dt.HasElements()) return true;
foreach (DataRow row in dt.Rows)
{
//构造
var entity = new Branch(row);
m_Dao.SaveOrUpdate(entity);
}
return true;
});
}
public bool UpdateSth2(DataSet ds)
{
return TrycatchBlock(() =>
{
//...
return true;
//...
//return false;
});
}
public bool UpdateSth3(DataSet ds)
{
throw new NotImplementedException();
}
public bool UpdateSth4(DataSet ds)
{
throw new NotImplementedException();
}
//many update methods,many try-catches...
//try-catch控制块
private bool TrycatchBlock(Func<bool> body)
{
try
{
return body();
}
catch (Exception ex)
{
Logger.Log(ex);
return false;
}
}
}
是的，这是一次进步，将所有的try-catch的功能职责都集中到了一个函数里面，也方便调试了。
但是，还得每个方法都加上一句：return TrycatchBlock(() => { 。。。 })。
从本质上来说，还是在进行中重复。
Version3——过滤器思想（否决）
经过老大的指点：考虑MVC中的类似FilterAttribute的注解。
思路演进：MVC中，有一个HandErrorAttribute的特性，用于拦截控制器或者动作的异常。。。。。。对，这是个思路，但过了没多久，我就放弃了。
放弃理由：“Request请求——>路由数据——>ControllerInvoker——>反射调用Controller或Action。”，这里面用了很多元数据（***Descriptor，***Invoker等）手段，实现难度不小。
另外，我需要的是“instance.MethodAction”（对象直接调用方法）的方式，因为是为WCF直接提供服务（WCF会根据配置文件中服务的名称创建服务），不需要使用反射进行动态调用。
Version4——动态代理
浏览网页的过程中，想起动态代理——Castle Dynamic Proxy，是的，Moq，Spring.net等一系列优秀的框架中引用到了它。
V4.1.使用中间层
想起一个老外曾经说过的一句话“计算机的任何问题，都可以通过一个中间层来解决”，当然，这里的中间层，是一个广泛和抽象的概念，比如，中间1号调中间2号、中间2号调目标，可能是一个递归的结构也说不定。
于是使用interceptor继续一个版本：
代码3：中间层——ConcreteServiceProxy；拦截器——ServiceDynamicProxyInterceptor。
/// <summary>
/// 服务实现
/// </summary>
public class ConcreteService : IUpdateManyManyThingContract
{
private IDao m_Dao;
public bool UpdateSth1(DataSet ds)
{
var dt = ds.First();
if (!dt.HasElements()) return true;
foreach (DataRow row in dt.Rows)
{
//构造
var entity = new Branch(row);
m_Dao.SaveOrUpdate(entity);
}
return true;
}
public bool UpdateSth2(DataSet ds)
{
//...
return true;
//...
//return false;
}
public bool UpdateSth3(DataSet ds)
{
throw new NotImplementedException();
}
public bool UpdateSth4(DataSet ds)
{
throw new NotImplementedException();
}
//many update methods,many try-catches...
}
public class ConcreteServiceProxy : IUpdateManyManyThingContract
{
private ConcreteService m_Service;
public ConcreteServiceProxy()
{
m_Service = ServiceDynamicProxyInterceptor.CreateServiceProxy<ConcreteService>();
}
public bool UpdateSth1(DataSet ds)
{
return m_Service.UpdateSth1(ds);
}
public bool UpdateSth2(DataSet ds)
{
return m_Service.UpdateSth2(ds);
}
public bool UpdateSth3(DataSet ds)
{
return m_Service.UpdateSth3(ds);
}
public bool UpdateSth4(DataSet ds)
{
return m_Service.UpdateSth4(ds);
}
}
public class ServiceDynamicProxyInterceptor : IInterceptor
{
/// <summary>
/// 工厂方法
/// </summary>
/// <typeparam name="T">服务类型</typeparam>
/// <returns>一个经过代理的服务</returns>
public static T CreateServiceProxy<T>() where T : class
{
ProxyGenerator generator = new ProxyGenerator();
ServiceDynamicProxyInterceptor interceptor = new ServiceDynamicProxyInterceptor();
T entity = generator.CreateClassProxy<T>(interceptor);
return entity;
}
public void Intercept(IInvocation invocation)
{
try
{
invocation.Proceed();
}
catch (Exception ex)
{
Log.Error(ex.Message);
invocation.ReturnValue = false;
}
}
}
上述代码是一目了然，使用m_Service = ServiceDynamicProxyInterceptor.CreateServiceProxy<ConcreteService>();就得到一个代理过的对象，也就能够进行拦截。
多了一个中间层——ConcreteServiceProxy，层次分明了，但是代码同样没有减少，这个似乎又看起来多次一举。
况且还要改配置文件，WCF的配置，如下下划线部分。
<service name="MyNameSpace.Service.ConcreteServiceProxy" behaviorConfiguration="WFServiceBehavior">
V4.2.IOC版
到使用中间层为止，我已经是能够接受的了。但老大觉得还可以再精简，确实是经验丰富，又被指点了，然后提点我使用IOC，目标是去除中间层——ConcreteServiceProxy。
思路：
1） 先使用动态代理创建一个被代理过的（Proxied）ConcreteService对象；
2） 将此对象放入IOC中（如Autofac，Unity等）；
3） 如果需要使用ConcreteService类型的实例，从IOC中获取即可。
注：（去除了中间层——ConcreteServiceProxy；同时ConcreteService不用加try-catch；也不用改配置文件了）
代码4：去除了中间层——ConcreteServiceProxy；同时ConcreteService不用加try-catch；也不用改配置文件了
public class DependencyRegistrar : IDependencyRegistrar
{
public virtual void Register(ContainerBuilder builder, ITypeFinder typeFinder)
{
var proxiedService = ServiceDynamicProxyInterceptor.CreateServiceProxy<ConcreteService>();
builder.Register(c => proxiedServicec).As<ConcreteService>().InstancePerRequest();
}
public int Order
{
get { return 0; }
}
}
一次多好的体验啊！！！
用DP（Dynamic Proxy）完成了拦截；用IOC完成了DI。
写到这里，问题来了，WCF能够通过配置文件配置的服务名称，即MyNameSpace.Service.ConcreteService，自动去IOC中找到被代理的对象吗？Autofac.WCF能不能帮助它完成呢？
（附）动态代理链接：
http://docs.castleproject.org/Tools.DynamicProxy.ashx
http://www.cnblogs.com/daxnet/archive/2011/09/07/2169520.html
http://www.cnblogs.com/RicCC/archive/2010/03/15/castle-dynamic-proxy.html
总结：就先写到这里，体验的感觉哪怕就是一点点，也很爽！欢迎拍砖。
重构实践——为了try-catch大兴排场