一个小型网站中的层职责设计,请问是否合理

这个网站的主要功能是新闻发布,投票管理,一些政策信息的发布,新闻版块的管理.
项目使用struts+hibernate3.0开发

项目中分层是这样的
Entity(相当于DOMAIN)
DAO层
Service层.
还有 web层.web层主要是struts的action,相当于一个控制器.

在DAO层中我只写了一个包含了CRUD方法的接口暂时叫做(Service)和它的一个实现类,接口中的方法如下
interface Service{
saveOrupdate(Entity e);//Entity 是每个实体类必须实现的接口
delete(Class c,Serializable id);
List query(String hql,Map conditions);//使用hibernate HQL查询

}

针对于具体的业务要求,我在Service层中写具体的业务方法,比如:
NewsService{
Service service=new ServiceImpl();
public News readNewsById(Serializable newsId){
String hql="from news n where n.id=:id";
Map conditions=new HashMap();
conditions.put("id",conditions);
List newsList=service.query(hql,conditions);
return newsList.get(0);
}
public void deleteNewsById(Serializable id){
service.delete(News.class,id);

}
......//其余业务方法略
}

在NewsService中我没有使用任何事物机制.具体的事物是通过AOP方式实现的,这个事物处理方法是通过CGLIB中的enhancer来包装这个NewsService,然后写个方法拦截器,在NewsService中每个方法执行之前和之后开启事物和关闭事物以及捕获异常回滚等.
这个包装NewsService的类叫TransactionProxy,在struts的action中通过如下方式使用带有事物机制的NewsService
DeleteNewsAction extends Action {
public ActionForward execute(....){
NewsService newsService=
(NewsService)TransactionProxy(NewsService.class);
.....
}
}


以上是我的代码,不知道大家对这样的项目结构有什么看法;本人期待大家的意见,谢谢


基本结构清楚。

关于事务采取AOP方式是可行的,如果从性能角度来说,不如直接在代码中显式调用,权限检查等是需要AOP,因为权限系统设计上需要和业务系统分离,而事务支持作为一个API,我们介入有关事务编程工作很少(相反,我们介入权限方面的编程要很多)。

个人意见,纯参考。

谢谢板桥大哥的回复,我还有一个问题想问问,就是我把DAO代码做的尽量通用,避免写烦琐而功能类似的代码,这种方式对于项目的扩展来说有没有影响呢?我做过的项目不多,而且没有参与过架构设计,没有什么预见性,请您以及有设计经验的大侠们指点一下,先谢谢了

>把DAO代码做的尽量通用,避免写烦琐而功能类似的代码
使用Hibernate,所有Domain Model只需要用一个包含save update delete get(CRUD)的类就可以了,Spring+Hibernate中提供的HibernateTemplate必须根据不同的Model做不同的DAO实现,而如果我们统一所有Model为一个Entity(根据Evans DDDD),那么只需要一个DAO类就可以,不是统一而通用吗?

当然,剩余的功夫就是你的Domain Model聚合设计了。也就是Evans DDD的功夫了,我已经做出一个这样系统,见该文源码:
http://www.jdon.com/artichect/javaee.html