- 浏览: 1680198 次
- 性别:
- 来自: 杭州699号
文章分类
最新评论
-
莫莫摸:
为什么不用dubbo
RCP数据传输模型回顾 -
大胡子爸爸:
String, Class 都实现了Serializable接 ...
RPC框架几行代码就够了 -
lss598018587:
谢谢大神分享,比起新手看复杂的dubbo框架还不如看大神的这一 ...
RPC框架几行代码就够了 -
15606915740:
你好,请问一下。<dubbo:consumer filt ...
Dubbo文档 -
joqk12345:
...
一些设计上的基本常识
转于自己在公司的Blog:
http://pt.alibaba-inc.com/wp/experience_886/software_design_general_knowledge.html
最近给团队新人讲了一些设计上的常识,可能会对其它的新人也有些帮助,
把暂时想到的几条,先记在这里。
1. API与SPI分离
框架或组件通常有两类客户,一个是使用者,一个是扩展者,
API(Application Programming Interface)是给使用者用的,
而SPI(Service Provide Interface)是给扩展者用的,
在设计时,尽量把它们隔离开,而不要混在一起,
也就是说,使用者是看不到扩展者写的实现的,
比如:一个Web框架,它有一个API接口叫Action,
里面有个execute()方法,是给使用者用来写业务逻辑的,
然后,Web框架有一个SPI接口给扩展者控制输出方式,
比如用velocity模板输出还是用json输出等,
如果这个Web框架使用一个都继承Action的VelocityAction和一个JsonAction做为扩展方式,
要用velocity模板输出的就继承VelocityAction,要用json输出的就继承JsonAction,
这就是API和SPI没有分离的反面例子,SPI接口混在了API接口中,
合理的方式是,有一个单独的Renderer接口,有VelocityRenderer和JsonRenderer实现,
Web框架将Action的输出转交给Renderer接口做渲染输出。
2. 服务域/实体域/会话域分离
任何框架或组件,总会有核心领域模型,比如:
Spring的Bean,Struts的Action,Dubbo的Service,Napoli的Queue等等
这个核心领域模型及其组成部分称为实体域,它代表着我们要操作的目标本身,
实体域通常是线程安全的,不管是通过不变类,同步状态,或复制的方式,
服务域也就是行为域,它是组件的功能集,同时也负责实体域和会话域的生命周期管理,
比如Spring的ApplicationContext,Dubbo的ServiceManager等,
服务域的对象通常会比较重,而且是线程安全的,并以单一实例服务于所有调用,
什么是会话?就是一次交互过程,
会话中重要的概念是上下文,什么是上下文?
比如我们说:“老地方见”,这里的“老地方”就是上下文信息,
为什么说“老地方”对方会知道,因为我们前面定义了“老地方”的具体内容,
所以说,上下文通常持有交互过程中的状态变量等,
会话对象通常较轻,每次请求都重新创建实例,请求结束后销毁。
简而言之:
把元信息交由实体域持有,
把一次请求中的临时状态由会话域持有,
由服务域贯穿整个过程。
3. 在重要的过程上设置拦截接口
如果你要写个远程调用框架,那远程调用的过程应该有一个统一的拦截接口,
如果你要写一个ORM框架,那至少SQL的执行过程,Mapping过程要有拦截接口,
如果你要写一个Web框架,那请求的执行过程应该要有拦截接口,
等等,没有哪个公用的框架可以Cover住所有需求,允许外置行为,是框架的基本扩展方式,
这样,如果有人想在远程调用前,验证下令牌,验证下黑白名单,统计下日志,
如果有人想在SQL执行前加下分页包装,做下数据权限控制,统计下SQL执行时间,
如果有人想在请求执行前检查下角色,包装下输入输出流,统计下请求量,
等等,就可以自行完成,而不用侵入框架内部,
拦截接口,通常是把过程本身用一个对象封装起来,传给拦截器链,
比如:远程调用主过程为invoke(),那拦截器接口通常为invoke(Invocation),
Invocation对象封装了本来要执行过程的上下文,并且Invocation里有一个invoke()方法,
由拦截器决定什么时候执行,同时,Invocation也代表拦截器行为本身,
这样上一拦截器的Invocation其实是包装的下一拦截器的过程,
直到最后一个拦截器的Invocation是包装的最终的invoke()过程,
同理,SQL主过程为execute(),那拦截器接口通常为execute(Execution),原理一样,
当然,实现方式可以任意,上面只是举例。
4. 重要的状态的变更发送事件并留出监听接口
这里先要讲一个事件和上面拦截器的区别,拦截器是干预过程的,它是过程的一部分,是基于过程行为的,
而事件是基于状态数据的,任何行为改变的相同状态,对事件应该是一致的,
事件通常是事后通知,是一个Callback接口,方法名通常是过去式的,比如onChanged(),
比如远程调用框架,当网络断开或连上应该发出一个事件,当出现错误也可以考虑发出一个事件,
这样外围应用就有可能观察到框架内部的变化,做相应适应。
5. 扩展接口职责尽可能单一,具有可组合性
比如,远程调用框架它的协议是可以替换的,
如果只提供一个总的扩展接口,当然可以做到切换协议,
但协议支持是可以细分为底层通讯,序列化,动态代理方式等等,
如果将接口拆细,正交分解,会更便于扩展者复用已有逻辑,而只是替换某部分实现策略,
当然这个分解的粒度需要把握好。
6. 微核插件式,平等对待第三方
大凡发展的比较好的框架,都遵守微核的理念,
Eclipse的微核是OSGi, Spring的微核是BeanFactory,Maven的微核是Plexus,
通常核心是不应该带有功能性的,而是一个生命周期和集成容器,
这样各功能可以通过相同的方式交互及扩展,并且任何功能都可以被替换,
如果做不到微核,至少要平等对待第三方,
即原作者能实现的功能,扩展者应该可以通过扩展的方式全部做到,
原作者要把自己也当作扩展者,这样才能保证框架的可持续性及由内向外的稳定性。
7. 不要控制外部对象的生命周期
比如上面说的Action使用接口和Renderer扩展接口,
框架如果让使用者或扩展者把Action或Renderer实现类的类名或类元信息报上来,
然后在内部通过反射newInstance()创建一个实例,
这样框架就控制了Action或Renderer实现类的生命周期,
Action或Renderer的生老病死,框架都自己做了,外部扩展或集成都无能为力,
好的办法是让使用者或扩展者把Action或Renderer实现类的实例报上来,
框架只是使用这些实例,这些对象是怎么创建的,怎么销毁的,都和框架无关,
框架最多提供工具类辅助管理,而不是绝对控制。
8. 可配置一定可编程,并保持友好的CoC约定
因为使用环境的不确定因素很多,框架总会有一些配置,
一般都会到classpath直扫某个指定名称的配置,或者启动时允许指定配置路径,
做为一个通用框架,应该做到凡是能配置文件做的一定要能通过编程方式进行,
否则当使用者需要将你的框架与另一个框架集成时就会带来很多不必要的麻烦,
另外,尽可能做一个标准约定,如果用户按某种约定做事时,就不需要该配置项。
比如:配置模板位置,你可以约定,如果放在templates目录下就不用配了,
如果你想换个目录,就配置下。
9. 区分命令与查询,明确前置条件与后置条件
这个是契约式设计的一部分,尽量遵守有返回值的方法是查询方法,void返回的方法是命令,
查询方法通常是幂等性的,无副作用的,也就是不改变任何状态,调n次结果都是一样的,
比如get某个属性值,或查询一条数据库记录,
命令是指有副作用的,也就是会修改状态,比如set某个值,或update某条数据库记录,
如果你的方法即做了修改状态的操作,又做了查询返回,如果可能,将其拆成写读分离的两个方法,
比如:User deleteUser(id),删除用户并返回被删除的用户,考虑改为getUser()和void的deleteUser()。
另外,每个方法都尽量前置断言传入参数的合法性,后置断言返回结果的合法性,并文档化。
10. 增量式扩展,而不要扩充原始核心概念
参见:http://javatar.iteye.com/blog/690845
------------------------
Dubbo设计分享系列:
谈谈扩充式扩展与增量式扩展
是的,因为Renderer是给扩展者实现的,而Action是给使用者实现的,两者之间不应该互相干扰。
http://pt.alibaba-inc.com/wp/experience_886/software_design_general_knowledge.html
最近给团队新人讲了一些设计上的常识,可能会对其它的新人也有些帮助,
把暂时想到的几条,先记在这里。
1. API与SPI分离
框架或组件通常有两类客户,一个是使用者,一个是扩展者,
API(Application Programming Interface)是给使用者用的,
而SPI(Service Provide Interface)是给扩展者用的,
在设计时,尽量把它们隔离开,而不要混在一起,
也就是说,使用者是看不到扩展者写的实现的,
比如:一个Web框架,它有一个API接口叫Action,
里面有个execute()方法,是给使用者用来写业务逻辑的,
然后,Web框架有一个SPI接口给扩展者控制输出方式,
比如用velocity模板输出还是用json输出等,
如果这个Web框架使用一个都继承Action的VelocityAction和一个JsonAction做为扩展方式,
要用velocity模板输出的就继承VelocityAction,要用json输出的就继承JsonAction,
这就是API和SPI没有分离的反面例子,SPI接口混在了API接口中,
合理的方式是,有一个单独的Renderer接口,有VelocityRenderer和JsonRenderer实现,
Web框架将Action的输出转交给Renderer接口做渲染输出。
2. 服务域/实体域/会话域分离
任何框架或组件,总会有核心领域模型,比如:
Spring的Bean,Struts的Action,Dubbo的Service,Napoli的Queue等等
这个核心领域模型及其组成部分称为实体域,它代表着我们要操作的目标本身,
实体域通常是线程安全的,不管是通过不变类,同步状态,或复制的方式,
服务域也就是行为域,它是组件的功能集,同时也负责实体域和会话域的生命周期管理,
比如Spring的ApplicationContext,Dubbo的ServiceManager等,
服务域的对象通常会比较重,而且是线程安全的,并以单一实例服务于所有调用,
什么是会话?就是一次交互过程,
会话中重要的概念是上下文,什么是上下文?
比如我们说:“老地方见”,这里的“老地方”就是上下文信息,
为什么说“老地方”对方会知道,因为我们前面定义了“老地方”的具体内容,
所以说,上下文通常持有交互过程中的状态变量等,
会话对象通常较轻,每次请求都重新创建实例,请求结束后销毁。
简而言之:
把元信息交由实体域持有,
把一次请求中的临时状态由会话域持有,
由服务域贯穿整个过程。
3. 在重要的过程上设置拦截接口
如果你要写个远程调用框架,那远程调用的过程应该有一个统一的拦截接口,
如果你要写一个ORM框架,那至少SQL的执行过程,Mapping过程要有拦截接口,
如果你要写一个Web框架,那请求的执行过程应该要有拦截接口,
等等,没有哪个公用的框架可以Cover住所有需求,允许外置行为,是框架的基本扩展方式,
这样,如果有人想在远程调用前,验证下令牌,验证下黑白名单,统计下日志,
如果有人想在SQL执行前加下分页包装,做下数据权限控制,统计下SQL执行时间,
如果有人想在请求执行前检查下角色,包装下输入输出流,统计下请求量,
等等,就可以自行完成,而不用侵入框架内部,
拦截接口,通常是把过程本身用一个对象封装起来,传给拦截器链,
比如:远程调用主过程为invoke(),那拦截器接口通常为invoke(Invocation),
Invocation对象封装了本来要执行过程的上下文,并且Invocation里有一个invoke()方法,
由拦截器决定什么时候执行,同时,Invocation也代表拦截器行为本身,
这样上一拦截器的Invocation其实是包装的下一拦截器的过程,
直到最后一个拦截器的Invocation是包装的最终的invoke()过程,
同理,SQL主过程为execute(),那拦截器接口通常为execute(Execution),原理一样,
当然,实现方式可以任意,上面只是举例。
4. 重要的状态的变更发送事件并留出监听接口
这里先要讲一个事件和上面拦截器的区别,拦截器是干预过程的,它是过程的一部分,是基于过程行为的,
而事件是基于状态数据的,任何行为改变的相同状态,对事件应该是一致的,
事件通常是事后通知,是一个Callback接口,方法名通常是过去式的,比如onChanged(),
比如远程调用框架,当网络断开或连上应该发出一个事件,当出现错误也可以考虑发出一个事件,
这样外围应用就有可能观察到框架内部的变化,做相应适应。
5. 扩展接口职责尽可能单一,具有可组合性
比如,远程调用框架它的协议是可以替换的,
如果只提供一个总的扩展接口,当然可以做到切换协议,
但协议支持是可以细分为底层通讯,序列化,动态代理方式等等,
如果将接口拆细,正交分解,会更便于扩展者复用已有逻辑,而只是替换某部分实现策略,
当然这个分解的粒度需要把握好。
6. 微核插件式,平等对待第三方
大凡发展的比较好的框架,都遵守微核的理念,
Eclipse的微核是OSGi, Spring的微核是BeanFactory,Maven的微核是Plexus,
通常核心是不应该带有功能性的,而是一个生命周期和集成容器,
这样各功能可以通过相同的方式交互及扩展,并且任何功能都可以被替换,
如果做不到微核,至少要平等对待第三方,
即原作者能实现的功能,扩展者应该可以通过扩展的方式全部做到,
原作者要把自己也当作扩展者,这样才能保证框架的可持续性及由内向外的稳定性。
7. 不要控制外部对象的生命周期
比如上面说的Action使用接口和Renderer扩展接口,
框架如果让使用者或扩展者把Action或Renderer实现类的类名或类元信息报上来,
然后在内部通过反射newInstance()创建一个实例,
这样框架就控制了Action或Renderer实现类的生命周期,
Action或Renderer的生老病死,框架都自己做了,外部扩展或集成都无能为力,
好的办法是让使用者或扩展者把Action或Renderer实现类的实例报上来,
框架只是使用这些实例,这些对象是怎么创建的,怎么销毁的,都和框架无关,
框架最多提供工具类辅助管理,而不是绝对控制。
8. 可配置一定可编程,并保持友好的CoC约定
因为使用环境的不确定因素很多,框架总会有一些配置,
一般都会到classpath直扫某个指定名称的配置,或者启动时允许指定配置路径,
做为一个通用框架,应该做到凡是能配置文件做的一定要能通过编程方式进行,
否则当使用者需要将你的框架与另一个框架集成时就会带来很多不必要的麻烦,
另外,尽可能做一个标准约定,如果用户按某种约定做事时,就不需要该配置项。
比如:配置模板位置,你可以约定,如果放在templates目录下就不用配了,
如果你想换个目录,就配置下。
9. 区分命令与查询,明确前置条件与后置条件
这个是契约式设计的一部分,尽量遵守有返回值的方法是查询方法,void返回的方法是命令,
查询方法通常是幂等性的,无副作用的,也就是不改变任何状态,调n次结果都是一样的,
比如get某个属性值,或查询一条数据库记录,
命令是指有副作用的,也就是会修改状态,比如set某个值,或update某条数据库记录,
如果你的方法即做了修改状态的操作,又做了查询返回,如果可能,将其拆成写读分离的两个方法,
比如:User deleteUser(id),删除用户并返回被删除的用户,考虑改为getUser()和void的deleteUser()。
另外,每个方法都尽量前置断言传入参数的合法性,后置断言返回结果的合法性,并文档化。
10. 增量式扩展,而不要扩充原始核心概念
参见:http://javatar.iteye.com/blog/690845
------------------------
Dubbo设计分享系列:
谈谈扩充式扩展与增量式扩展
评论
10 楼
joqk12345
2018-02-26
9 楼
wuhukui8369
2016-11-23
文章最后提到的 幂等性 和 命令 ,我平时设计的时候,有的时候考虑到网络开销而放在了一起。现在想想,接口的简洁更加重要。而且粒度更加细一点,可以供外部更加灵活的重用。
8 楼
aaa110
2015-02-06
请问楼主可以推荐一些书看看吗?
7 楼
liu0013
2014-05-18
6 楼
bin_1715575332
2014-01-10
好文章!!!!必须顶
5 楼
wuchienchao
2013-11-20
从dubbo和您的文章中学习到太多太多,由衷感谢楼主的博学和奉献精神。
祝愿楼主事业有成、身体健康。
祝愿楼主事业有成、身体健康。
4 楼
javatar
2011-06-01
wu_yong988 写道
关于 API与SPI分离 不是很理解!
Renderer接口 就是SPI?
Renderer接口 就是SPI?
是的,因为Renderer是给扩展者实现的,而Action是给使用者实现的,两者之间不应该互相干扰。
3 楼
wu_yong988
2011-05-30
关于 API与SPI分离 不是很理解!
Renderer接口 就是SPI?
Renderer接口 就是SPI?
2 楼
flykk
2010-08-26
刚学习了struts的拦截器,对第一条深有感触。楼主的总结真的很好。学习了!
1 楼
sarstime
2010-08-20
实践中宝贵的经验,谢谢分享
发表评论
-
能力成长模型
2012-05-09 00:28 22667最近看了温伯格1986年出版的《技术领导之路》, 很老的书,讲 ... -
以HTTL为例讲讲模块分包&领域模型&扩展框架
2011-10-09 20:08 16445注:该博客内容已加入 ... -
使用Map参数的Webx3扩展
2011-08-28 02:10 5852因Webx3是开源的,所以把这个简单的Webx3扩展发在博客上 ... -
Netty内存泄露
2011-08-02 20:09 24865转于自己在公司的Blog: ... -
Grizzly和Netty以及Mina简单性能对比
2011-07-17 02:48 29611转于自己在公司的Blog: http://pt.alibaba ... -
RPC框架几行代码就够了
2011-07-14 00:34 89494转于自己在公司的Blog: http://pt.alibaba ... -
魔鬼在细节中
2011-05-24 14:50 32255转于自己在公司的Blog: ... -
Dubbo扩展点重构
2011-05-12 22:09 38759转于自己在公司的Blog: http://pt.alibaba ... -
配置设计
2011-03-09 23:41 23430转于自己在公司的Blog: ... -
[转]HTML5设计原理
2011-03-09 22:57 7653Jeremy Keith在 Fronteers 2010 ... -
Hessian序列化不设SerializerFactory性能问题
2010-12-27 11:38 6380转于自己在公司的Blog: http://pt.alibaba ... -
动态代理方案性能对比
2010-11-17 21:38 45630转于自己在公司的Blog: http://pt.alibaba ... -
防痴呆设计
2010-11-05 18:58 17510转于自己在公司的Blog: ... -
负载均衡扩展接口重构
2010-11-05 18:53 8628转于自己在公司的Blog: ... -
分布式服务框架常被质疑的价值
2010-11-05 18:52 5677转于自己在公司的Blog: http://pt.alibaba ... -
Hessian3.2.1在序列化32.5k字符串时的问题
2010-11-05 18:49 7113转于自己在公司的Blog: http://pt.alibaba ... -
谈谈扩充式扩展与增量式扩展
2010-06-12 19:46 18966转于自己在公司的Blog: http://pt.alibaba ... -
Scaling Architecture
2010-02-25 10:31 4052Scaling Second Life: http://p ... -
EBay SOA
2010-02-23 18:23 4735EBay SOA PPT -
服务化基础设施
2009-11-15 23:11 6216服务化,也可以叫SOA, ...
相关推荐
电子设计基础知识,其中包括一些学术名词等。
一些硬件设计基础知识总结.docx一些硬件设计基础知识总结.docx
PCB板就是把设计好的原理图变成一块实实在在的PCB电路板,请别小看这一过程,有很多原理上行得通的东西在工程中却难以实现,或是别人能实现的东西另一些人却实现不了,因此说做一块PCB板不难,但要做好一块PCB板却不是一...
关于virtuoso layout设计的一些你必须知道的基础知识问题
计算机的一些语言的简介(主要以Java为主)简单易懂,非常适合初学者,学校的课程资源,制作成PDF格式,分十二个章节:第一章 JAVA语言简介、第二章 Java的图形界面、第三章 流与Java中的文件操作、第四章 数据库...
同时,在嵌入式的一些基础知识题目的解题中,也需要一定电子电路设计的基础知识。电子电路设计的基础知识可以写成几本书,但是不要害怕。正是如此,考试考查的只可能是重要概念、基础知识和基本技能。过去的真题也...
文章介绍了一些基础的电子电路设计的知识。
该资料主要讲了一些网页制作的基本知识,对初学者很用用,对有一定基础的可以作为参考资料
Protel 印制电路板设计 第9讲 PCB设计基础及简单PCB设计 主 要 内 容 一、PCB编辑器 二、PCB设计基本组件 三、PCB工作层 四、规划PCB 五、设置PCB元件库 六、元件封装放置与布局调整 七、放置焊盘、过孔 八、手工...
本文档主要介绍了电路一些基本的元器件,如电阻电容的概念和应用,以及在单片机中的应用
《算法设计与分析基础(第3版)》十分适合用作算法设计和分析的基础教材,也适合任何有兴趣探究算法奥秘的读者使用,只要读者具备数据结构和离散数学的知识即可。 目录 第1章绪论 1.1什么是算法 习题1.1 1.2算法问题...
c语言的基础知识点,关于顺序程序设计的一点经验
1:什么是二极管的正偏?在p节加正电压,而n节加负电压。即为正偏。 正偏是扩散电流大大增加,反偏使漂移电流增加。但是漂移电流是由于少子移动形成的,所以有反向饱和电流! 2:一般低频信号,电阻线的粗细是为了流...
平面设计专题:版式设计基础知识,做美工的都要用的一些知识
大一期末考复习资料,包括详细知识点,程序题,一些经典的程序题
鉴于此目的,我们编写了一些重要的设计模式,并以编目分类的形式将它们展现出来。 内容简介 《设计模式:可复用面向对象软件的基础》是引导读者走出软件设计迷宫的指路明灯,凝聚了软件开发界几十年设计经验的结晶。...
计算机辅助建筑设计:3D 计算机图形学的一些基础知识.pptx
主要内容包括程序设计基础知识、类与对象的基本概念、继承与多态、输入输出流,以及泛型程序设计。此外,本教材还介绍了一些常用数据结构基础知识,使得读者学习本书后,能够解决一些简单的实际问题。整套教材语言...
1、通过本次课程设计可以灵活运用单片机的基础知识,依据课程设计内容,能够完成从硬件电路图设计,到电路搭建焊接,再到软件编程及系统调试实现系统功能,完成课程设计,加深对单片机基础知识的理解,并灵活运用,...
详细说明了包括嵌入式系统的一些基础概念、计算机的基础知识、数字逻辑电路基础、微处理器原理和接口技术、嵌入式软件设计、实时操作系统的各种概念和相关理论、软件设计和项目管理、需求分析和软件测试、系统设计和...