81,092
社区成员
发帖
与我相关
我的任务
分享关于web开发分层的问题
web开发的项目，基本上都是分成了这几个层次：显示层(jsp)，控制层(action),服务层(service)，数据访问层(DAO)，模型层(javabean)。自己在做开发的过程中也是按照这几层进行的，但是就是照葫芦画瓢，不太了解其中的含义，有下面几个问题想请教一下：
DAO应该是做简单的CRUD操作的，Service层将DAO中的操作作为原料，拼成有意义的方法，提供给action层调用，那么：
1、DAO应该是一个接口，每张表都应该对应一个XxxDAOImpl类，这样导致了有很多XxxDAO类，使项目看起来很乱
2、Service也应该是一个接口，根据具体业务的不同对应不同的ServiceImpl类，但是不同的业务怎么能归纳出一个共同的接口呢？另外，这样也导致要写很多ServiceImpl类，是项目很复杂。
我想知道这样做是否有意义，如果这样不好，应该采取什么方法进行web开发，谢谢！
DAO应该是做简单的CRUD操作的，Service层将DAO中的操作作为原料，拼成有意义的方法，提供给action层调用，那么：
1、DAO应该是一个接口，每张表都应该对应一个XxxDAOImpl类，这样导致了有很多XxxDAO类，使项目看起来很乱
2、Service也应该是一个接口，根据具体业务的不同对应不同的ServiceImpl类，但是不同的业务怎么能归纳出一个共同的接口呢？另外，这样也导致要写很多ServiceImpl类，是项目很复杂。
我想知道这样做是否有意义，如果这样不好，应该采取什么方法进行web开发，谢谢！
...全文
请发表友善的回复…
发表回复
chenglix 2011-11-22
- 打赏
- 举报
Action接收表单提交的数据，将数据交给Service层去处理，可能要经过多个Service层处理，这里暂且分为AService、BService、CService。用户提交了表单后， Action将数据提交给AService处理，AService把处理后的数据返回给Action，如果需要多个Service处理的话，Action又将数据交给BService处理，然后BService把处理后的数据返回给Action……
youyou0248 2011-07-28
- 打赏
- 举报
学习了。。。。。
alexliang2008 2009-11-04
- 打赏
- 举报
考虑采用一些开源框架
gao512008 2009-11-02
- 打赏
- 举报
MARK
wgj830823 2009-11-02
- 打赏
- 举报
楼主把很多问题放在一块考虑就会觉得很乱了
你先去理解mvc，这三层应该是很容易理解的，展示和业务以及数据模型间分开有*****多的好处，这个即使没有什么经验也可以想明白，然后你说的dao，以及service过多的问题实际上是为了避免高耦合的编程陷阱。每个业务一个service接口，然后对应一个或者多个实现类，实际上你做的时候不用考虑太多，根据前台需要什么方法接口里就去声明一个，然后在实现类里去编写代码实现，一般刚开始开发的时候就有一个实现类，这样也看不出什么优势，但是如果后期或者维护的时候某些地方发生了变化，这样的模式就优势明显了，。想想看如果你的数据库突然需要变更，如果没有这个接口 ，你就要去修改很多写在一起的代码，从一堆代码里找到需要改的然后改掉。而现在就只要做一个新的实现类，指定使用它就是了，可能这个改的过程你的工作量没有什么减少 甚至还有增加。但是你保存了原来的代码，只是又加了一种实现。万一哪天又需要改回去，你只要改改配置就ok了，这不是很好嘛。
总之，写了这么多乱七八糟的东西就是想说：分层以及使用ioc就是为了代码的灵活和可扩展可维护等目的。
你先去理解mvc，这三层应该是很容易理解的，展示和业务以及数据模型间分开有*****多的好处，这个即使没有什么经验也可以想明白，然后你说的dao，以及service过多的问题实际上是为了避免高耦合的编程陷阱。每个业务一个service接口，然后对应一个或者多个实现类，实际上你做的时候不用考虑太多，根据前台需要什么方法接口里就去声明一个，然后在实现类里去编写代码实现，一般刚开始开发的时候就有一个实现类，这样也看不出什么优势，但是如果后期或者维护的时候某些地方发生了变化，这样的模式就优势明显了，。想想看如果你的数据库突然需要变更，如果没有这个接口 ，你就要去修改很多写在一起的代码，从一堆代码里找到需要改的然后改掉。而现在就只要做一个新的实现类，指定使用它就是了，可能这个改的过程你的工作量没有什么减少 甚至还有增加。但是你保存了原来的代码，只是又加了一种实现。万一哪天又需要改回去，你只要改改配置就ok了，这不是很好嘛。
总之，写了这么多乱七八糟的东西就是想说：分层以及使用ioc就是为了代码的灵活和可扩展可维护等目的。
abc130314 2009-11-02
- 打赏
- 举报
项目乱不乱和类的多少，没有直接关系。
而且分层也没有绝对的界线。
而且分层也没有绝对的界线。
代码间的舞者 2009-11-02
- 打赏
- 举报
我觉得是先分模块，再分层。
分模块就是将不同逻辑的业务分开，然后在这个模块下再分层。
之前开发的项目，就是把所有dao、service和action分别放在一个package里，结果维护的时候非常困难，都不知道谁是谁的谁了....
分模块就是将不同逻辑的业务分开，然后在这个模块下再分层。
之前开发的项目，就是把所有dao、service和action分别放在一个package里，结果维护的时候非常困难，都不知道谁是谁的谁了....
meander 2009-11-02
- 打赏
- 举报
up
tk5210364 2009-11-02
- 打赏
- 举报
这样子看起来很明了啊.
就算那里错了 就能知道是哪错了.
找起来容易啊.
在dao里写 它的接口或者实现.也可分开
servrice 如此
就算那里错了 就能知道是哪错了.
找起来容易啊.
在dao里写 它的接口或者实现.也可分开
servrice 如此
huadis 2009-11-01
- 打赏
- 举报
我觉得所谓的分层是要看你项目的实际应用场景的，如果你的项目只在国内跑，用的数据库只有一种，你去写一个国际化，搞一堆不同数据库接口、实现，有意义吗？与其写得这么累还不如抛开所谓的框架。
config_man 2009-11-01
- 打赏
- 举报
...
painforever 2009-11-01
- 打赏
- 举报
[Quote=引用 9 楼 mawenwu281107072139 的回复:]
基于接口编程这样做的好处是便于系统的升级,扩展,维护.
层与层之间不之间调用而是通过接口,这样做是为了解耦合,目的还是上面说的.
我想你现在在学校读书吧,等你上班了公司里面都是这样做的 而却分的更加的清楚,细致,目的还是上面的那几个.
所有分三层开发是很有必要的.
[/Quote]
真上班了，就是在开发的过程中想到的这些问题。就是说为了做到易于扩展和维护，就要有很多类？
基于接口编程这样做的好处是便于系统的升级,扩展,维护.
层与层之间不之间调用而是通过接口,这样做是为了解耦合,目的还是上面说的.
我想你现在在学校读书吧,等你上班了公司里面都是这样做的 而却分的更加的清楚,细致,目的还是上面的那几个.
所有分三层开发是很有必要的.
[/Quote]
真上班了，就是在开发的过程中想到的这些问题。就是说为了做到易于扩展和维护，就要有很多类？
blliy117 2009-11-01
- 打赏
- 举报
觉得楼主想法是不错的，但有些东西是很难避免的，serviceImpl多正常啊，我现在的项目中service就是一大把。这个没办法。
当然像dao我觉得还是有不少能重用的，如crud其实就是基本可以用统一用一个抽象父类来写，也不要想得太多关于重用，毕竟有时候需求没有这么多时间让你考虑！
当然像dao我觉得还是有不少能重用的，如crud其实就是基本可以用统一用一个抽象父类来写，也不要想得太多关于重用，毕竟有时候需求没有这么多时间让你考虑！
MaWenWu281107072139 2009-11-01
- 打赏
- 举报
基于接口编程这样做的好处是便于系统的升级,扩展,维护.
层与层之间不之间调用而是通过接口,这样做是为了解耦合,目的还是上面说的.
我想你现在在学校读书吧,等你上班了公司里面都是这样做的 而却分的更加的清楚,细致,目的还是上面的那几个.
所有分三层开发是很有必要的.
层与层之间不之间调用而是通过接口,这样做是为了解耦合,目的还是上面说的.
我想你现在在学校读书吧,等你上班了公司里面都是这样做的 而却分的更加的清楚,细致,目的还是上面的那几个.
所有分三层开发是很有必要的.
javaors 2009-11-01
- 打赏
- 举报
面向接口编程是一个非常好的习惯。
woming66 2009-11-01
- 打赏
- 举报
系统有2个模块A和B，那么Service层就应该有2个相应的接口ServiceA和ServiceB,ServiceAImpl可以用ADaoImpl和BDaoImpl,同样ServiceBImpl也可以用ADaoImpl和BDaoImpl,不一定非要一对一，但当业务复杂的时候，通常是一个service对应多个dao
显示层不一定是jsp，还有别的如果freemarker,Velocity
分层是根据需求来的，不一定非得分三层，小P项目就可以不用分层，大项目 如电信的 可能分的更细
显示层不一定是jsp，还有别的如果freemarker,Velocity
分层是根据需求来的，不一定非得分三层，小P项目就可以不用分层，大项目 如电信的 可能分的更细
painforever 2009-11-01
- 打赏
- 举报
[Quote=引用 3 楼 woming66 的回复:]
2、Service或manager层通常是对应一个模块的业务，达到内聚的目的。一个大系统模块很多，会有很多的业务逻辑组件，但是如果有些系统的业务逻辑相同，你就可以直接用原来开发过的业务层组件（但是这种几率不是很大）。
你没有做过真正实战的项目，你是根本体会不到分层的好处！
[/Quote]
那么比如说，系统有2个模块A和B，那么Service层就应该有2个相应的接口ServiceA和ServiceB，ServiceAImpl是调用和模块A有关的DAOImpl的东西，ServiceBImpl是调用和模块B有关的DAOImpl的东西，那这层有什么可复用的呢？
能不能举个真正应用中的例子呢？
另外，楼上几位的意思就是这种把web开发分成显示层(jsp)，控制层(action),服务层(service)，数据访问层(DAO)，模型层(javabean)这种分层方式是正确的咯？
2、Service或manager层通常是对应一个模块的业务，达到内聚的目的。一个大系统模块很多，会有很多的业务逻辑组件，但是如果有些系统的业务逻辑相同，你就可以直接用原来开发过的业务层组件（但是这种几率不是很大）。
你没有做过真正实战的项目，你是根本体会不到分层的好处！
[/Quote]
那么比如说，系统有2个模块A和B，那么Service层就应该有2个相应的接口ServiceA和ServiceB，ServiceAImpl是调用和模块A有关的DAOImpl的东西，ServiceBImpl是调用和模块B有关的DAOImpl的东西，那这层有什么可复用的呢？
能不能举个真正应用中的例子呢？
另外，楼上几位的意思就是这种把web开发分成显示层(jsp)，控制层(action),服务层(service)，数据访问层(DAO)，模型层(javabean)这种分层方式是正确的咯？
min123456520 2009-11-01
- 打赏
- 举报
只要楼主一层一层的理解清楚,应该是很清晰的
项目中采用面向接口编程,是为了方便以后做扩展用
我觉得还是很有必要的
up
项目中采用面向接口编程,是为了方便以后做扩展用
我觉得还是很有必要的
up
zl3450341 2009-11-01
- 打赏
- 举报
便于以后扩展和维护
woming66 2009-11-01
- 打赏
- 举报
1、不一定一张表对应一个XxxDAOImpl类,也可能有两个或两个以上的表，只映射一个实体模式，
<class table="t_message" name="com.zzq.domain.Message">
<property name="......"/>
<list table="t_message_uploadfile" name="files">
<key column="messageid"/>
<list-index column="indexValue"/>
<composite-element class="com.zzq.domain.EmailUploadFile">
<property name="。。。。。。"/>
<property name="fileName"/>
</composite-element>
</list>
.......
</class>
2、Service或manager层通常是对应一个模块的业务，达到内聚的目的。一个大系统模块很多，会有很多的业务逻辑组件，但是如果有些系统的业务逻辑相同，你就可以直接用原来开发过的业务层组件（但是这种几率不是很大）。
3、分层的好处还有一点是，让页面控制、业务逻辑、数据库操作 解耦，更好的应对各种变化，使层的职责更加明确。
你没有做过真正实战的项目，你是根本体会不到分层的好处！
<class table="t_message" name="com.zzq.domain.Message">
<property name="......"/>
<list table="t_message_uploadfile" name="files">
<key column="messageid"/>
<list-index column="indexValue"/>
<composite-element class="com.zzq.domain.EmailUploadFile">
<property name="。。。。。。"/>
<property name="fileName"/>
</composite-element>
</list>
.......
</class>
2、Service或manager层通常是对应一个模块的业务，达到内聚的目的。一个大系统模块很多，会有很多的业务逻辑组件，但是如果有些系统的业务逻辑相同，你就可以直接用原来开发过的业务层组件（但是这种几率不是很大）。
3、分层的好处还有一点是，让页面控制、业务逻辑、数据库操作 解耦，更好的应对各种变化，使层的职责更加明确。
你没有做过真正实战的项目，你是根本体会不到分层的好处！
加载更多回复（2）
