java的web架构讨论【散分,来者有分】

qq1043809470 2012-11-13 04:13:34
说明:系统使用了Structs2、hibernate3、spring3框架,使用了基本的三层架构,即:Dao层、Service层、Action层

一、关于Dao层
顾名思义,Dao数据操纵对象,封装了访问数据库的操作,在service层只需调用它提供的接口就可以实现数据库的操纵,无论使用下面的哪种方法都可以屏蔽数据库的信息(无论它是oracle、sqlserver、mysql、db2)
1、有的系统只使用一个Dao对象,即CommonDao对象,把所有的数据库操作都放在该对象中,这样做确实不要写太多的Dao接口和实现类,请经验丰富者说明该种设计的利和弊(包括后期维护的利和弊)。
2、有的系统使用N个Dao接口和DaoImpl,基本上做到了一张表一个Dao,这样有些Dao操作是通用的,可是却在Dao中重复了N遍,感觉挺麻烦,请经验丰富者说明该种设计的利和弊(包括后期维护的利和弊)。

二、关于Service层
service对象,即:业务处理对象,其封装的是业务处理逻辑,action层只需要访问其提供的接口就行了,这样action代码很简洁,在这里我有一个疑问,就是service层有必要实现面向接口编程吗?请经验丰富者说明该种设计的利和弊(包括后期维护的利和弊)。


请大家踊跃发言,各抒己见,来者有分
...全文
2475 85 打赏 收藏 转发到动态 举报
写回复
用AI写文章
85 条回复
切换为时间正序
请发表友善的回复…
发表回复
ZQYfendou 2012-11-21
  • 打赏
  • 举报
回复
我现在正在学习ssh,你们都懂的太多了
qinzi_2013 2012-11-21
  • 打赏
  • 举报
回复
qq1043809470 2012-11-21
  • 打赏
  • 举报
回复
求共享,求分享 我先来共享一篇文章 http://blog.csdn.net/shaily/article/details/4308449
faith_boys 2012-11-21
  • 打赏
  • 举报
回复
菜鸟飘过、、、、、、
qq1043809470 2012-11-21
  • 打赏
  • 举报
回复
上面 只是例子
qq1043809470 2012-11-21
  • 打赏
  • 举报
回复
你们把你们公司的架构图上传上来,大家共享下,只要显示到包即可,下面是我的:

jiemotang 2012-11-19
  • 打赏
  • 举报
回复
引用 15 楼 qq1043809470 的回复:
引用 13 楼 scottxzj 的回复:还有就是 你问的 为什么 有的 是把action service dao 每一样相对的都写一起, 相对小的项目,紧密性高的 写一起方便,不用引用那么多包,不用来回继承。 缺点就是 ,大项目 怎么办? 你打开一个action 里面有 十来万代码 你还有心看么。找个 action 得累死,改个错误都闹心死。 ……
各有利弊,不过我比较喜欢一个模块一个biz一个Dao一个Action
chinaskyone 2012-11-19
  • 打赏
  • 举报
回复
小系统,任何一个人一眼就可以把握的,可以动手做的时候,讲这些体现不出来优势。 从高层来说,当系统大到一定程度,复杂到一定程度,而且系统不会只是用个一年两年就废弃了,而是要不断的完善,扩展的时候,分系统、分子系统、分模块,把系统尽量隔离开,最小化功能相关,就是很迫切的需要的。 同样分层action、service、dao,职责单一,多个service、多个dao,虽然看起来个别地方重复(设计做的够好,是可以避免的),但是利于简化项目复杂的,利于项目实施和管理。 接口的问题,在大系统设计的设计,架构师和设计人员要考虑的一个重要问题就是模块之间的通讯连接问题,怎么样,分解系统,降低复杂度的同时,让系统组合起来可以更好的运行,这个是接口的主要意义,然后就可以分发下去开发,对项目管理也有很大益处。 这样子做的好处,从底层来说就是得到了高内聚,低耦合的组件,这样子对以后系统的维护、扩展的好处,到处都可以搜到。 对开发人员来说,我只需要关注实现我自己的模块,对管理人员来说可以更好的安排工作,控制工作进度。对于bug的定位和修改也都容易的多。
y_keven 2012-11-19
  • 打赏
  • 举报
回复
service层用接口编程,正是java的面向对象编程啊,这里调用相应的类面向接口编程,运用接口概念是为了减少设计模式之间的各层的耦合度,一种规范,通俗一点说就是你好了这个接口,把你项目的需求、业务逻辑等封装进去,然后分配给项目组的其他人;面向接口还有一个好处就是你做的这个web项目以后升级的时候,你所需要做的就是在service接口添加新业务应用,实现类去实现,其他层可以不动,不需要大的改动
y_keven 2012-11-19
  • 打赏
  • 举报
回复
Bumpking 2012-11-19
  • 打赏
  • 举报
回复
降低模块间耦合更符合软件工程的思想。维护起来会省很多麻烦。 细粒度的结构划分可以更精确的定位。比如aop的切面定位,事物划分等。 没见过用一个DAO的系统,不做评论。
mindsk 2012-11-19
  • 打赏
  • 举报
