mvc 的 model 层为什么要分为service和dao？

mvc中的 v 为视图最易于理解，只把前端和后端分离。

c 为路由控制，权限控制等，以及根据参数灵活调用 model，但一般不处理数据。

那么 model 实际就是对事务逻辑的真正处理。

model 会有很多的处理代码，并且其中会和数据库操作【也就是必须执行一些sql】。

随着业务的越来越庞大，比如一个用户，有几十种操作，那么对用户表会有大量的sql操作，比如用户的余额会有很多的增删改查。

运营一段时间后，突然发现余额异常了。而业务如此庞大，代码 和 sql 又混杂在一块，显然难以找到问题所在。

又或者说，随着业务数据量庞大，原先可能使用 sqlite，或 mysql，现在要改成 Oracle，理想情况下是改sql就可以了，我不懂代码但是我觉得我改sql就可以了，但是现在代码和sql混杂在一块，这明显是不可能的。

甚至是，把编程语言改一改，我们认为只改代码就行了，sql不用动呀，但是这个想法也必然落空了。

我们发现，model是逻辑处理，处理必然有编程语言代码和sql，但从维护的角度来讲，代码、和sql实际应该分离。所以 model 笼统的分为了 service 和 dao 分别对应代码和sql。

service 是逻辑代码的处理也就是编程语言代码不要写sql，而 dao 则相反，只写sql【所以后来dao也叫数据处理层】。

基于以上认识，仍然是模糊的，那么 dao 到底该怎么处理？一般我们会认为就是写一个方法，把sql写在里面，而且一直以来也是这么做的。

后面又有了更实际的方案，比如 orm ，实体类和数据库字段对应。只是因为惯性思维会觉得dao是写函数，而实际dao仅仅是分离sql，至于怎么分离总之是尽可能的分离就是它原本的意义，所以 orm 和 dao 并不是对立关系，而是说 orm 是 dao 的一种实现形式。