请问一下这样分层对不对

10-03-04 cmzx3444

现在做一个系统，框架就用spring 打算这样分层

dao:只负责数据的持久化以及查询

cache：领域对象存放的地方

repository：数据的入口与出口，负责保存数据到cache，根据需要来持久化数据，以及取出cache中的领域对象给上层使用

service：提供给客户端的接口
不知道这样合理不，以前公司的项目都是一个泛型dao，然后所有的操作都在action中，有的action都几乎上千行了，让我很奔溃啊。

我现在还有个以为就是，客户端调用的只能是service层暴露的接口，那service层的接口会不会太细了，会有很多方法。这个怎么避免呢？

yinyousong

2010-03-05 09:20

嫌细就把service暴露给view

banq

2010-03-05 09:25

2010年03月04日 12:48 "cmzx3444"的内容

然后所有的操作都在action中，有的action都几乎上千行了，让我很奔溃啊。

当你使用了Service以后，也要防止所有操作都写在Service中，有的Service也会几乎上千行，让你更崩溃。

所以，关键是从对象职责角度切分这些操作，将这些操作划归到各个领域对象中。

见对象的责任与职责

如何从职责和协作中发现丰富对象？

DCI架构可以解决贫血模型

[该贴被banq于2010-03-19 09:22修改过]

IceQi

2010-03-20 00:45

LZ提到了Service接口，也想到了接口可能带来的负面效果。

接口的设计需要考虑到多种因素，比如：
@ 接口的稳定性：当具体的操作过程发生变化的时候，原先定义的接口在多大程度上可以重用？
@ 接口的复杂性：是否因为接口的过于复杂而造成了客户端调用的困难？
@ 接口的定义清晰：是否因为一个接口的业务定义不够清晰，导致了参数、结果的不确定？
等等，还有很多。

很多时候定义接口就是权衡的过程，有所得也有所失最后找到了一个相对的平衡。

具体到接口的细化程度，当你发觉一套接口过于细枝末节和繁杂的时候也许就是应该返回头看一看是否到了重构和分离服务的时刻了。

phoenix2121

2010-04-16 15:09

2010年03月05日 09:25 "banq"的内容

LZ提到了Service接口 ...

初学MVC就跟LZ一样,但当工作以后,发现公司框架就如bankq所言,role来确定角色,chain来控制流程,template来调用业务(action),channel来控制输出,数据封装到context(上下文),我只需要简单配置bean,写一些action即可.

可是这样做,让我这样的初级开发人员,不像开发,更像是代码拼凑,太简单了,而框架的源码又不开放,导致我现在很迷茫.曾经很想钻研公司框架,奈何只能参透0.001的东西.虽然知道公司内部框架very good,但是我实在是学不到东西.请banq指点一二.谢谢