Repository、Model、Service、Controller术语解析及依赖关系详解

我来把这几个后端核心组件讲清楚，用直白的定义、差异和真实案例帮你理顺关系：

1. 各组件直白定义 #

Model（模型） #

• 就是数据的原型模板，对应数据库里的表（或其他数据源的实体），用来封装数据的属性和最基础的数据行为。比如电商里的Product模型，包含ID、名称、价格、库存这些字段，最多再加个getDiscountPrice()方法计算折扣价——只跟数据本身有关，绝不碰业务逻辑或数据库操作。
• 核心：只负责“数据长什么样，基础数据怎么处理”。

Repository（仓库） #

• 是专门管数据访问的工具层，所有和数据库（或Redis、ES等数据源）打交道的操作都放这儿。比如ProductRepository会提供findById()查商品、save()存商品、updateStock()改库存这些方法，底层会帮你写好SQL或调用数据源API。
• 核心：屏蔽数据访问的底层细节，让上层不用关心用的是什么数据库，只管调用接口拿数据。

Service（服务） #

• 是业务逻辑的核心实现层，负责把多个Repository操作、第三方服务调用（比如支付、短信）组合起来，完成一个完整的业务流程。比如创建商品时，Service会先校验参数，再调用分类Repository确认分类合法，接着调用商品Repository存数据，最后调用库存服务初始化库存——把零散的步骤拼成符合业务规则的完整流程。
• 核心：处理复杂业务规则，协调多个数据源或服务，是业务逻辑的“大脑”。

Controller（控制器） #

• 是对外交互的入口接待员，负责接收前端（或其他服务）的请求，校验参数合法性，然后调用对应的Service处理业务，最后把结果封装成响应返回。比如POST /api/products接口，Controller会接住前端传的商品信息，喊Service去创建商品，再把创建好的商品ID和详情打包成JSON返回。
• 核心：只管请求进来、响应出去，不碰任何业务逻辑。

2. 核心差异对比 #

• Model vs Repository：Model是数据的“样子”，Repository是操作这个数据的“工具”——Model定义商品有啥属性，Repository负责把商品存进数据库或从数据库拿出来；
• Repository vs Service：Repository只做单数据源的CRUD（增删改查），Service做跨数据源/跨服务的业务组合——Repository只会存商品，Service会把“存商品+初始化库存+校验分类”整个流程串起来；
• Service vs Controller：Service管“业务怎么实现”，Controller管“怎么接请求和给响应”——Service知道创建商品要走哪些步骤，Controller只知道前端要创建商品，把参数传给Service，再把结果返回。

3. 真实案例：电商商品创建全流程 #

用一个用户创建商品的完整流程，看各组件的协作和依赖关系：

1. Controller层动作：

   • 接收前端POST /api/products的请求，参数是商品名称、价格、分类ID；
   • 先校验参数：价格不能为负、分类ID不能为空；
   • 调用ProductService.createProduct(商品参数)；
   • 把Service返回的商品ID和详情封装成JSON响应，返回给前端。

2. Service层动作：

   • createProduct()方法先调用CategoryRepository.findById(分类ID)，确认这个分类在数据库里存在；
   • 用前端参数生成一个ProductModel实例；
   • 调用ProductRepository.save(ProductModel)，把商品数据存入数据库；
   • 调用InventoryService.initStock(商品ID, 100)，给这个商品初始化100件库存；
   • 最后把创建好的ProductModel返回给Controller。

3. Repository层动作：

   • ProductRepository.save()执行SQL：INSERT INTO products(name, price, category_id) VALUES(?, ?, ?)，把Model里的数据写入数据库；
   • CategoryRepository.findById()执行SQL：SELECT * FROM categories WHERE id = ?，返回对应的CategoryModel。

4. Model层动作：

   • ProductModel持有id、name、price、categoryId、createTime这些属性；
   • 如果有促销活动，getDiscountPrice()方法会返回price * 0.8（打8折）的计算结果。

依赖关系链 #

整个流程的依赖是上层依赖下层，下层不依赖上层：
Controller → Service → Repository → Model
这样分层的好处是，比如要把数据库从MySQL换成MongoDB，只需要改Repository层，Service和Controller完全不用动；要改创建商品的业务规则（比如加个审核步骤），只需要改Service层，Controller和Repository不用变。

内容的提问来源于stack exchange，提问作者Kaushlendra Tiwari