如果是贫血模式 就不是多此一举 项目前期 或者小项目没什么太大区别但是项目大了以后 区别就很大了 项目开发到后期的话 你一个项目内包含有其他的小项目 比如 后台 erp 商城 等等 都用的是同一个数据库 这个时候 就不能使用一个service/biz 全部解决了 有些业务是通用的 有一些业务可能只有erp有 其他模块没有 也有可能同一个业务 在细微上有一些差别 如果全部都放进一个业务层中的话 这个业务层就会非常的臃肿 这个时候就需要拆分 一个基础业务层 一个应用层业务层 基础业务层只是针对该对象的CURD操作 应用业务层就是一个复杂的功能模块或流程 举个例子 service作基础业务层 biz作为应用层业务层比如我现在要在商城中 做一个下单功能 牵涉到商品,库存,活动等等 那么我把这个东西放哪呢? 订单service层? 如果放到这里 订单service层中就会引入商品,库存,活动的service或dao 如果还有其他功能 那么这个模块牵涉到的功能就越来越多 所以并不合适 不光商城中牵涉到订单service 后台也可能会用到 erp也可能会用到 那么这时候就需要做个一个应用层 可以去了解一下 DDD 领域驱动设计
如果是贫血模式 就不是多此一举
项目前期 或者小项目没什么太大区别
但是项目大了以后 区别就很大了
项目开发到后期的话 你一个项目内包含有其他的小项目 比如 后台 erp 商城 等等 都用的是同一个数据库
这个时候 就不能使用一个service/biz 全部解决了 有些业务是通用的 有一些业务可能只有erp有 其他模块没有 也有可能同一个业务 在细微上有一些差别 如果全部都放进一个业务层中的话 这个业务层就会非常的臃肿
这个时候就需要拆分 一个基础业务层 一个应用层业务层
基础业务层只是针对该对象的CURD操作 应用业务层就是一个复杂的功能模块或流程
举个例子 service作基础业务层 biz作为应用层业务层
比如我现在要在商城中 做一个下单功能 牵涉到商品,库存,活动等等 那么我把这个东西放哪呢? 订单service层? 如果放到这里 订单service层中就会引入商品,库存,活动的service或dao 如果还有其他功能 那么这个模块牵涉到的功能就越来越多 所以并不合适 不光商城中牵涉到订单service 后台也可能会用到 erp也可能会用到 那么这时候就需要做个一个应用层
可以去了解一下 DDD 领域驱动设计