请教一下 Java MVC 设计里业务层的'业务'是什么？

[ukipoi]

service 里应该怎样做分类？
是把一个用户做的操作（注册、登陆、购买、修改个人资料等）归为一类，还是根据操作对象来分类？
还是根据用户执行操作的位置分类？（比如说用户在个人中心界面，那么其中所有的操作归为一类。用户在商城页面，又归为一类）不过这好像是控制层做的事情？

[choice4]

简单的比如把数据库的 0 变成字符串的女 类似这种吧。。

[wshcdr]

是把一个用户做的操作（注册、登陆、购买、修改个人资料等）

注册，登录，购买这些都是业务...

[aa6563679]

mvc 和后台三层架构是不同的，mvc 没有业务层

[passerbytiny]

首先纠正楼上一些严重误人子弟的观点：model 不是 dao，model 不是负责数据库那边的。后面再解释。

MVC，Model、View、Controller，或者叫做模型、视图、控制器，这是一种将系统的交互部分与主体部分解耦的设计思想；业务层，或者 Service 层，是一种纵向分层解耦技术的术语：二者原本一毛钱关系都没有，是后人硬给弄到一起的。

举些例子：
MVC 鼻祖 Struts，三部分分别指的是 Action 类的非自动部分及其关联代码、Struts 标签及 JSP、Struts 配置文件和 Action 类的自动部分；
Struts2 给 V 加上了模板等非 JSP 技术，C 部分的内核换成了拦截器，本质上是 M、V、C 各自丰富，总体思想不变；
Spring MVC，M 只是 Controller 类的方法及其关联代码，V 是模板或压根就没有，C 是 Controller 的注解、自动绑定等等，实际上可以认为只有 C。
请注意，以上三个，虽然都建议你只在 Action 或 Control 中定义执行简单处理或跳转，但 Action 和 Controller 的非自动处理部分，仍然是处于 M 部分：分离成 M、V、C 三部分后，并不妨碍对 M 部分再继续纵向分层，Action 和 Controller 的非自动处理部分，是 M 部分的最上层。

至于后人为什么回混用 MVC 和纵向分层呢，因为简化和更易推广。在那个 J2EE 分离年代，那时候一般这样分层：JSP/自定义标签 /模板、Action/Controller、Service、Dao。这是简化过的，拆开后是：1，JSP/自定义标签 /模板； 2.0，Struts/Struts2/Spring MVC 框架和 /或配置文件； 2.1，Action/Controller 的自动部分（自动绑定等）； 3，Action/Controller 的非自动部分（手工校验、格式转换等）； 4，Service 层，5，Dao 层。1 是 View，2.0、2.1 是 Controller，3、4、5 是 Model。简化后的相比拆开后的更容易学习，更容易推广，这个不光是培训班的需要，也是 Java 社区的需要。如果作为科普来看，这种简化功不可没，虽然现在有点尾大不掉了（后面解释）。

再举个例子，按照现行的前后端分离技术，采用领域驱动设计和依赖倒置分层，那么程序是这样分离的（基本没有纵向分层了）：
V 部分，单层或 MVVM 等前端架构；
C 部分，路由、自动绑定、Controller 等等（此时 Controller 完全作为控制器）；
M 部分，领域模型（含模型、领域服务、存储库）、应用服务（事务边界）、基础设施；

最后解释前面留的点。
model 的含义是模型，也可以理解成建模。广义上，模型指的就是程序，因为程序就是用一种特别的模型来解决现实问题的。MVC 思想上，模型仍然是广义的程序概念，只不过特别把人机交互部分拿出去了。狭义上，模型一般指的是具有特定属性和行为的某件事物，或者说，特别的“类”和“对象”。DDD 中就代表现实事物的 model 是模型，前端 MVVM 架构中代表数据的 model 是模型，Java Bean 和 EJB 是模型，就算是没有行为的贫血领域模型也勉强可以算上是模型。dao 或**Mapper 这样的类，只是抽象 /封装实体的持久化功能的，只有无状态行为，没有属性，它们显然不可能成为模型。
再来说说简化分层的尾大不掉，这个尾巴，硬是把 Java 从面向对象语言，拉回了面向过程语言。简化的目的，本来只是为了降低难度，并将展现、校验、数据库操作这些末枝操作分离出去，腾出来时间好好的去弄“ Service ”，然而就像大部分“简化”一样，不知不觉就本末倒置了，本该简化的其它三个被重视了，不该简化的“ Service ”反而直接被简化成了无状态服务，或者干脆就叫它函数，标准的面向过程编程概念。
楼上有人提到了阿里规约，忠告一句：尽信书不如无书，阿里规约里面充斥了大量为了减少 REVIEW 人工作量的机械条款，看到的时候要无视。

[519718366]

@passerbytiny 看了大佬的回答，发现我的回答前面不应该提 MVC 的😂
准确的说应该是 MVC 思想对后端的影响，所以回答里没提 V。
赞同大佬的 M 肯定不是单单指 Dao，Mapper
在后端，整个数据获取和数据处理代码都是 M，只不过 M 里分了 dao 包和 service 包来解耦复用代码

[cyril4free]

mvc 和 restful 的理解可能都是一千个程序员 500 种理解

[ukipoi]

@passerbytiny
不好意思再问一些问题。有点没看懂。
MVC 这块，View 就是程序处理完毕展示的结果吧。
Model 这个其实不是程序里的实体类而是对外部来说的模型么？我举个例子，拼装一个四驱车模型。实际的部件是底盘、外壳、轮胎、电池等。但是外部来说就是一个汽车的模型。四驱车的部件是程序里的实体类，但是 MVC 的 M 部分是指 拼装 的车模。 请我我这个理解对吗？因为看到前辈说 “ Spring MVC 的 M 只是 Controller 类的方法及其关联代码” 我就这么理解了。 不好意思，我的说法有些混乱，可能是我本来的思想有问题。我觉得我原先可能搞错了一个问题才会有这样的疑问。（程序里常见的 Model 包下的实体了其实本来就是外部要操作的模型设计的而不是对应数据库而设计的，应该是这样的吧。）
-------
我花了点时间重新思考了一下，Model 是不是包括完成一次操作的所有内容啊，如果我可以在一个类里面完成 获取要修改的数据、连接数据库、操作数据库、返回数据 的所有操作 那这个类就是 Model 部分；而 controller 只是说这个 Model 的入口或者把这个 Model 拆开，依靠配置让 Model 可以找到下一个部分的内容。
MVC 是不是可以这样子来描述啊 V -> C -> M -> C -> V

[V2XEX]

@passerbytiny 你总结得不错
还记得刚开始学框架时心里就一直有一个疑问：所谓的 MVC 分层的这个 m 为何没有按“面向对象”的思想承担起属于自己的“行为”。
依你看，现在把所谓的“业务放到” pojo 里的做法是否妥当呢？

[helloSpringBoot]

@passerbytiny 赞一个。解决了我好多不清楚的地方