banq大哥,请用DDD来分析下我的架构是否有问题,谢谢.

08-03-11 tianhaoleng
小弟目前的系统架构如下:
SSH框架搭建

首先是持久化层,有一个Service接口,里面有SaveAnything(Object ob){}
QueryAll();等通用的方法.这个接口用于满足持久化的一系列操作.
ServiceImp类实现了Service接口.它是持久化的真正实现者.

二,模型:一些bean,由业务需求抽象而来,里面基本是getter、setter方法。

三、 Struts的Action：具体用来响应用户请求，调用Service接口，进行增查改删操作。把返回的对象或者对象序列存到request 或session范围，进行显示。

我特别不清楚的是，struts的action在DDD中属于哪个层呢?

我该怎么改进我的架构呢，请指教！

tianhaoleng
2008-03-12 13:39
人好少啊~自己顶下

tianhaoleng
2008-03-12 20:43
大哥,小弟第一次在贵站发贴,给点关注吧……

banq
2008-03-12 20:44
>首先是持久化层,有一个Service接口
Service接口属于业务层，凌驾于持久化层以上，不能两者混熊。

>struts的action在DDD中属于哪个层呢
struts属于MVC框架，是界面层的实现，Action当然属于MVC中的Controller。

模式是分层架构的基础。

tianhaoleng
2008-03-12 23:02
但是我的系统仅仅就是增查改删这些动作,我的Service层应该处理些什么呢,或者说一般系统的service层的用途是什么.

我直接在Action中进行对持久化层方法的调用,比方说有两个实体是一对多关系,我在Action中建立他们两个的关系，然后直接在Action中调用持久化层的方法，将这个两个关联实体通过HIbernate持久化到数据库．

我的思路对吗，如果错，那么正确的做法是怎样的呢？

fw2003
2008-03-13 10:47
我的建议
对于一般小型项目
你可以这样做
设计一个基类DAO 如BaseDAO之类的 在里面把常用的获得日志 增删改查 分页 条件修改查询删除都写上
然后对应每个模型写一个DAO接口和具体的实现类
实现类实现接口并继承BaseDAO 在具体的方法里只需要调用父类BaseDAO的方法传入相应参数即可

这样做的好处我觉得很明显 层次分明 真正达到接近组件化的效果 举个例子 我甚至可以将持久层打成JAR包 然后交给写业务的人 他只需要导入包 查看我写的注释文档
自己调用或组装多个方法完成业务 他甚至不需要懂SQL或HQL 因为SQL或HQL是在持久层里就写死了的

然后业务层很好做 每个模型分别对应一个业务接口和实现类

最后就是在action里通过set业务层接口的方式注入业务实现类调用业务方法 然后在业务实现类里通过set持久层接口的方式注入DAO实现类调用DAO方法 当然也可以自己组装多个完成较复杂的业务

至于你说的系统仅仅是增删改查 好象有直接在action里调用DAO的倾向
但这是错误的 就算业务再简单 也应该分离出业务层 因为你无法预见将来系统因为需求变更会扩展出什么样的功能
这其实好比19世纪的火车 刚出现时就一个火车头或者说一节车厢 随着乘客越来越多 车厢会慢慢加长 但是火车不可能一直走直线 也是需要转弯的 车厢过长肯定会产生影响 那最后怎么解决的呢 很简单 如果一开始就将火车设计为很多节车厢 那么就算在起点站发车的时候没装满 但是到了每一站后都只需要让新乘客各自进入指定的车厢就可以了
在JDON潜水很久了 学到很多 也避免了实际开发中的一些弯路
我强烈支持banq的软件的生命在于可伸缩性和维护性!!!
很多失败的项目，并不是指功能没有实现，没有做出来，而是指的在后期陷入了需求变更的泥潭，系统臃肿不堪，牵一发而动全身，拆东墙补西墙的现象比比皆是。计划总是没有变化快，为了最大限度的降低需求变更的风险，必须在设计阶段考虑周全。

[该贴被fw2003于2008-03-13 10:55修改过]

[该贴被fw2003于2008-03-13 10:56修改过]

tianhaoleng
2008-03-13 13:33
如果我没理解错的话,楼上大哥的意思是把一个大的DAO类做基础的DAO类,然后根据不同的业务模块做新的DAO类,并继承基础DAO类来达到复用.

我目前的复用比较有意思,我把基础DAO类的一些可变参数,如:HQL语句等设置为变量,然后延迟到actoin中对DAO方法调用的时候,通过DI注入不同的HQL语句.

如此,比方说我做一个查询的action,反正这类action的功能都是把查询出来的LIST放到httpsession里,然后在JSP上迭代显示,对两个不同实体进行查询的action,往往只有HQL语句不同而已,于是,我只写一个基础的查询action,这个action具体查询出哪些内容是由DI注入的HQL来决定的,也就是说,我注入不同的HQL,这个action就成了不同功能的查询action了,然后我在spring配置文件中,声明多个action名,但实际type都指向的是这一个基础的查询action类,只是注入的HQL不同.这样,一个action不就能完成所有的集体查询功能了吗?

不知道我这个做法是对还是错.请指教.

还有,我们一直在讨论的都是DAO层,那么我要怎么做,才能分离出我的服务层呢?

fw2003
2008-03-14 09:27
呵呵
WEB层传入SQL或HQL 或者业务层传入 稍微正规点的公司都会被骂得很惨吧
如果我没猜错 你写了一个类似 public List find(String hql)的方法吧 我刚工作时一开始也这样做 还觉得很灵活 而且仅仅是在service里传的 但是都被老大骂得很惨
一个方法 传入返回要有明确的说明 比如 find(Map map)到底是传什么进去呢
LZ你现在是一个人在做吧 可能不能体会到分层的重要性 其实如果真正是一个人从头到尾一直负责的话 那么有没有想过回到最原始的所有东东统统写在JSP里又何尝不可呢

至于业务层做什么 调用持久层
具体的我上面阐述得很明白了

"我甚至可以将持久层打成JAR包 然后交给写业务的人 他只需要导入包 查看我写的注释文档
自己调用或组装多个方法完成业务 他甚至不需要懂SQL或HQL 因为SQL或HQL是在持久层里就写死了的"

LZ可以看这个http://www.jdon.com/article/27452.html

[该贴被fw2003于2008-03-14 09:29修改过]

[该贴被fw2003于2008-03-14 10:37修改过]

tianhaoleng
2008-03-14 13:41
谢谢fw2003大哥，我懂了。现在就改进我的代码！

killer
2008-03-24 09:27
To tianhaoleng：
首先要明白DDD和架构是两个概念，DDD是领域驱动设计，讲的是如何进行业务领域建模，是系统的核心，架构是指一个系统的逻辑组织结构，实际上是业务领域模型的一个运行支撑环境，楼主所说的SSH正是这样的一个运行支撑环境。

>>>二,模型:一些bean,由业务需求抽象而来,里面基本是getter、setter方法。
业务对象有数据属性，也有行为，属性决定行为，但不一定全是getter、setter方法。

>>>三、 Struts的Action：具体用来响应用户请求，调用Service接口，进行增查改删操作。把返回的对象或者对象序列存到request 或session范围，进行显示。

Action是属于展现层的，不能直接跨越业务层直接调用数据持久化的接口。

>>>我特别不清楚的是，struts的action在DDD中属于哪个层呢?
只能说action在架构中属于哪个层，你这个问题和DDD没什么关系。

架构最重要的是要层次清晰，各层职责明确，只有这样才能灵活扩展。