为新的小型项目设计了一个架构，请批评指正

学院组织自行开发的小型项目，从需求来说并不存在切换数据库和表现层的可能，所以事实上来说jsp+javabean都能完成，当然我们并不会满足与此。在使用MVC开发了学院的教学管理系统的过程中，我们明显的发现了架构上一些不合理的地方：

1、jsp页面与servlet的耦合很严重，任何对servlet的改动最终可能都会导致servet的改动
2、没有业务逻辑层，逻辑分散在servlet和dao中，导致维护的困难，并且难以复用
3、没有采用接口，不同开发人员之间的代码匹配存在问题（设计不充分也是一个原因，但是利用接口来描述不同类的关系显然更直观）

针对这些问题，我们本次的开发从一开始就希望可以解决这些问题，本来我是希望使用spring的，但是团队里很多人对spring并不熟悉，所以现在就着手设计了（可能最终还是会使用spring，架构所需的助手类就足以把我们的时间耗尽了:? ），最低的要求就是要将业务层独立出来。
目前大致的想法是这样的：
├─com
│  └─util
├─dao
│  ├─jdbc
├─domin
│  ├─bean
│  └─logic
└─web

其中：
com.util下放一些工具类；
dao下放dao层的接口，dao所包的jdbc包则放基于jdbc的具体实现；
domain下放facade和对应的implementation，domain所包含的bean和logic两个包，bean中放do，logic中则放业务逻辑类；
web包中放servlet；

这样的话，业务层却是已经独立出来了，并且接口的使用也可以使得程序的结构更为清晰（需要良好的设计），但是

1、第1个问题即servet和jsp的耦合依然未能解决；
2、另外interface的作用并未完全发挥。由于缺乏自动维护xml的机制，为了避免大量的xml为维护工作而没有使用factory模式将具体对interface的实现从调用代码里抽取出来，即未将各层间的耦合降低（对于本系统来说这并不算致命）。
3、哪些方法应该放入领域对象，哪些应给独立出来还没有概念

这些就是现在的一些想法，还很不成熟，请大家提出一些自己的看法，谢谢

Src
├─domain
├─logic
├─service
├─persistence
│    ├─jdbc
├─util
│    ├─bean
└─web

domain领域对象
logic业务逻辑
service服务层
persistence 持久层
util工具类

DAO不是非用不可的。它分为domain领域对象，service服务层更清晰。
层与层之间不允许跨层调用。

我做的是Struts，不知合适不合适你的项目。
在项目中是这样的结构
├─domain
├─logic
├─service
├─persistence
├─util
│    ├─bean
└─web

domain领域对象
logic业务逻辑
service服务层
persistence 持久层
util工具类

DAO不是非用不可的。它分为domain领域对象层，service服务层更清晰。
层与层之间不允许跨层调用。util,bean没有什么好谈的,下面主要说说我用Domain,logic,Service,Persistence的过程.


设定:
基本类
Artilce 文章
├─id   ID
├─titie  标题
├─class  类别
├─concept 内容

比如
form中传入一个Article文章对象，当然它需要一定的处理，比如根据内容concept取出类别class,截去内容前10位做标题(如果用户没有指定标题)等，然后调用ArticleSevice.save(article),这是ArticleSevice的对上接口,插入语句在save()函数中写,然后调用persistence的execute方法.
如果form中传入的是条件,比如类别,则logic类新建一个Article的实例,其class字段赋上值其它的留空,然后调用ArticleSevice.search(article),查询语句根据Article的各个字段是否为空组合成,然后调用persistence的search方法取出List,再传回页面.
其它删除 更新也是一样的处理方法.

不知楼主和大家感觉这样做如何,一起谈谈?

我觉得楼上的把dao的概念给搞错了，dao就是一个简单的数据访问层，不应包括业务逻辑性的东西。业务逻辑性的东西包括事物管理都在service层实现。
如果让我来设计，就是
|- dao
|- model
|- service
|- util
|- web

dao层提供对数据库或其他持久化数据的统一访问接口，爱用orm或者用纯jdbc都无所谓。
model里面放不包含具体业务逻辑的只有getter和setter方法的POJO，也许应该叫域对象
service层提供域对象的封装、业务逻辑的实现和事务管理实现，同时为web层提供调用接口
web层包括servlet和/或action类。
util就是放工具类的了。
web层除本层外只允许调用service层的接口及util类
service层调用dao层接口和封装model

我看这个帖子的内容倒更接近package结构设计，而不是项目的架构设计。

dao就是简单数据访问,我觉得是没有必要做一个类层次的.我感觉它的权责过轻了,实际使用时为一时方便又容易分派给它很多额外任务,所以有必要分开成两层Domain和Service.

我认为系统中各部分传递的数据都应该是Domain(也就是你说的model)中各类及其集合和组合,logic是对数据从内(java)向外(view)或从外向内的处理,service搭起流动对象与持久层之间的桥梁.我感觉这样比较清晰.

请问cjmm 怎么看?(PS:这段是后来改的,原文是楼上怎么看,回完贴才发现楼上换人了,Robbin是否觉得那个小CheckBox有些不妥啊)

这个世界有时就是有心栽花花不活,无心插柳柳成荫.只要观点能交流能碰撞,真理越辩越明,就是一个好帖子.何必为了一些名词概念捆住手脚?

分析了一下两位的看法
util：没什么好说的:)
web：即servlet和/或action类，我也是这么想的（不过servlet和jsp的解藕不知道有没有什么办法）
service：cjmm  认为是用于提供域对象的封装、业务逻辑的实现和事务管理实现，同时为web层提供调用接口； 而行为艺术家的做法是把它再分开为service和logic，更为清晰
dao：其实我想行为艺术家说的persistence层也是一样的意思，都是为了屏蔽具体的数据库相关操作的细节
domain：domain和model我想指的也是同样的意思，就是领域对象

不过行为艺术家的这句我有点不太理解：

似乎是对dao的理解于我不同，我理解的dao层其实就是persistence，呵呵

对于不能跨层调用我也赞同

谢谢两位帮我弄清除了domain层的作用，这样我的架构就使这样了，和cjmm 所说的其实是没什么区别的，只是个别名字不同
src
├─util            工具类
├─persistence 持久化
│ ├─jdbc
├─domin         领域对象
├─service        服务层
└─web           web层

调用的关系就是从下往上，逐层调用

不过我的三大问题还是悬而未决

确实有那么点味道，呵呵，不过我们讨论的还是如何分层的问题
希望大家提出自己的意见

我和楼主是一起做项目的，其实我们构建出来的系统架构没有解决的问题是怎么让接口发挥他的利用，如果用factory模式的话，就要在xml中加入相关的类，相当麻烦，不知道各位都是怎么解决这个问题的，