回复
接口是规范,类是实现。OOP即现实中所有事物都可以看成是对象,接口就是用来描述事物特征的。其实太多的接口是写给计算机看的。其实没有写个大量函数式编程的,是不能真正的领悟OOP的。
ztianlong 2012-11-18
  • 打赏
  • 举报
回复
1、有的系统只使用一个Dao对象,即CommonDao对象,把所有的数据库操作都放在该对象中,这样做确实不要写太多的Dao接口和实现类,请经验丰富者说明该种设计的利和弊(包括后期维护的利和弊)。 ========================================= 这样做个人感觉是不大好的,只用一个Dao对象,可能导致这个Dao代码过长,太多人维护。利益我暂时没看到。 2、有的系统使用N个Dao接口和DaoImpl,基本上做到了一张表一个Dao,这样有些Dao操作是通用的,可是却在Dao中重复了N遍,感觉挺麻烦,请经验丰富者说明该种设计的利和弊(包括后期维护的利和弊)。 ========================================= 这个还是凑合 不一定要一个表一个dao 也可以相关的类公用一个dao 至于某些Dao 操作是通用的,你可以抽取出来,放在父类的Dao里边。这样以后要修改通用操作的时候只用维护这个父Dao就可以。 其他地方也应该是有公用的代码就放到父类里边。 二、关于Service层 service对象,即:业务处理对象,其封装的是业务处理逻辑,action层只需要访问其提供的接口就行了,这样action代码很简洁,在这里我有一个疑问,就是service层有必要实现面向接口编程吗?请经验丰富者说明该种设计的利和弊(包括后期维护的利和弊)。 ====================================== 这个没有太多经验... 嗯 以上是我的看法 欢迎拍砖 也是新手学习 哈哈
tangwei070 2012-11-18
  • 打赏
  • 举报
回复
一、关于Dao层 封装在一个里面 没有利,只有弊。没有见过这样的设计。 难道一个对象里面几万行代码? 二、关于Service层 service对象,即:业务处理对象,其封装的是业务处理逻辑,action层只需要访问其提供的接口就行了,这样action代码很简洁,在这里我有一个疑问,就是service层有必要实现面向接口编程吗?请经验丰富者说明该种设计的利和弊(包括后期维护的利和弊)。 有适当的必要。 特别是当你的程序需要提供webservices、 或者rmi服务的时候。 另外如果有合适的注释,看接口比看一个实现类要轻松的多。 甚至有时候也许你根本不想去看其他人的写的一堆不知所谓的“垃圾代码”(呵呵 ,每个人都有自己独特的风格)。
小牛毛 2012-11-18
  • 打赏
  • 举报
回复
刚刚开始学hibernate!
WdengniZ 2012-11-18
  • 打赏
  • 举报
回复
用框架的目的无非是让项目的代码量少了很多,方便了而已,之前用MVC模式做项目不也是做了吗,框架是应运而生的东西,自我感觉,还有就是个人感觉Struts还有Sping没什么大意思,个人还是比较喜欢hibernate这个持久层的框架还是很有用的,再有一点不得不承认的是,现在的这些框架在内存方面为我们分担了许多啊,不必需要极其更高的配置,本人只是发表一下个人的看法,高人可以指教,欢迎
雍寇德 2012-11-18
  • 打赏
  • 举报
回复
楼主别坑了 接分把 你老老实实问同事 公司流程 那么写
ToBeLastOne 2012-11-16
  • 打赏
  • 举报
回复
前期对这个问题也是特别困惑,当你维护过一个大项目,经历过需求变更的修改可能会有更多感悟。
ToBeLastOne 2012-11-16
  • 打赏
  • 举报
回复
看来楼主没有接触过复杂的业务逻辑吧,想你一下移动有多少套餐,你要是编程实现会有多么麻烦,如果只有一个commondao,你不可能把所有的底层业务sql都写到commondao里面吧!另外,如果不用很多daoimpl,那么这些业务sql就要写在services里面了,service里面的代码就会相当复杂,即有业务逻辑的,还要有事务控制的,还要有业务逻辑sql的。。。后期一旦改变需求,就能把程序员弄个半死(这个是很经常的),如果业务sql写在commondao里面就会出现影响所有的其他类使用这个sql,可能会造成许多异常。 另外,在程序方面,如果你的版本已经定了,也就是说经过了多个部门共同努力(包括测试,编码等等),如果需要变更,你更改了commondao,那么就要把之前的东西可能都要测试一下,想想工作量。。。。 另外,services里面和这里的情况也是类似的。 其实项目做大后,不要只在代码层面说省事就可以,前期编码只占程序的一部分,后期的维护和需求变才更重要,只所以分多层,面向接口来编程,就是站在工程的角度和节省后期维护成本的角度来说的。 其实我建议可以看下企业级的应用程序开发的原则和设计模式,那么这个问题可能就会有一个全新的认识。
雍寇德 2012-11-16
  • 打赏
  • 举报
回复
那你还想问什么 代码可能不修改么 你感觉直接写dao是没错 不过定义接口更规范 还是那句话 写代码也要 有规矩 按公司规矩走把
加载更多回复(63)

81,090

社区成员

发帖
与我相关
我的任务
社区描述
Java Web 开发
社区管理员
  • Web 开发社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