一、模型概念

本文介绍了领域模型的概念,强调其作为业务对象模型,用于描绘业务角色和实体间的协作。接着,讨论了贫血模型,即领域对象仅包含get/set方法,业务逻辑集中在BusinessLogic层。然后,解释了充血模型,其中领域对象包含大部分业务逻辑,BusinessLogic主要负责事务管理和部分业务逻辑封装。最后,对比了各种模型的优缺点,指出充血模型更适合复杂业务逻辑的开发。
摘要由CSDN通过智能技术生成

一、领域模型、贫血模型、充血模型概念总结

1.1 领域模型

领域模型是对领域的概念类或现实世界中那个对象的可视化表示。专注于分析问题领域本身,发掘重要的业务领域概念,并简历业务领域概念之间的关系。

业务对象模型(也叫领域模型 domain model)是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。业务对象模型从业务角色内部的观点定义了业务用例。该模型为产生预期效果确定了业务人员以及他们处理和使用的对象之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。

1.2 失血模型

是指领域对象里只有 get 和 set 方法 (POJO 普通对象),所有的业务逻辑都在业务(Business Logic)层

这种模型并未体现JAVA的面向对象的特点。领域对象只是作为保存状态或者传递状态使用,只有数据没有行为的对象不是真正的对象,在Business Logic里面处理所有的业务逻辑,对于细粒度的逻辑处理,通过加上一层Facade 达到门面包装的效果。
优点:系统的层次结构清楚,各层之间单向依赖(Client -> Business Facade -> Business Logic -> Data Access Object。领域对象几乎只作传输介质之用,不会影响到层次的划分。

1.3 贫血模型

是指在领域对象中存在业务逻辑而没有持久化的代码、没有持久层的业务逻辑。

1.3 充血模型

是指领域对象存在大多数的业务逻辑和持久化代码,而Business Logic只是简单封装部分业务逻辑以及控制事务、权限等。层次结构:Client -> Business Facade -> Business Logic -> Domain Object -> Data Access Object。

优点:面向对象,Business Logic符合单一职责原则。
缺点:如何划分业务逻辑,什么样的逻辑应该放在Domain Object中,什么样的业务逻辑应该放在Business Logic中,很含糊。在一个就是由于业务逻辑分散在 Business Logic 和 Domain Object层中,就不能更好的分模块开发,在领域对象中既包含了业务逻辑也包含了持久化,十分混乱。其次如果Business Logic要控制事务并且为上层提供一个统一的服务调用入口点,它就必须把在Domain Logic里实现的业务逻辑全部重新包装一遍。

充血模型更加适合较复杂业务逻辑的设计开发

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值