dao层和service层分别是充当什么角色的，举个简单例子，小的在此谢了。

dao完成连接数据库修改删除添加等的实现细节，例如sql语句是怎么写的，怎么把对象放入数据库的

service层是面向功能的，一个个功能模块比如说银行登记并完成一次存款，UI要把请求给service层，然后service曾将这一个case分解成许多步骤调用底层的实现完成这次存款，dao就是下面那层

dao就是把数据存起来，之所以service的方法会有雷同只不过是因为service得需求不是很复杂不用再service里面完成太多包装或者处理过程可以直接调用dao的方法就完成的请求处理例如就要save一个对象，而这个对象是封装好的，dao里面有个方法专门save封装好的对象于是service的方法就仅仅调用一下就o了，函数签名自然很像了

service不能直接接触持久层，而dao是持久层或者直接访问持久层

有的时候只是为了分层清楚，为了将来scale up的时候方便我们才把service和dao分开，其实没必要分开的

首先我们先知道spring的项目分层：

按照MVC的设计理念来讲，由service服务层调用持久层dao，在由controller调用service，这符合MVC的分层结构也符合我们的编程习惯。

dao一般是做封装，service做业务，controller校验数据

要是controller直接调用dao的话，controller直接拿到数据这是不安全的，而且平常的一些业务逻辑处理不好处理，因为业务需求是实时改变的，把业务写在dao里还要全部更改业务信息，这样不仅不会节约成本还增加耦合，代码复用性也不高后期代码维护也困难。建议还是遵循MVC分层结构开发，尽管是少量数据也不建议直接调用dao。关于好处可以上别人博客借阅：网页链接

java是针对接口编程，制定编程规范，这样就拥有较好的可扩展性。做个小项目使用接口看起来还麻烦了，但是做大的项目就不一样了，针对接口编程就显得很重要了，利于维护和扩展。而且在分工上也比较容易配合。比如，我要调用service层方法，直接通过接口调用方法就好了，完全不必关心方法的实现，可以由团队的其他人来做。另外，不针对接口编程，做的只是一个项目。而针对接口编程，可以做成产品，然后在产品的基础上构建项目。相同领域的项目，很多只是具体实现的细节不同而已。

controllerservicedao有必要拆成三个模块

1Controller层

负责在页面和程序之间传输数据的，做页面的跳转。用户在页面中填写完表单数据，点击提交按钮，页面的表单数据由Controller传入Service层。

Controller层负责具体的业务模块流程的控制，在此层要调用service层的接口来控制业务流程，控制的配置也同样是在Spring的配置文件里进行，针对具体的业务流程，会有不同的控制器。设计过程可以将流程进行抽象归纳，设计出可以重复利用的子单元流程模块。这样不仅使程序结构变得清晰，也能减少代码量。

2Service层

负责业务模块的应用逻辑设计。Controller只负责管理，而Service负责实施。同样是首先设计接口，再设计其实现类，然后在Spring的配置文件中配置其实现的关联。我们就可以在应用中调用service接口来进行业务处理。service层的业务实，具体要调用已经定义的dao层接口，封装service层业务逻辑有利于通用的业务逻辑的独立性和重复利用性。

3DAO层

负责对数据向数据库增删改查的 *** 作。

dao层主要做数据持久层的工作，封装了负责与数据库进行联系的一些任务，dao层的设计首先是设计dao层的接口，然后在Spring的配置文件中定义该接口的实现类，然后就可以调用该接口来进行数据业务的处理，而不用关心此接口的具体实现类是哪个类，结构清晰，DAO层的数据源，以及有关的数据库连接参数都在Spring配置文件中进行配置

以上就是关于dao层和service层分别是充当什么角色的，举个简单例子，小的在此谢了。全部的内容，包括:dao层和service层分别是充当什么角色的，举个简单例子，小的在此谢了。、spring mvc里面,为什么要单独出来一个service层调用dao再传给controller啊 这样设计有什么好处、j2ee项目里面service层里面为什么要建立一个接口，一个实现类等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！