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

[ukipoi]

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

[WuwuGin]

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

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

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

如果理解有误，请指出。

[TomVista]

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

[mrcode]

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

[yidinghe]

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

[liuxey]

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

[ukipoi]

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

[wysnylc]

MVC 和三层架构是两个东西

[lcdxiangzi]

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

[visonme]

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

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

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

[qwertyzzz]

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

[luosuosile]

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

[southsala]

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

[lovelybear]

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

[BeFun]

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

[wly19960911]

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

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

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

[DamonLin]

增删改查就是业务啊

[koalli]

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

[519718366]

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

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

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

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

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

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

[zpf124]

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

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

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

[jingyulong]

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