关于J2EE中的分层

本人在用ssh做项目的时候用的分层是

action-service-dao-po


一个模块（后台用户模块，后台管理员模块，前天界面模块）用一个action控制；
一个action（DispatchAction）调用多个service；
一个service调用多个Dao；
一个Dao对应一个po

但是实现后发现action 类的方法比较臃肿，如果一个功能对应一个action ，好像action类比较多。

由于自己的java技术都是一路自学过来的，很少项目的经验。

问下在分大，中，小，型项目中，分层思想是怎样的，主要是前台页面、action、service、dao  四者之间的对应关系。。在网上找不到相关的内容，自己又想总结下，所以请教下大侠们。
问题补充
另: "一个action（DispatchAction）调用多个service", 那事务是在哪儿控制的?


事务控制可以在dao层配置  或者在service层  该可以吧

一个功能对应一个action不是很好吗，稍微大一点的系统不可能你一个人完成的哦。
不过我也讨厌它的配置文件。。
jiyanliang (初级程序员) 2009-06-18
zhxing 写道
本人在用ssh做项目的时候用的分层是

action-service-dao-po


一个模块（后台用户模块，后台管理员模块，前天界面模块）用一个action控制；
一个action（DispatchAction）调用多个service；
一个service调用多个Dao；
一个Dao对应一个po

但是实现后发现action 类的方法比较臃肿，如果一个功能对应一个action ，好像action类比较多。


问下在分大，中，小，型项目中，分层思想是怎样的，主要是前台页面、action、service、dao  四者之间的对应关系。。在网上找不到相关的内容，自己又想总结下，所以请教下大侠们。


你们采用action-service-dao-po的这种结构应该算是比较经典的结构吧.
po(pojo贫血模式)就是对数据库表及其关系的映射;
dao是对po的操作, 就是对数据库的crud等操作;
service层是写具体的业务逻辑的, 一般在这里调用dao. 看spring的书籍时一般会发现总会有service层出现. service层在Martin Fowler的一本书里面有介绍.

同ls, 一个功能调用一个action不是挺好的嘛

另: "一个action（DispatchAction）调用多个service", 那事务是在哪儿控制的?



Dony (初级程序员) 2009-06-18
struts就是这个样子，没办法，我曾经玩过一个struts的config文件，里面有几千个action，夸张吧，没办法，业务太复杂了
taga (初级程序员) 2009-06-18
我感觉加上Service层比较好，程序灵活性更好
feiyu311 (初级程序员) 2009-06-18
请参考一下这个比较经典的帖子吧
http://www.iteye.com/topic/17579
fengbaoxp (初级程序员) 2009-06-18
借宝地发个问题：

在一个EAR包中有两war包，那么能否在A.war中的利用Request.getRequestDispatcher将A的request和resepones转到B.war中的servlet或者是JSP中去处理呢？
danni505 (初级程序员) 2009-06-18
你把业务逻辑写在ACTION层里必然导致ACTION过于膨胀。

按你的说法：

action-service-dao-po


一个模块（后台用户模块，后台管理员模块，前天界面模块）用一个action控制；
一个action（DispatchAction）调用多个service；
一个service调用多个Dao；
一个Dao对应一个po

你这样，不管怎么分，你总会膨胀，也许是ACTION，也许是service。而你的DAO几乎又傻傻的把HIBERNATE又封装了一遍。
treblesoftware (初级程序员) 2009-06-18
IEstrutsActionServletActionspringmodeldaoHibernatedb
一般的开发架构是这样的，你可以好好看看！
vera_sq (初级程序员) 2009-06-19
事务当然控制在service层呀,你记住,一切逻辑功能(包括事务),都在service是编写.其实action里不是你想像的那么肿,你想想所有的逻辑功能都封在service里,action只是调就行了,充其量只能说action里的方法多点.但那有什么关系呢, 如果你觉的action里的方法太多了,你可以再根据功能再划分一些出去,都是可以的.
huangnetian (架构师) 2009-06-19
你们所用的这个组合算是经典的组合了，这个组合没有什么问题的。
其实不一定必须要一个功能就一个action的，一个action里面可以有多个方法的，比如有增删改查等等的方法，有两种实现的方法：
一，用if来判断，从页面里传一个参数过来，根据传过来的参数来判断进入到哪个功能方法中，不如传过来的是add，那你就让它进入到add的方法中。页面传的时候可以在.do后面加上?action=add这样传到action中，再根据 request.getParameter("action")取到参数，在action中判断 if(request.getParameter("action").equals("add"))就进入到add()方法中，从而来控制程序的跳转。不过我不建议用这个方法。
二，不要继承Action基类了，继承DisAction这个基类吧（好像是这个基类），继承它的话，它支持多个处理方法，只要在配置文件中配置一下method，然后从页面里传参数，.do?method=add,然后在你自己的action里面写add(HttpRequest request,HttpResponse response,......)这样的方法就行，我推荐这种方法。
如果这样做的话，就可以一个模块一个action了，一个功能对应一个action里面的一个方法。
tianyangqi (中级程序员) 2009-06-19
其实不用非得一个功能一个action，我在写SSH项目时，当功能都在一个action中能实现时，我通常通过继承DispatchAction来通过方法区分每次的功能，这样就不必写多个Action了
handonghandong (初级程序员) 2009-06-19
引用
一个action（DispatchAction）调用多个service；


一个action不应该调用多个service。你可能把业务逻辑写在action里。action通常只是验证参数是否正确，参数格式转换。 我个人觉的service与dao也不是一一对应的，service是面向功能模块来划分的，而dao是根据数据表来划分的
luckaway (初级程序员) 2009-06-19
1。action用来处理页面相关的东西，其他逻辑放到service中；action层也可以简化，你可以看看REST的东西，自己把action进行高度抽象。随着Ajax和REST的应用action会变的越来越薄的！
2。事务控制层次越高越好，放在action直接调用的service方法上；逻辑复杂时，service层中也需要更细的分层，这些层都为服务层
3。dao层，应该尽量弱化，因为spring、ibatis等实现了dao功能，可以直接在service调用他们提供的dao；事务不能放在这个层。扩展一下，现实中系统调用的资源（数据库、外部接口等）都会处于同一层，应该叫做资源层

还有一个非常重要的东西——模型，模型就是系统要处理的对象，形象一点，模型就是自然社会中的人，享受各种服务，资源，呈现各种形态

以上只是我的一点看法，系统设计的思维方式不同，系统划分的层次就不一样。
mojiedao (初级程序员) 2009-06-19
事务操作最好是在model层，或者是在service层中。
dao层主要负责的是连接DB做操作的，不要写在dao层，不便于以后系统的扩展！
具体舟事务层是写在model层，还是service就看你的系统大小和业务来决定了。
vera_sq (初级程序员) 2009-06-20
action那边只是实现的参数处理，执行顺序，结果处理

service层实现业务逻辑的具体内容，将最终结果返回给action。

至于你说的事务，当然放在service的方法中，如果service中的方法有什么错误就回滚事务，防止数据库中出现有问题的数据
zhoulei984623 (初级程序员) 2009-06-22
事务，一般都在Controller里控制
tinkingdzj (初级程序员) 2009-06-22
引用

IEstrutsActionServletActionspringmodeldaoHibernatedb

这个可真够强的！
lucky16 (初级程序员) 2009-06-24
事务是在service层管理的，可以使用DispacthAction,这样，这个
action里虽然有很多的方法，但是配置文件里的action里就会相对的少很多了。
linsongbin1 (初级程序员) 2009-06-24
其实你不要刻意去分层的 个人认为 ACTION中 有时候很难避免有service 代码的    MVC 也不是是那样完美 真的 有时候 一个很小的项目 MVC 纯是拖累
pzk417 (初级程序员) 2009-06-25
我也习惯楼主说的结构，导致我看人家把dao和sevice写到一起我看了难受。
renguistyle (初级程序员) 2009-06-25