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

事实上 mvc 没有绝对的规则，只有抽象的概念。

一般理解的是 mvc 中，model 负责数据库那边的抽象，以及实际功能的完成，controller 负责连接前者和 view 之间的关系。

一个 controller 里面可以使用多个 model 也不冲突啊，个人认为这和操作对象没关系，总的来说还是业务关系，比如用户的登录、注册、密码修改都可以在 user controller 里面完成，但是他们只是在逻辑上有关联。

如果理解有误，请指出。

业界难题,程序员也不知道程序员口中的业务是什么,可能连说话本人都不知道

就是除去持久层，接口层剩下那一大堆逻辑，不知道怎么细分这一大堆东西，所以取了个名字叫业务层

业务就是：
1、从数据库查出数据来，如何展现到界面上；
2、用户操作数据时，如何保存到数据库；
3、有什么需要同外部服务交互的功能（例如微信扫码登录）；
4、有什么需要执行的定时任务。

MVC 是 Model – view – controller，service 是在三层架构范畴里 View、Service、Dao。
至于怎么分， 看你们的业务特点，大厂的系统是分的很细的，而且是经过多年沉淀形成，所以我觉得一开始 service 就跟着 controller 走，不够了再加，就像你说的，先按照位置来做，后期慢慢服务化后就会出现各种细分服务。

@mrcode
我现在遇到一个问题，持久层写好了。Controller 建立好分类了，我是根据用户所在的页面做的分类。
但是我不知道怎么给 Service 做分类，不知道起什么名字。。。

MVC 和三层架构是两个东西

个人理解，mvc 是一个偏技术的概念，与业务耦合不大。从技术设计的思路上考虑，应该将 mvc 的设计和数据模型结合起来，因为 mvc 是对业务流程的梳理框架。这样的好处是会降低技术实现的复杂度，在一定程度上实现流程和数据的统一。
个人理解，希望可以和大家探讨。

@ukipoi
命名可以根据具体的功能，比如处理订单的用 OrderService, 根据具体的情况，要细分，比如 OrderStatusService 处理订单状态相关的业务等.

service 一般我们划分为具体的业务 service 跟基础 service.
具体的业务 service 处理类似订单，用户等业务。
基础 service 处理日志只，异常，消息等

在某些系统架构中，如果需要我们还会引入业务数据模型，controller 处理接收和组织业务数据模型，然后将业务数据模型传递给 service，service 处理后，将业务数据模型映射到最终的数据模型.

service 里好像是写方法 controller 里调用 不是一个东西吧 根据具体对象归纳吧感觉

我觉得就是业务逻辑，dao 层只写和数据库交互，service 只写业务逻辑，controller 只写和外界交互。暂时我时这么理解的，我也才用不久

什么 MVC MVP MVVM 去撸代码，撸多了就明白了

增删改查，各种算法输出，各种分析

面向对象开发，你就把每个东西当做对象，对对象的操作就是业务。有个 DDD 领域模型的东西可以了解一下

MVC 指的是 view 层的一个关系，model-view-contoller。

三层架构是 数据库访问 - 业务逻辑 - view，也就是说 MVC 是三层架构中的 view 层。

这个必须分清楚的，MVC 和业务交互的只有 contoller，你说的是 controller 和 service 的一个关系。

增删改查就是业务啊

@ukipoi
解耦是为了什么？是为了提高模块的内聚性。
从这一点来看，用户模块就应该专注于注册、修改、获取数据等，订单模块就应该专注于新增、修改订单等。
各个模块应该专注于各自的功能，因此我认为 Service 应该根据具体的用途来划分，就根据具体的用途来命名就好了。

MVC 这个真的是玄学的东西，大家都知道要 mvc，也会去这么做，但是做法真的千奇百怪。
我个人现在这么做的

model->就是各种操作数据库的代码（**Mapper, **Dao)，返回的对象一般以 DO 结尾（参考阿里规约）

controller->就是接收请求，做些简单的参数验证，然后就直接调 service 层里的具体服务（一般调一个 service 就行），然后将 service 返回的 DTO 对象转成 VO 对象返回就完事儿了

service->那里的代码就很复杂了，调 model 层的 Mapper 获得数据，调其他 service 获得数据，通过各种手段获得数据后，噼里啪啦再对数据各种组装转换成一个 DTO 返回就完事儿了

service 里有简单的对 model 层 CRUD 封装的 service，也有超级复杂的调各种 service 的高级 service

个人理解，扔出来大家探讨探讨

我觉得 是 java 大企业推出的细分模块后规范， 慢慢累积下来的 啰嗦的、复杂的 包名规范。

java 里面的 service 包还有 controller 包 实际上都是 MVC 模型里面的 C, Controller。

具体实践 我觉得 #17 的那种方式其实应该是更合理的实践，service 里写大多数于页面无关于持久化无关的代码。

Model 有几种，domain model,view model ,input model。从数据来看业务层就是来处理 domain model 的，可能有多个 domain model。
在此基础上，可以使用 DI 解耦，就是所谓的 service。所有 Service 就是业务层。

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

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

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

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

首先纠正楼上一些严重误人子弟的观点：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 人工作量的机械条款，看到的时候要无视。

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

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

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

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

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