这样设计有有关问题呢？ 请指正，多谢
这样设计有问题呢？ 请指正，谢谢
采用struts+spring+hibnerate框架，下面是我初步设计的草图，希望大家指出其中存在的问题，谢谢
有时候不一定为了分层而分层
如果项目比较小的话,把数据访问层、逻辑层合在一起,也未尝不可
纵向分工，工作的内容业务相关性比较强。
采用struts+spring+hibnerate框架，下面是我初步设计的草图，希望大家指出其中存在的问题，谢谢
1 楼
dada
2007-01-01
结构上没有问题。
问题问的太大，不知道你是指哪方面的问题?
问题问的太大，不知道你是指哪方面的问题?
2 楼
dzgwt2004
2007-01-01
横向：采用三层：数据访问层、逻辑层、表示层
纵向：根据不同的模块划分，另外提供一个共用的基类Base***
不知道各位一般设计整体框架是这样的么？
纵向：根据不同的模块划分，另外提供一个共用的基类Base***
不知道各位一般设计整体框架是这样的么？
3 楼
dada
2007-01-01
和你的差不多，如果项目小或者开发周期短则抛弃DAO层
4 楼
lane_cn
2007-01-01
表面上看各层次很全，但各层次不是按照业务概念来制定的，而是根据技术特点来制定的。本质上讲这样和jsp－database没有实质区别。估计你也是“老板让我用xxx”的设计方式。
别怕，大家一开始都一样，我也是。
别怕，大家一开始都一样，我也是。
5 楼
zqc53
2007-01-01
BaseService做什么用？比较感兴趣这个
6 楼
lighter
2007-01-02
dzgwt2004 写道
横向：采用三层：数据访问层、逻辑层、表示层
纵向：根据不同的模块划分，另外提供一个共用的基类Base***
不知道各位一般设计整体框架是这样的么？
纵向：根据不同的模块划分，另外提供一个共用的基类Base***
不知道各位一般设计整体框架是这样的么？
有时候不一定为了分层而分层
如果项目比较小的话,把数据访问层、逻辑层合在一起,也未尝不可
7 楼
dzgwt2004
2007-01-02
首先谢谢各位的支持！
BaseService是将每个***Service抽出的公共部分，作为基类。
因为我们项目是按照那个图纵向分工的，BaseAction、BaseService、BaseDAO,这三层也作为一个纵向（一个模块），来分给对业务比较熟悉的人，其余的纵向（模块）分给对模块比较熟悉的
里面的Base***都是提供出来的公共部分而已。
本来我以为可以横向分工的，就是说表示层，逻辑层，数据访问层这样划分任务的，可惜被我们头驳回……
zqc53 写道
BaseService做什么用？比较感兴趣这个
BaseService是将每个***Service抽出的公共部分，作为基类。
因为我们项目是按照那个图纵向分工的，BaseAction、BaseService、BaseDAO,这三层也作为一个纵向（一个模块），来分给对业务比较熟悉的人，其余的纵向（模块）分给对模块比较熟悉的
里面的Base***都是提供出来的公共部分而已。
本来我以为可以横向分工的，就是说表示层，逻辑层，数据访问层这样划分任务的，可惜被我们头驳回……
8 楼
ahuaxuan
2007-01-02
这种划分是比较通用的划分方法,包括appfuse这种合成framework也是这样组织的,我们公司之前的框架也是改装自appfuse,当然appfuse中只是一些common的东西,如果其中没有自己想要的还是需要自己加上去的
9 楼
Godlikeme
2007-01-03
dzgwt2004 写道
首先谢谢各位的支持！
BaseService是将每个***Service抽出的公共部分，作为基类。
因为我们项目是按照那个图纵向分工的，BaseAction、BaseService、BaseDAO,这三层也作为一个纵向（一个模块），来分给对业务比较熟悉的人，其余的纵向（模块）分给对模块比较熟悉的
里面的Base***都是提供出来的公共部分而已。
本来我以为可以横向分工的，就是说表示层，逻辑层，数据访问层这样划分任务的，可惜被我们头驳回……
zqc53 写道
BaseService做什么用？比较感兴趣这个
BaseService是将每个***Service抽出的公共部分，作为基类。
因为我们项目是按照那个图纵向分工的，BaseAction、BaseService、BaseDAO,这三层也作为一个纵向（一个模块），来分给对业务比较熟悉的人，其余的纵向（模块）分给对模块比较熟悉的
里面的Base***都是提供出来的公共部分而已。
本来我以为可以横向分工的，就是说表示层，逻辑层，数据访问层这样划分任务的，可惜被我们头驳回……
纵向分工，工作的内容业务相关性比较强。