学习
实践
活动
专区
工具
TVP
写文章

贫血模型和充血模型

贫血模型是指领域对象里只有 get 和 set 方法(POJO),所有的业务逻辑都不包含在内而是放在 Business Logic 层。 在使用 Spring 的时候,通常暗示着你使用了贫血模型,我们把 Domain 类用来单纯地存储数据,Spring 管不着这些类的注入和管理,Spring 关心的逻辑层(比如单例的被池化了的 Business 贫血模型实施的最大难度在于如何梳理好 Business Logic 层内部的划分关系,由于该层会比较庞大,边界不易控制,内部的各个模块之间的依赖关系不易管理,可以考虑这样这样的实现思路: (1)铺设扁平的原子业务逻辑层 它的优点是面向对象,Business Logic 符合单一职责,不像在贫血模型里面那样包含所有的业务逻辑太过沉重。 使用 RoR 开发时, 每一个领域模型对象都可以具备自己的基础业务方法,通常满足充血模型的特征。充血模型更加适合较复杂业务逻辑的设计开发。

13210

DDD领域驱动设计 — 贫血模型与充血模型

前言 要想深入掌握和了解 DDD 领域驱动设计的核心,那无论如何也绕不开两大较为抽象的概念——“贫血模型”、“充血模型”: 贫血模型即事务脚本模式。 充血模型即领域模型模式。 | 贫血模型 贫血模型最早广泛应用源于EJB2,最强盛时期则是由Spring创造,将: “行为”(逻辑、过程); “状态”(数据,对应到语言就是对象成员变量)。 作为领域模型的推广者,他们觉得这不是一件好事。 贫血领域模型的基本特征是:它第一眼看起来还真像这么回事儿。项目中有许多对象,它们的命名都是根据领域来的。 更糟糕的是,很多人认为这些贫血领域对象是真正的对象,从而彻底误解了面向对象设计的涵义。 如今,面向对象的概念已经传播得很广泛了,而要反对这种贫血领域模型的做法,还需要更多论据。 因此实际工程场景中,是否使用,如何使用还依赖于设计者以及团队充血模型设计的理解和把握,因为现在绝大多数J2EE开发者都受贫血模型影响非常深。

31331
  • 广告
    关闭

    新年·上云精选

    热卖云产品年终特惠,2核2G轻量应用服务器7.33元/月起,更多上云必备产品助力您轻松上云

  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    DDD领域驱动设计-充血模型贫血领域模型

    贫血模型即事务脚本模式 充血模型即领域模型模式 贫血模型 最早广泛应用源于EJB2,最强盛时期则是由Spring创造,把 “行为”(逻辑、过程) “状态”(数据,对应到语言就是对象成员变量) 分离到不同的对象中 贫血领域模型的基本特征是:它第一眼看起来还真像这么回事儿。项目中有许多对象,它们的命名都是根据领域来的。对象之间有着丰富的连接方式,和真正的领域模型非常相似。 更糟糕的时,很多人认为这些贫血领域对象是真正的对象,从而彻底误解了面向对象设计的涵义。 如今,面向对象的概念已经传播得很广泛了,而要反对这种贫血领域模型的做法,还需要更多论据。 贫血领域模型的根本问题在于,它引入了领域模型设计的所有成本,却没有带来任何好处。 最主要的成本是将对象映射到数据库中,从而产生了一个O/R(对象关系)映射层。 因此实际工程场景中,是否使用,如何使用还依赖于设计者以及团队充血模型设计的理解和把握,因为现在绝大多数J2EE开发者都受贫血模型影响非常深。

    42930

    架构设计的贫血模型与充血模型

    以前就听别人说过这俩种模型。 它们描述的对象是面向对象设计中的实体,构建领域模型(Domain model)时,贫血模型与充血模型给出了俩种不同的方案: 贫血模型:是指领域对象里只有get和set方法,或者包含少量的其它方法,与之有关的业务逻辑都不放在该类中 充血模型:充血模型与之不同,不仅有get/set方法,还有业务逻辑也在领域模型(Domain model)里面,Business Logic只是简单封装部分业务逻辑以及控制流程。 贫血模型的好处:     每个贫血对象职责单一(体现在哪:每个对象几乎只有属性,get/set方法,无业务逻辑),这样模块间、对象间解耦程度很高。 贫血模型的坏处:     对象状态和行为分离(贫血模型中,对象只有属性,get/set方法,业务逻辑在不在对象类内部),所以一个完整的业务逻辑描述不能在一个类中完成,而是一组相互协作的类共同完成的。

    1.5K20

    DDD 领域驱动设计:贫血模型、充血模型的深入解读!

    - 前言 - 要想深入掌握和了解 DDD 领域驱动设计的核心,那无论如何也绕不开两大较为抽象的概念——“贫血模型”、“充血模型”: 贫血模型即事务脚本模式。 充血模型即领域模型模式。 - 贫血模型 - 贫血模型最早广泛应用源于EJB2,最强盛时期则是由Spring创造,将: “行为”(逻辑、过程); “状态”(数据,对应到语言就是对象成员变量)。 作为领域模型的推广者,他们觉得这不是一件好事。 ? 贫血领域模型的基本特征是:它第一眼看起来还真像这么回事儿。项目中有许多对象,它们的命名都是根据领域来的。 更糟糕的是,很多人认为这些贫血领域对象是真正的对象,从而彻底误解了面向对象设计的涵义。 如今,面向对象的概念已经传播得很广泛了,而要反对这种贫血领域模型的做法,还需要更多论据。 因此实际工程场景中,是否使用,如何使用还依赖于设计者以及团队充血模型设计的理解和把握,因为现在绝大多数J2EE开发者都受贫血模型影响非常深。

    3.9K11

    大白话给你讲清楚之领域模型贫血模型和充血模型

    今天跟大家分享一个知识点即领域模型贫血模型和充血模型。 看完这篇文章你会更深入理解各自的优缺点和适用场景。希望对你平时开发和架构设计有所参考和帮助。 贫血模型 1 什么是贫血模型 贫血模型是一种领域模型,该模型下的领域对象包含很少或没有业务逻辑(对象只包含基本的属性即属性对应的getter/setter方法)。 上面的介绍可能稍微觉得抽象,我觉得要理解贫血模型我们要了解另一个知识点即事务脚本编程模式。 业界也叫贫血模式。 通过领域模型对象的交互,完成业务逻辑的实现。可以这么说设计好了领域对象,也就设计好了业务逻辑实现。 所以业界又把这种模型称为领域模型。 它是真正的遵守面向对象编程思想,体现高内聚,低耦合理念!

    17810

    业务开发常用的基于贫血模型的MVC架构违背OOP吗?

    考虑到你有可能不太了解我刚刚提到的这几个概念,所以,在正式进入实战项目的讲解之前,我先带你搞清楚下面几个问题: 什么是贫血模型?什么是充血模型? 为什么说基于贫血模型的传统开发模式违反 OOP? 现在,我们再来看一下,什么是贫血模型? 实际上,你可能一直都在用贫血模型做开发,只是自己不知道而已。不夸张地讲,据我了解,目前几乎所有的业务后端系统,都是基于贫血模型的。 这种贫血模型将数据与操作分离,破坏了面向对象的封装特性,是一种典型的面向过程的编程风格。 什么是基于充血模型的 DDD 开发模式? 刚刚我们讲了基于贫血模型的传统的开发模式。 为什么基于贫血模型的传统开发模式如此受欢迎? 前面我们讲过,基于贫血模型的传统开发模式,将数据与业务逻辑分离,违反了 OOP的封装特性,实际上是一种面向过程的编程风格。 既然基于贫血模型的开发模式已经成为了一种约定俗成的开发习惯,那什么样的项目应该考虑使用基于充血模型的 DDD 开发模式呢? 刚刚我们讲到,基于贫血模型的传统的开发模式,比较适合业务比较简单的系统开发。

    36941

    DDD(领域驱动设计),你必须知道的贫血模型和充血模型

    背景 最近公司开始推行DDD(领域驱动设计),基于充血模型的面向对象开发模式是DDD的特点之一,而在平时开发中我们都使用的是MVC 架构是基于贫血模型的面向过程开发风格,也许有同学就会问了,贫血模型和充血模型是的什么呢 贫血模型和充血模型 简介 贫血模型: 定义对象的简单的属性值,没有业务逻辑上的方法(个人理解)没有找到官方解释 充血模型 充血模型也就是我们在定义属性的同时也会定义方法,我们的属性是可以通过某些方式直接得到属性值 回归正题还是看充血模型贫血模型 说了这么多DDD思想中的充血模型到底优势在哪里呢?适用于哪些场景呢?而我们都在用贫血模型,但是我们在平时的开发中也没有什么问题呀? 为什么大家都在使用贫血模型? 综上所述: 充血模型的设计要比贫血模型更加有难度 大家一致使用基于贫血模型的面向过程编程已经成为习惯,比较难转换思想 还有就是对代码不负责任的态度。 总结 贫血模型和充血模型的简单解释 以及DDD开发模式和面向过程编程与充血和贫血模型的关系 对比了基于贫血模型的MVC层的面向过程编程范式和基于充血模型的面向对象编程范式的对比 两种模型分别适用于那种场景

    4K21

    实现业务逻辑三种方式:事务脚本、贫血模型、DDD

    在《领域驱动设计》这本书里面,列举了三种可将业务逻辑建模为软件模型的模式,也就是大家常听说的事务脚本、贫血模型、DDD。有好些名字来描述这三种模式。 贫血模型 Anemic Model 贫血模型似乎从摒弃存储过程之后,把存储过程的搬迁到service中,实体对象与表一一对应。也被称为Table Module,表模块。 到此,我们就明白了为什么贫血模型的火热原因。 而且,正因为有这种局限性,当我们想去构建OO充血模型时,这种分裂阻碍了我们。 为系统提供一个统一门面,至于系统内部是用贫血模型,还是贫血模型,对外部来讲是个黑盒,客户端不用关心。 那么再放大点,现在微服务架构是标配,我们只要知道服务在哪儿,提供了什么能力。 经过这几种风格对比,随着AI的兴起,还会再出现新的模型方法,将来OO还是追求的最优解吗? 总结 实现业务架构的三种方式,贫血模型随处可见,而事务脚本与充血模型倒却难得一见。

    21310

    EF Core中避免贫血模型的三种行之有效的方法

    本篇文章将先探讨贫血模型的问题,再去探究在EF Core中使用Code First时如何使用简单的方法来避免贫血模型。 2.什么是贫血模型 在对领域建模后,输出一系列类中仅包含一些简单属性声明而不包含业务逻辑的模型,就属于贫血模型贫血模型是十分常见的。从我的经验来看,EF中超过80%的领域模型都是贫血模型。这并不奇怪。几乎所有的文档和其他博客文章都以最简单的方式展示了EF。他们专注于尽可能快地开始工作,而不是主张最佳实践。 3.改造为更丰富的领域模型(充血模型) 下面我们将讨论三种简单的方式去丰富你的贫血模型。这几种方法都非常简单,仅需要最小的改动。 温馨提示 当您打算从贫血模型转移到更丰富的领域模型时,您将立即体会到将领域级的业务逻辑封装在领域对象中的好处。请注意,尽管如此,尝试并不是件容易的事。

    48940

    设计概念的统一语言

    贫血模型 贫血模型准确地说,应该被称之为“贫血领域模型(Anemic Domain Model)”,因为这个术语其实是在领域模型这个语境中使用的。 当我们在讨论领域模型时,发现更有好事者在贫血模型的基础上衍生出各种与“血”有关的各种模型,统计下来,除了Martin Fowler提出的贫血模型之外,还包括失血模型、充血模型与胀血模型。 我还看到有的人错误的理解或者误用了“贫血模型”的定义,将只有字段和字段的getter/setter方法的类称之为“失血模型”,而将Martin Fowler提出的富领域模型称之为“贫血模型”。 顾名思义,贫血(Anemic)这个词代表着不健康,贫血模型当然就意指不健康的模型。 如果采用这篇文章的定义,Martin Fowler所推崇的富领域模型反倒成了不健康的贫血模型(虽然该文作者未必认为贫血模型不健康),该何其无辜啊!

    46510

    一个Entity Bean要剥离出来至少三个以上的POJO

    一个并没有行业经验积累的软件公司,它开发的软件,基本上完全是需求驱动,而不是领域模型驱动。只有具备了领域模型积累的公司才有资格去谈领域模型驱动软件开发。 但是我们应该看到,Martin批评的贫血的领域模型并不是Hibernate实体类,Martin指的贫血的领域模型实际上是缺乏丰富业务逻辑概念的领域抽象模型,这和Hibernate实体类完全是风牛马不相及的东西 我认为,Martin批评的贫血的领域模型是指只关注了领域模型持久化特征方面,而忽略了领域模型其他特征方面的模型,这样的模型贫血的。 因为这种模型只关注了模型在技术层面的外在表现,也就是说只关注了数据的存取操作,而忽视了模型蕴含的业务核心价值。 举例来说,我们编一个银行软件,如果你只关注了账户的增删改查,这叫做贫血! 由这些POJO的类互相协作来共同完成这个领域模型。如果你仅仅关注Account的增删改查,那就贫血了,而如果你关注了账户的业务规则,并且考虑一组互相协作的类去完成它,就不是贫血的。

    17720

    多研究些架构,少谈些框架(2)-- 微服务和充血模型

    程序员开发生涯是从学习J2EE经典的分层理论开始的(Action、Service、Dao),在这种分层理论中,我们基本没有啥机会使用那些所谓的“行为型”的设计模式,这里的核心原因,就是J2EE经典分层的开发方式是“贫血模型 Martin Fowler在他的《企业应用架构模式》这本书中提出了两种开发方式“事务脚本”和“领域模型”,这两种开发分别对应了“贫血模型”和“充血模型”。 使用这种开发方式,对象只用于在各层之间传输数据用,这里的对象就是“贫血模型”,只有数据字段和Get/Set方法,没有逻辑在对象中。 马丁福勒定义的“贫血模型”是反模式,面对简单的小系统用事务脚本方式开发没问题,业务逻辑复杂了,业务逻辑、各种状态散布在大量的函数中,维护扩展的成本一下子就上来,贫血模型没有实施微服务的基础。 贫血模型完全依靠数据库对并发的支撑,实现可以简化很多,但充血模型就得自己实现了,不管是在内存中通过锁对象,还是使用Redis的远程锁机制,都比贫血模型复杂而且可靠性下降,这是充血模型带来的挑战。

    77850

    一周技术思考笔记(第56期)-微服务的“二次创业”

    在二次创业中,要弄清这个业务能力,还是让我们先从贫血模型和充血模型说起。 充血模型是领域模型模式,实现起来就相对”复杂”些,那么我觉得这种复杂也是相对贫血模型的脚本式编程来说的。 充血模型真的那么”复杂“,贫血模型真的那么”简单“吗? 你仔细回忆一下,贫血模型的代码结构,Service类,Person类,使用它们的Client类,一个也不少,而且这段结构最终的样子就是下面这样。 贫血领域模型的根本问题是,它引入了领域模型设计的所有成本,却没有带来任何好处。 只有当你充分使用了面向对象设计来组织复杂的业务逻辑后,这一成本才能够被抵消。

    10020

    人人都在跟风学微服务,却不知道DDD领域驱动设计?

    的实现案例可以参考下面这篇文章: “【领域驱动设计在互联网业务开发中的实践】 https://tech.meituan.com/2017/12/22/ddd-in-practice.html ” 关于DDD你需要知道的 贫血模型贫血领域对象 贫血领域对象(Anemic Domain Object)是指仅用作数据载体,而没有行为和动作的领域对象。 既然有贫血领域对象,那也就有充血领域对象。 “充血领域对象 实体除了Getter/Setter方法,还有描述实体行为和动作的方法 ” 我们举个例子,这里有一个订单实体Order。 上面实体并没有描述实体行为的方法,所以该实体是贫血模型。 如果我们需要一个专门修改订单为发货的方法,可以这样写 如果用充血模型写是什么样子的呢? 其实按通常思路来说贫血模型没毛病,但是当业务逻辑复杂了,业务逻辑,状态会散落在大量的方法中,原本代码的意图会渐渐不明确。

    12110

    为什么我写不出面向对象的代码

    今天我们简单介绍下在代码中如何运用DDD领域驱动设计模型 说到DDD,人们首先会讨论充血模型贫血模型。 充血模型 “充血领域对象 实体除了Getter/Setter方法,还有描述实体行为和动作的方法 ” 充血模型贫血模型 在充血模型中我们的对象不只有本身的属性,还有相关的行为。 关于DDD领域驱动设计,推荐书籍: “《领域驱动设计:软件核心复杂性应对之道》 《实现领域驱动设计》 ” 为什么我们在使用贫血模型 看了上面的代码,我们可能会疑问:我使用贫血模型开发挺好的啊? 为什么还要使用充血模型?也没看出什么不一样啊? 传统开发模式的贫血模型,将数据与业务彻底隔离。 因此我总结为什么人们更愿意使用贫血模型呢: “ 充血模型相对贫血模型存在一定的设计难度,你需要多花时间思考哪些是对象本身的行为 面向过程的编程思想根深蒂固,很难改变 对代码没有太大负责态度,认为怎么简单怎么来

    9820

    关注

    腾讯云开发者公众号
    10元无门槛代金券
    洞察腾讯核心技术
    剖析业界实践案例
    腾讯云开发者公众号二维码

    相关产品

    • 语音识别

      语音识别

      腾讯云语音识别(ASR) 为开发者提供语音转文字服务的最佳体验。语音识别服务具备识别准确率高、接入便捷、性能稳定等特点。腾讯云语音识别服务开放实时语音识别、一句话识别和录音文件识别三种服务形式,满足不同类型开发者需求……

    相关资讯

    热门标签

    活动推荐

    扫码关注腾讯云开发者

    领取腾讯云代金券