希望看懂我想问的朋友回答下，关于action层，service层和dao层，在这里action和service不知道具体应怎么写
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了希望看懂我想问的朋友回答下，关于action层，service层和dao层，在这里action和service不知道具体应怎么写相关的知识，希望对你有一定的参考价值。
我的两种想法：
1.action负责逻辑处理，而service只是负责action调用dao的中介而已，也就是说action调用service，而service简单的调用dao,而service不负责逻辑上的处理
2.action只是负责将任务分发，然后通过service来实际处理逻辑业务，而service是通过调用dao来访问数据库的。
这里我都很疑惑，请懂的人来帮忙解答。
我的个人观点：action:控制调度；service:业务逻辑；dao层：数据库操作【例如：有一个文档上传的功能，假设你的文档上传处理action只有一个，但是你要判断是管理员上传还是普通用户上传，然后做出不同的操作，比如管理员上传的文档要进行转化生成为flash，再把生成的flash附件和文档母本都保存到硬盘，在往数据库插入一条标识当前文档的信息；普通用户无需转化只需将上传的文档保存到硬盘然后数据库插入一条标识当前文档的记录即可。】这个时候，你就可以在service层实现里面写两个方法（一个针对管理员，一个针对普通用户；注：如果管理员和普通用户每个操作都差别很大的话，比如修改差别也很大，删除差别也很大，也可以写两个sevice层的实现，他们实现自同一个接口，这里暂不考虑这种方式），然后action根据用户的类型，来控制是调用service层的哪个方法，调用完成后，跳转向哪个页面。service的那两个方法在这个例子里分别就是：【管理员上传的那个方法，玩成文档的转换，文档母本和副本的本地保存，调用dao层保存数据】【普通用户上传的那个方法，完成文档的本地保存，调用dao层保存数据】。这只是我简单的虚拟出来的一个需求，现实开发中可以根据实际情况（如，二者功能实现上的差异程度）来选择是向上面那样写两个方法，还是写两个实现类。 参考技术A 我的建议是Service用来处理业务，当然如果划分的更详细一点，可以再添加一个ServiceIMPL层，把Service里面只放业务的接口，在ServiceIMPL具体实现业务，而action主要用来处理业务逻辑。追问
action处理业务逻辑，service处理业务???逻辑和业务，可否讲的明确点
追答我的理解是：
业务比如说：增删改查；
而业务逻辑：什么时候增加，增加的条件之类的。
那你的意思就是service基本的方法是和dao的方法是一样的罗
追答也不能说一样，Service还可以处理一些别的业务，而非单纯的增删改查，如验证登陆，修改权限之类的各种你需要的业务。当然，这些你如果放在DAO里面处理也是可以的，只不过层次感差一点。
追问我知道dao是负责直接与数据库打交道的，而我不清楚的是service和action他们真是所应该负责那方面的
追答你要分清楚业务和业务逻辑的区别。这么跟你说吧。每一个业务你可以想象成一个最基本的操作，比如说增、删、改、查、验证、判断等基本操作。而业务逻辑好比再什么情况下进行这个操作，比如说，当用户点击查询时，你就该进行查询操作，当用户点击删除按钮，你就该进行删除操作，而这些请求的处理可能都交给同一个action，所以你就应该在action中写好这个业务在什么情况下进行处理，也就是业务逻辑。不知道我这样说你能否明白？这里的Service就是每一个最基本的操作。action就是用来处理业务逻辑的。
本回答被提问者采纳 参考技术B 主要是为了团体开放的分层模式，做数据库访问的专心在dao里写数据库访问的代码，写action人员负责接受前台发过来的信息和页面跳转等，做service的主要做业务逻辑当dao和action的桥梁，而且在些项目时常会有很多异常，service下还常常做一些节异常和把相应错误信息写入相应的日志文件。不分层也能写，但一旦出了问题也会混在一起，我们代码要做到高内聚低耦合，分层了也便于管理，我只写过几个web项目，一点小小的经验，仅供参考！追问我也不清楚action和service实际应该写些什么，是action实际是通过调用dao来获取数据并且进行业务处理，而service只是简单中间而已，还是说action只是业务的分发，而实际的逻辑出来才是service来处理的
追答没有绝对的界限，你可以dao什么都做了，或许项目大了你就能看出来分层的重要了，比如说数据库的事务回滚问题，每当数据库访问异常你的食物都会回滚，那么你完全在更高的层次一段代码去一次处理这个问题，而不是每个dao中的方方法中都写。
你所看到的其实是这么多年来开发人员预订俗成的规矩，就像数据库访问层不一定要叫dao一样，但团队开发这个都有用，先写以后再慢慢理解。
你的意思是action才是真实实现逻辑的地方就好像判断判断密码是否正确那样，action通过调用service只是获得了user这个对象，而action再通过这个user来实现是否密码正确，然后再返回给页面？
追答你知道struts2不？里面对密码的验证有这样的方法validatordoUser的方法可以实现验证，他是在你实现User方法之前运行的。可以说action是实现逻辑的地方。他在不停的调用需要的逻辑方法，实现的。
参考技术D 你这分发任务机制就像MVC思想我知道android后台service机制，你所说的action与service处理各自事情的两种想法，其实是纠结再各层面的通信上面。
首先数据库就采用户dao方式，这无所谓
action听名字,action啊,行动，动作，就应该来处理主要逻辑
而你说的这个service完全是没有必要了，就是一个中间件了，而不像是android里的service是后台服务。两种想法都能实现，我觉第一种更合理，封装起来也能容易点吧
才疏学浅，弱弱顶起，坐等高手追问
谢谢，我也在坐等高手
ASP.NET中MVC的理解
我想问下MVC和三层架构直接有什么区别，我已经做过关于三层架构的项目了，还想对MVC了解下，我自己看百度知道的东西不是很理解，有简单的话说下你的理解吧，回答的我满意我再给100分，别给我复制一段话
说清楚下你的理解，复制百度的就别给我回答了，我看的没意思，还是不太懂，最好能有个例子
MVC模式最早由Trygve Reenskaug在1974年[1]提出，是施乐帕罗奥多研究中心（Xerox PARC）在20世纪80年代为程序语言Smalltalk发明的一种软件设计模式。MVC模式的目的是实现一种动态的程序设计，使后续对程序的修改和扩展简化，并且使程序某一部分的重复利用成为可能。除此之外，此模式通过对复杂度的简化，使程序结构更加直观。软件系统通过对自身基本部份分离的同时也赋予了各个基本部分应有的功能。专业人员可以通过自身的专长分组：
（控制器Controller）- 负责转发请求，对请求进行处理。
（视图View） - 界面设计人员进行图形界面设计。
（模型Model） - 程序员编写程序应有的功能（实现算法等等）、数据库专家进行数据管理和数据库设计(可以实现具体的功能)。
MVC模式的缺点是由于它没有明确的定义，所以完全理解MVC模式并不是很容易。使用MVC模式需要精心的计划，由于它的内部原理比较复杂，所以需要花费一些时间去思考。开发一个MVC模式架构的工程，将不得不花费相当可观的时间去考虑如何将MVC模式运用到应用程序中，同时由于模型和视图要严格的分离，这样也给调试应用程序带来了一定的困难。每个构件在使用之前都需要经过彻底的测试。另外由于MVC模式将一个应用程序分成了三个部件，所以这意味着同一个工程将包含比以前更多的文件。
MVC模式的缺点是由于它没有明确的定义，所以完全理解MVC模式并不是很容易。使用MVC模式需要精心的计划，由于它的内部原理比较复杂，所以需要花费一些时间去思考。开发一个MVC模式架构的工程，将不得不花费相当可观的时间去考虑如何将MVC模式运用到应用程序中，同时由于模型和视图要严格的分离，这样也给调试应用程序带来了一定的困难。每个构件在使用之前都需要经过彻底的测试。另外由于MVC模式将一个应用程序分成了三个部件，所以这意味着同一个工程将包含比以前更多的文件
过去MVC模式并不适合小型甚至中等规模的应用程序，这样会带来额外的工作量，增加应用的复杂性。但现在多数软件设计框架，能直接快速提供MVC骨架，供中小型应用程序开发，此问题不再存在。对于开发存在大量用户界面，并且逻辑复杂的大型应用程序，MVC将会使软件在健壮性、代码重用和结构方面上一个新的台阶。尽管在最初构建MVC模式框架时会花费一定的工作量，但从长远的角度来看，它会大大提高后期软件开发的效率。 参考技术A MVC模式（Model-View-Controller）是软件工程中的一种软件架构模式，把软件系统分为三个基本部分：模型（Model）、视图（View）和控制器（Controller）。
MVC模式最早由Trygve Reenskaug在1974年[1]提出，是施乐帕罗奥多研究中心（Xerox PARC）在20世纪80年代为程序语言Smalltalk发明的一种软件设计模式。MVC模式的目的是实现一种动态的程序设计，使后续对程序的修改和扩展简化，并且使程序某一部分的重复利用成为可能。除此之外，此模式通过对复杂度的简化，使程序结构更加直观。软件系统通过对自身基本部份分离的同时也赋予了各个基本部分应有的功能。专业人员可以通过自身的专长分组：
（控制器Controller）- 负责转发请求，对请求进行处理。
（视图View） - 界面设计人员进行图形界面设计。
（模型Model） - 程序员编写程序应有的功能（实现算法等等）、数据库专家进行数据管理和数据库设计(可以实现具体的功能)。
MVC模式的缺点是由于它没有明确的定义，所以完全理解MVC模式并不是很容易。使用MVC模式需要精心的计划，由于它的内部原理比较复杂，所以需要花费一些时间去思考。开发一个MVC模式架构的工程，将不得不花费相当可观的时间去考虑如何将MVC模式运用到应用程序中，同时由于模型和视图要严格的分离，这样也给调试应用程序带来了一定的困难。每个构件在使用之前都需要经过彻底的测试。另外由于MVC模式将一个应用程序分成了三个部件，所以这意味着同一个工程将包含比以前更多的文件。
MVC模式的缺点是由于它没有明确的定义，所以完全理解MVC模式并不是很容易。使用MVC模式需要精心的计划，由于它的内部原理比较复杂，所以需要花费一些时间去思考。开发一个MVC模式架构的工程，将不得不花费相当可观的时间去考虑如何将MVC模式运用到应用程序中，同时由于模型和视图要严格的分离，这样也给调试应用程序带来了一定的困难。每个构件在使用之前都需要经过彻底的测试。另外由于MVC模式将一个应用程序分成了三个部件，所以这意味着同一个工程将包含比以前更多的文件
过去MVC模式并不适合小型甚至中等规模的应用程序，这样会带来额外的工作量，增加应用的复杂性。但现在多数软件设计框架，能直接快速提供MVC骨架，供中小型应用程序开发，此问题不再存在。对于开发存在大量用户界面，并且逻辑复杂的大型应用程序，MVC将会使软件在健壮性、代码重用和结构方面上一个新的台阶。尽管在最初构建MVC模式框架时会花费一定的工作量，但从长远的角度来看，它会大大提高后期软件开发的效率。 参考技术B 楼上的是错的，MVC不是三层。
三层架构中，DAL(数据访问层)、BLL(业务逻辑层)、UI(显示)层各司其职，意在职责分离。
MVC是 Model-View-Controller，严格说这三个加起来以后才是三层架构中的显示层，也就是说，MVC把三层架构中的UI层再度进行了分化，分成了控制器、视图、实体三个部分，控制器完成页面逻辑，通过实体来与界面层完成通话；而C层直接与三层中的BLL进行对话。追问
到底什么区别了，你还是没表达清楚
追答首先你要知道三层跟MVC根本不是一个东西
三层是将整个业务由数据到逻辑处理到显示分离开来，体现高内聚，低耦合。
MVC是一个设计模式，用来强制性的使应用程序的输入、处理和输出分开。
MVC是一个设计模式，用来强制性的使应用程序的输入、处理和输出分开。
MVC是设计模式，那么实现的时候怎么实现的？还是不太明白
你想要单独按照MVC模式来做应用程序那可难了，不过现在大都提供了现成的MVC框架，比如微软的MVC3。
想理解MVC，建议你去看看headfirst的设计模式，或者国人写的大话设计模式，或者最经典的GOF的设计模式。
MVC就是设计模式吗？我现在学了观察者的和策略的，其他的还在慢慢学习，现在就是想了解多一点MVC的知识，马上就要找工作了，感觉这个还是不太了解
追答MVC最复杂的复合型设计模式之一，建议你好好看看那几本书，MVC是依据其他模式建立起来的。如果不懂设计模式的话，找工作估计也会难一点吧，至少你要知道MVC里面包含了那几种模式....
追问MVC是不是所有的设计模式都包含进去了，您能不能介绍下包含了哪一些设计模式呀？
追答当然不是了........
视图和控制器:策略模式
视图中的显示:组合模式
模型:观察者模式
还利用到了其他的什么模式吗，这几个模式我都有所了解
追答没有，就这几个
本回答被提问者采纳 参考技术C MVC其实就是三层架构, M是指Model, 模型, 其实就是实体类, V是指View视图, 就是界面层, C是指Controller控制, 就是逻辑层 参考技术D mvc中的View,Controller（也可包括Model，也可单独作为Model层）就是三层结构中的表示层以上是关于希望看懂我想问的朋友回答下，关于action层，service层和dao层，在这里action和service不知道具体应怎么写的主要内容，如果未能解决你的问题，请参考以下文章