关于service层的作用，有点疑惑，求各路前辈指点迷津

Question

参与了一个不算复杂的项目，从web层写到dao。突然产生了一个疑惑。
第一个问题：
     通常都说service层负责实现业务逻辑，dao封装数据库访问。
     但是我在页面实现的功能大多数都是按照表单条件查询，插入什么的。
     实现的方法就是在DAO层根据传进来的DTO拼装sql进行数据库操作。service层什么也没做其实。不是说service层封装逻辑么？但是我实现功能的逻辑不是都是由sql来体现的么？
     比如我要查名字=张三的人，这个逻辑不是最后由dao层的sql反应的么？
     那DAO层不就是和业务逻辑关联的，这能算解耦么？dao层感觉做特别多事
     第二个问题：
     而且我在做这个项目的时候，大部分功能都是页面传vo给controller（springmvc）再传dto给service（service基本不做事，或者很少一点）再传给DAO(dao负责按页面需求功能拼接sql，感觉这里就是主要做的事了）。 
     整个过程完全没感觉有要用到什么设计模式的必要……我自己在dao层尽量重构了下代码（多抽几个小方法，避免重复代码什么的） ，其他就完全没觉得有什么书上说的常见的各种模式的运用了（工厂模式，单例什么的还是有，不过是别人用来封装项目架子和辅助工具类的时候用的，自己写业务逻辑的时候感觉完全用不上什么模式）
     问了问项目组的前辈，也说不出个所以然，大意就是……项目比较小白，用不上啥设计……
     有各路路过的前辈能就自己的项目经验讲讲么？
      service层为什么啥事都没做而dao那么厚？
     设计模式在项目的运用例子？（简单讲讲）      菜鸟自学不容易……先谢谢各路大神了。
设计模式WebERP

Answer 1

在项目中，控制器完成的工作主要是流程控制，及请求相应，根据对应的结果返回对应的视图，具体的业务代码代码不应该写到控制器里，而是交给service负责实现。比如要验证一个用户名是否存在，应该在控制器里调用Service层的验证的方法，由service去验证用户名是否存在，而service再调用dao层，dao层跟底层的数据库打交道，查询出结果返回service层，service层返回结果给控制器层。控制层根据结果返回对应的资源。
如果涉及到到了dao的操作，都是由service去调用dao的。
个人认为，所谓的耦合是指在编译时就确定了类型，如果要更改，得全部修改。而采用面向接口编程，运行时才知道具体实现的是那个类。控制器在运行时才知道具体实现的是哪一个service，service在运行的时候才知道具体实现的是哪一个dao。

Answer 2

感觉楼主对mvc基本已经很了解了,就够了,代码没有什么要求非要写成什么样子了,代码写多了,阅读优秀的代码多了自然而然的就懂了,现在说再多无非也就是解释mvc没什么意义

Answer 3

业务逻辑拼接sql应该放到service里，dao负责执行这个语句就可以了，你将sql放到dao里拼接其实是在用dao处理业务逻辑，dao应该只负责数据库访问。
关于设计模式的话小项目很少用到，用最简单的方法解决问题就好

Answer 4

service曾的主要作用是实现业务逻辑  和 控制事务
简单的增删改查 不用service也没关系

Answer 5

4楼的兄弟，你确定这件事么？我就是这么认为的。
其他楼的兄弟没看懂我的问题啊。
我就觉得 按照页面上的功能实现拼sql这件事本身不就是业务逻辑了么？放在DAO层做，不就是和业务逻辑相关了？正确的做法应该是在service层拼sql然后传给DAO？
    还有木有大神给说说~？

Answer 6

个人理解 
对于小项目来说 后台业务逻辑主要就是数据库操作和一些补充 所以小的项目服务层的业务逻辑就会显得特别少 因为数据库操作都被封装到dao层了 比如一个登陆设置 dao层主要负责就是在数据库中查找用户信息并返回 而服务层相关就是接受dao的返回并和用户名比对 和密码比对 
dao层给我的感觉的是特定的数据库操作的封装 比如查用户名 返回用户信息 或者查特定的信息 至于查出来干什么 那是服务层的事了。
感觉学的还不深 如果有什么问题请指出。 

Answer 7

举个简单的例子，3张有关联关系的表，通过1张表的数据得出或更改其他表的数据，这些操作你要在Dao层和控制层里写吗？逻辑操作再多点呢？

Answer 8

什么逻辑，操作，持久化，控制代码，你全写到一个文件里都行。
小项目有的时候service就是个摆设，大点你就知道了。你恨不得再多分几层

Answer 9

没有谁规定一定要有个Service，只要你觉得你的框架能够达到如下目的即可：1，实现功能
2，完成第1点的基础上，尽可能减少代码或者配置
3，可以对可预见的变化比较方便的进行修改或者扩展
4，方便测试或者调试所以，如果你能实现上述目标，没Service就没Service了以下部分，纯碎是个人偏好，不同意的，直接略过，而且稍微有点偏题：我个人很讨厌Service/DAO都有还不算（这个很正常），没事却一定要写个Service和DAO的接口，而这个接口放上一千年，也就只有一个实现版本的情况。话说，这里绝大部分人写的绝大部分系统：1，数据库迁移，比如从oracle <----> mysql真的不是很常见，至少我知道的，大部分类似的迁移，不是简简单单通过配置换个接口的实现，就能搞定的。所以，写个接口为了数据库迁移做准备这点，你就不用考虑了。
2，业务变化，这点确实，有接口，实现好几种模式都会方便点。但是，如果没有碰到或者在可预见的将来会发生，似乎也不必要先放进去
3，为了Spring注入，话说，直接面向实际的类，也能用Spring我喜欢的风格，说白了，就是别太罗嗦了，一样实现一个目的，分层当然要，但是别太多

Answer 10

关于拼接SQL那部分，我这里是很少很少有拼接SQL的。如果是页面查询，根据用户输入的查询条件拼写，我的做法是用SQL的模板，让DAO（里面的工具类）自己把模板和传入的条件结合起来。比如：SELECT * FROM table
 WHERE delFlag = 0
 [ AND x = :x ]
 [ AND y = :y ]
如果参数X为空，Y非空，自动变成
SELECT * FROM table
 WHERE delFlag = 0  AND y = ? 
并且自动进行参数设置（比如，ps.setXxxx(1, param.y))当然类似的方式还是很多的比如batis里面也可以写模板窃以为，由于此类查询是最常见的功能，而且无论是业务还是技术，都不是很复杂。所以，每次新增一个页面查询，或者调整某个页面上的条件个数，就要程序员在程序里面写或者改N个if，拼接SQL的框架，都是对程序员不太友好的框架。这点上，就好比对输入进行最简单的required, date这样的常见操作，如果你的项目里，你还要手写if，那绝对是不合适的。

Answer 11

只能说目前楼主接触的项目还比较少、比较简单。真正大型的项目并非只是根据页面的条件进行增删改查的。
查询的时候页面传递给service层的只是简单的一些查询条件，但是页面需要显示的查询结果的数据并不在同一个对象（或者说表）中，这就需要service层进行一些逻辑处理了，比如将这些查询条件进行拆分、组合用以查询不同的数据，然后再将这些不同的数据进行整合反馈给前台页面显示。这仅仅只是一个简单的例子，真正用的时候会有很多逻辑在里面。