免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
查看: 4194 | 回复: 1

架构更新 [复制链接]

论坛徽章:
0
发表于 2011-02-09 14:47 |显示全部楼层
这个帖子聊聊我们最近开发项目的技术架构,希望大家多提宝贵意见。

【总的思想】
1、以业务层(领域模型)为核心
2、高内聚、低耦合

【特点】
1、将DAO接口置于业务层;
2、在数据访问层实现DAO接口,PO服务于DAO接口

【分层】
显示层-业务层-数据访问层(下面简称数据层)
业务层:细分为事务层-操作层-实体层-DAO接口,DAO接口进一步分为读接口和写接口
数据层:DAO实现+PO
显示层:这个比较简单,用MVC框架,然后调用业务层即可

【业务层与数据层的关系】
数据层服务于业务层,业务层定义数据访问的接口(DAO接口),数据层来实现,数据层的PO是为了持久化的目的设计的,这也是PO唯一的存在价值,PO不属于业务层范畴,不具备反映业务逻辑的职责,它的活动范围被严格限制在数据层之内,换句话说,无论是业务层还是显示层都不能引用PO。

是否设计PO与所使用的持久化技术有关,如果业务实体能够直接拿来持久化,而且性能没有问题,那么就不需要单独设计PO。总之PO属于数据层的实现细节,业务层的设计可以不考虑PO的任何问题,只管提DAO接口就是了。当然DAO接口只能用业务实体做参数,而不能有PO。

【业务层的设计原则】
事务层:包含事务的业务逻辑。必须定义接口。如果用Spring,则在此层绑定事务
操作层:不包含事务的业务逻辑。必须定义接口
实体层:包含简单的、操作自身和聚合边界内其它实体的业务逻辑。接口定义不是必须的。可变的、不稳定的业务逻辑通过在操作层、事务层应用策略模式等方式解决。
DAO接口:接口的语义仅限于反映实体的持久化操作,比如create、update、delete、findByXXX,DAO接口不能带有业务语义。不遵守这个原则会造成业务逻辑与数据逻辑的混淆,不符合高内聚的最高原则

【依赖关系】
总的依赖方向:显示层->业务层<-数据层
显示层可以引用:事务层、操作层、实体层和读的DAO接口,不可以引用写的DAO接口
事务层可以引用:事务层、操作层、实体层和读写的DAO接口
操作层可以引用:操作层、读的DAO接口和实体层
实体层不可以引用其它任何层的接口,包括DAO,实体的操作限于其聚合边界内

显示层还有一个有趣的技术就是,用Struts的话,将业务实体直接放到FormBean里面作为它的一个JavaBean属性,而不是根据页面定义一大堆String属性,页面通过x.x.x访问对象图的方式绑定数据,这样可以大大简化显示层的开发。(可能很多人都是这么用的,只是我们才刚刚醒悟过来)。至于有人提出的业务层一变,显示层会跟着变的问题,这就看你想让谁依赖谁了,你总要确定一个依赖方向,不可能谁也不依赖谁(变通的办法是再加一层,然后都依赖它,如果你愿意的话……),最开始就讲了,架构总的原则是以业务层为核心,这就决定了其它层都必定是依赖与业务层的,我实在是想不出为什么不能依赖业务层。

关于Service,我不太喜欢这个概念(还有Facade),它真的能起到应有的作用吗?它究竟是让接口变简单了呢还是增加了系统整体的复杂程度?jdk那么复杂,也没什么Service层啊!我们用jdk或者Hibernate的时候就看它的api和reference,那么显示层用业务层的时候,也去看业务层的api和reference不结了?


转:http://www.javaeye.com/topic/11474

论坛徽章:
3
金牛座
日期:2014-06-14 22:04:062015年辞旧岁徽章
日期:2015-03-03 16:54:152015年迎新春徽章
日期:2015-03-04 09:49:45
发表于 2011-02-10 09:05 |显示全部楼层
感觉这个架构设计描述得很模糊
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP