Question

希望看懂我想问的朋友回答下，关于action层，service层和dao层，在这里action和service不知道具体应怎么写

我的两种想法：
1.action负责逻辑处理，而service只是负责action调用dao的中介而已，也就是说action调用service，而service简单的调用dao,而service不负责逻辑上的处理
2.action只是负责将任务分发，然后通过service来实际处理逻辑业务，而service是通过调用dao来访问数据库的。
这里我都很疑惑，请懂的人来帮忙解答。

Answer 1

回复 用户名kd仔：【我的建议是Service用来处理业务，】【业务比如说：增删改查；】【那你的意思就是service基本的方法是和dao的方法是一样的罗】【 也不能说一样，Service还可以处理一些别的业务，而非单纯的增删改查，如验证登陆，修改权限之类的各种你需要的业务。（与【这里的Service就是每一个最基本的操作】冲突！）】{【而action主要用来处理业务逻辑。】【如验证登陆，修改权限之类的各种你需要的业务。】按你上面的说法【而业务逻辑：什么时候增加，增加的条件之类的。】，这属于业务逻辑了}？？岂不自相矛盾？没别的意思，就是看你说的确实挺绕的。

我的个人观点：action:控制调度；service:业务逻辑；dao层：数据库操作【例如：有一个文档上传的功能，假设你的文档上传处理action只有一个，但是你要判断是管理员上传还是普通用户上传，然后做出不同的操作，比如管理员上传的文档要进行转化生成为flash，再把生成的flash附件和文档母本都保存到硬盘，在往数据库插入一条标识当前文档的信息；普通用户无需转化只需将上传的文档保存到硬盘然后数据库插入一条标识当前文档的记录即可。】这个时候，你就可以在service层实现里面写两个方法（一个针对管理员，一个针对普通用户；注：如果管理员和普通用户每个操作都差别很大的话，比如修改差别也很大，删除差别也很大，也可以写两个sevice层的实现，他们实现自同一个接口，这里暂不考虑这种方式），然后action根据用户的类型，来控制是调用service层的哪个方法，调用完成后，跳转向哪个页面。service的那两个方法在这个例子里分别就是：【管理员上传的那个方法，玩成文档的转换，文档母本和副本的本地保存，调用dao层保存数据】【普通用户上传的那个方法，完成文档的本地保存，调用dao层保存数据】。这只是我简单的虚拟出来的一个需求，现实开发中可以根据实际情况（如，二者功能实现上的差异程度）来选择是向上面那样写两个方法，还是写两个实现类。

Answer 2

我的建议是Service用来处理业务，当然如果划分的更详细一点，可以再添加一个ServiceIMPL层，把Service里面只放业务的接口，在ServiceIMPL具体实现业务，而action主要用来处理业务逻辑。

追问

action处理业务逻辑，service处理业务???逻辑和业务，可否讲的明确点

追答

我的理解是：
业务比如说：增删改查；
而业务逻辑：什么时候增加，增加的条件之类的。

追问

那你的意思就是service基本的方法是和dao的方法是一样的罗

追答

也不能说一样，Service还可以处理一些别的业务，而非单纯的增删改查，如验证登陆，修改权限之类的各种你需要的业务。当然，这些你如果放在DAO里面处理也是可以的，只不过层次感差一点。

追问

我知道dao是负责直接与数据库打交道的，而我不清楚的是service和action他们真是所应该负责那方面的

追答

你要分清楚业务和业务逻辑的区别。这么跟你说吧。每一个业务你可以想象成一个最基本的操作，比如说增、删、改、查、验证、判断等基本操作。而业务逻辑好比再什么情况下进行这个操作，比如说，当用户点击查询时，你就该进行查询操作，当用户点击删除按钮，你就该进行删除操作，而这些请求的处理可能都交给同一个action，所以你就应该在action中写好这个业务在什么情况下进行处理，也就是业务逻辑。不知道我这样说你能否明白？这里的Service就是每一个最基本的操作。action就是用来处理业务逻辑的。

Answer 3

主要是为了团体开放的分层模式，做数据库访问的专心在dao里写数据库访问的代码，写action人员负责接受前台发过来的信息和页面跳转等，做service的主要做业务逻辑当dao和action的桥梁，而且在些项目时常会有很多异常，service下还常常做一些节异常和把相应错误信息写入相应的日志文件。不分层也能写，但一旦出了问题也会混在一起，我们代码要做到高内聚低耦合，分层了也便于管理，我只写过几个web项目，一点小小的经验，仅供参考！

追问

我也不清楚action和service实际应该写些什么，是action实际是通过调用dao来获取数据并且进行业务处理，而service只是简单中间而已，还是说action只是业务的分发，而实际的逻辑出来才是service来处理的

追答

没有绝对的界限，你可以dao什么都做了，或许项目大了你就能看出来分层的重要了，比如说数据库的事务回滚问题，每当数据库访问异常你的食物都会回滚，那么你完全在更高的层次一段代码去一次处理这个问题，而不是每个dao中的方方法中都写。
你所看到的其实是这么多年来开发人员预订俗成的规矩，就像数据库访问层不一定要叫dao一样，但团队开发这个都有用，先写以后再慢慢理解。

Answer 4

action负责的是逻辑层，配置文件调用action实现与jsp的信息的交互，所以action中需要实现在jsp中的需要实现的类的方法，比如初期化的Init等。而Dao实现的事对数据库的持久层的操作，通过Dao对数据库的操作实现对数据的增删查改。service只是Action和Dao之间的一个方法，service调用接口Dao实现对数据的操作，Action调用service实现Jsp的表现。不知道你看懂没

追问

你的意思是action才是真实实现逻辑的地方就好像判断判断密码是否正确那样，action通过调用service只是获得了user这个对象，而action再通过这个user来实现是否密码正确，然后再返回给页面？

追答

你知道struts2不？里面对密码的验证有这样的方法validatordoUser的方法可以实现验证，他是在你实现User方法之前运行的。可以说action是实现逻辑的地方。他在不停的调用需要的逻辑方法，实现的。

Answer 5

你这分发任务机制就像MVC思想
我知道android后台service机制，你所说的action与service处理各自事情的两种想法，其实是纠结再各层面的通信上面。
首先数据库就采用户dao方式，这无所谓
action听名字,action啊,行动，动作，就应该来处理主要逻辑
而你说的这个service完全是没有必要了，就是一个中间件了，而不像是android里的service是后台服务。两种想法都能实现，我觉第一种更合理，封装起来也能容易点吧
才疏学浅，弱弱顶起，坐等高手

追问

谢谢，我也在坐等高手