AOP基础框架的选择

这里我选择了Castle，Castle可以动态创建接口的实现类并实例化，可以对接口方法调用前进行拦截，并设置返回结果。

我们可以根据这个拦截功能，收集每个面的配置，组装为http请求消息，然后调用HttpClient为完成发送请求，再让第5个面来进行回复结果处理。基于Castle与HttpClient，我们就可以封装出支持AOP的HttpClient新框架，这里命名为WebApiClient吧。

 

WebApiClient设计

现在，我们的目标是，让调用WebApi与编写WebApi一样，声明接口、参数、返回值，打上请求方法与路径（面）特性、返回结果处理（面）特性、请求内容（面）特性。然后框架帮我们实现并取得实例，然后就可以调用这些接口了。

Net的服务端应用AOP很常见，在Asp.net MVC与Asp.net WebApi等新框架里到处都有AOP的影子，我们可以把一个服务方法“切”为很多面，日志面、验证面、请求方式处理、接口业务实现等多个面，有一些面可以使用过滤器特性(FilterAttribute)进行编写，然后很方便和打上特性即可，对于一般的工程师，只需要专注实现接口业务实现。

在流行SOAP的年代，很少需要一个强悍的Client，而今天restful时代，.net也出了一个HttpClient，可以说是与Asp.net WebApi相配吧，虽然HttpClient相对WebClient在http接口请求有了质的变化，但相比服务端的webApi，AOP的影子都不见了。