面向服务架构~面向服务的API是统一接口还是具体业务使用具体的接口?
2012-05-23 23:30
381 查看
前言说明:这里说的"接口"并不是C#时的interface,而一般指定一个方法签名,它一般为外部提供一个GET请求,接口到请求后,进行处理,然后对调用方进行信息的返回.
回到本题中来,事件上,我们坐下来,认真去想想,还是统一接口的比较好,如果要具体业务使用具体接口,那它的具体接口肯定也是去再调用一下"那个统一的入口模块"的,注意,这里我说的是"模块",而不是"接口,类,方法等"
大体流程应该是这样:
客户端调用某个服务接口
接口系统
调用某体业务前的逻辑
创建一个具体业务
调用某体业务后的逻辑
返回给客户端
对于一个服务端的代码要求应该是这样:
1 接口对外具有稳定性
2 对自己具体很好的扩展性(开闭原则)
3 每种具体业务都是独立的(单一职责原则)
对于上述要求,我设计如下代码:
通过上面代码,我们可以看到,对外统一UserAPI是稳定的,当业务有变化直接修改具体业务即可,客户端平台不用修改,而AddBuyingNews和AddUserLevel这两个类型是实现各自业务的,它们之间是独立的,功能是单一的,这符合单一职责,而如果服务层希望扩展新的业务只要建立一个新类型即可,对外统一接口UserAPI不用改变,因为具体业务已经通过反射实现了松耦合,有人说反射会对性能有很大的影响,事实上,不是这样的,细心的朋友可以看一下.net自己的托管的类库,用了大量的反射,为何要用反射?我会在另一篇文章中去说明,今天主要讲的就是这些,呵呵.
回到本题中来,事件上,我们坐下来,认真去想想,还是统一接口的比较好,如果要具体业务使用具体接口,那它的具体接口肯定也是去再调用一下"那个统一的入口模块"的,注意,这里我说的是"模块",而不是"接口,类,方法等"
大体流程应该是这样:
客户端调用某个服务接口
接口系统
调用某体业务前的逻辑
创建一个具体业务
调用某体业务后的逻辑
返回给客户端
对于一个服务端的代码要求应该是这样:
1 接口对外具有稳定性
2 对自己具体很好的扩展性(开闭原则)
3 每种具体业务都是独立的(单一职责原则)
对于上述要求,我设计如下代码:
/// <summary> /// 对外统一接口模块 /// </summary> public class SOA : Controller { /// <summary> /// 统一接口方法,外面可以使用GET请求 /// </summary> /// <param name="blockName"></param> /// <param name="param"></param> /// <returns></returns> public ContentResult UserAPI(string blockName, string param) { IAPI create = (IAPI)System.Reflection.Assembly.Load("dll").CreateInstance("namespace" + blockName); if (create.Create(param)) return Content("成功"); else return Content("失败"); } } /// <summary> /// 建立API指定接口规范 /// </summary> internal interface IAPI { bool Create(string param); } /// <summary> /// 添加购买动态的服务 /// </summary> internal class AddBuyingNews : IAPI { public bool Create(string param) { return true; } } /// <summary> /// 添加用户等级的服务 /// </summary> internal class AddUserLevel : IAPI { public bool Create(string param) { return true; } }
通过上面代码,我们可以看到,对外统一UserAPI是稳定的,当业务有变化直接修改具体业务即可,客户端平台不用修改,而AddBuyingNews和AddUserLevel这两个类型是实现各自业务的,它们之间是独立的,功能是单一的,这符合单一职责,而如果服务层希望扩展新的业务只要建立一个新类型即可,对外统一接口UserAPI不用改变,因为具体业务已经通过反射实现了松耦合,有人说反射会对性能有很大的影响,事实上,不是这样的,细心的朋友可以看一下.net自己的托管的类库,用了大量的反射,为何要用反射?我会在另一篇文章中去说明,今天主要讲的就是这些,呵呵.
相关文章推荐
- 面向服务体系架构的业务规划和建模方法系列之五——SOA项目中IBM产品的采用 推荐
- “.NET技术”使用WCF实现SOA面向服务编程—— 架构设计
- 移动端API架构 统一Proxy还是各自为政?
- 使用WCF实现SOA面向服务编程—— 架构设计
- 使用WCF实现SOA面向服务编程—— 架构设计
- Spring Cloud Spring Boot mybatis分布式微服务云架构(四十)使用AOP统一处理Web请求日志(1)
- 使用WCF实现SOA面向服务编程—— 架构设计
- 使用WCF实现SOA面向服务编程—— 架构设计
- 大数据架构中使用JSON-RPC好,还是RESTful API好?
- 使用 WebSphere Business Services Fabric 创建面向服务的灵活业务解决方案,第 1 部分:概述
- 架构实战项目心得(九):后台服务工具ldap:统一用户中心ldap工具使用以及安装
- 面向服务体系架构和业务组件的思考
- 使用dubbo与zookeeper搭建面向服务的架构工程
- 使用WCF实现SOA面向服务编程—— 架构设计
- 面向服务体系架构的业务规划和建模方法系列之二--基础概念辨析 推荐
- Asp.net 面向接口可扩展框架之使用“类型转化基础服务”测试四种Mapper(AutoMapper、EmitMapper、NLiteMapper及TinyMapper)
- 使用WCF实现SOA面向服务编程—— 架构设计
- 使用Swoole 构建API接口服务
- 使用WCF实现SOA面向服务编程—— 架构设计
- 面向服务体系架构的业务规划和建模方法系列之三--SOA方法裁减样例 推荐