展开

关键词

首页关键词贫血模型

贫血模型

相关内容

智能钛弹性模型服务

智能钛弹性模型服务

智能钛弹性模型服务(TI-EMS)是具备虚拟化异构算力和弹性扩缩容能力的在线推理平台,能够帮助客户解决模型部署复杂、资源浪费、手工扩展资源效率低下的问题。
  • 架构设计的贫血模型与充血模型 原

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

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

    云产品限时秒杀

    云服务器1核2G首年50元,还有多款热门云产品满足您的上云需求

  • 您找到你想要的搜索结果了吗?
    是的
    没有找到
  • 贫血领域模型:优点缺点是什么?

    我想知道使用贫血域模型的优点和缺点(请参阅下面的链接)。 Fowler Article
    来自:
    回答:2
  • 智能钛弹性模型服务

    产品概述,产品优势,应用场景,常见问题,词汇表,使用流程,创建模型服务配置,控制台说明,概览,创建模型服务配置,模型运行环境,管理模型服务配置,运行 TensorFlow 镜像模型批处理任务,调用 TensorRT镜像模型服务,简介,API 概览,请求结构,公共参数,签名方法 v3,签名方法,返回结果,更新历史,描述服务配置,描述服务运行环境,删除服务配置,创建服务配置,更新服务,描述服务,删除服务,创建服务,日志分析,联系我们,API 文档,产品简介,产品概述,产品优势,应用场景,常见问题,词汇表,快速入门,使用流程,创建模型服务配置,操作指南,模型服务,控制台说明,概览,创建模型服务配置,模型运行环境,管理模型服务配置,最佳实践,运行 TensorFlow 镜像模型批处理任务,调用 TensorRT 镜像模型服务,简介,API 概览,调用方式,请求结构,公共参数,签名方法 v3,签名方法,返回结果,更新历史,配置管理相关接口,模型仓库,模型优化,更新资源组的伸缩组,启用资源组的伸缩组,停用资源组的伸缩组,查询资源组的伸缩组信息,查询伸缩组活动,获取资源组列表,删除资源组的伸缩组,删除资源组,删除节点,创建资源组的伸缩组,监控与告警
    来自:
  • 多研究些架构,少谈些框架(2)-- 微服务和充血模型

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

    来自:
    浏览:129
  • DDD 领域驱动设计:贫血模型、充血模型的深入解读!

    来自:
    浏览:394
  • 如果被迫使用贫血域模型,那么将业务逻辑和计算字段放在哪里?

    我们目前的O RM工具并不能真正支持丰富的领域模型,所以我们被迫在各地都使用贫血(DTO)实体。这一直运行良好,但我仍然努力在哪里把基本的基于对象的业务逻辑和计算字段。
    来自:
    回答:2
  • 函数范式与领域模型

    遵循函数范式建立领域模型时,代数数据类型与纯函数是主要的建模元素。代数数据类型中的和类型与积类型可以表达领域概念,纯函数则用于表达领域行为。通过前面给出的案例,我们发现函数范式的领域模型颠覆了面向对象思想中“贫血模型是坏的”这一观点。事实上,函数范式的贫血模型不同于结构范式和对象范式的贫血模型。函数范式虽然建立的是贫血模型,但它的模块化、抽象化与可组合特征降低了变化带来的影响。Debasish Ghosh总结了函数范式的基本原则,用以建立更好的领域模型:利用函数组合的力量,用小函数组装成一个大函数,获得更好的组合性。 纯粹,领域模型的很多部分都由引用透明的表达式组成。与事件驱动架构不同,事件模型驱动设计可以算是领域驱动设计的一种分支。
    来自:
    浏览:383
  • 设计概念的统一语言

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

    来自:
    浏览:1203
  • 单一责任原则与贫困领域模型反模式问题如何解决?

    然而,我们有一个Anemic的领域模型 - 在我们的任何模型类中都没有任何行为,它们只是属性包。如果是这样,那么感觉最终的结果就是一个贫血区域模型,这在我们的项目当然是这种情况。然而,贫血域模型是一种反模式。 这两个想法可以共存吗?几个上下文相关的链接: SRP - http:www.objectmentor.comresourcesarticlessrp.pdfAnemic领域模型 - http:martinfowler.comblikiAnemicDomainModel.html
    来自:
    回答:2
  • 业务开发常用的基于贫血模型的MVC架构违背OOP吗?

    来自:
    浏览:139
  • 智能钛工业 AI 平台

    本平台提供了包含数据工厂、内置通用/行业算法库、模型迭代训练引擎、基于题库测试的模型评估引擎、多版本模型对比分析、模型微服务管理和部署、硬件资源优化调度与管理等全栈 AI 能力。
    来自:
  • 领域驱动模型(DDD)

    而领域驱动设计的核心就在于建立正确的领域驱动模型。?image.png传统软件开发与贫血模型传统的开发思想传统开发四层架构?); 查询活动 queryWmActPoiByWmPoiId(); 根据门店查询活动 ....}可以看到,业务逻辑都是写在Service中的,WmActPoi充其量只是个数据载体,没有任何行为,是一种贫血模型简单的业务系统采用这种贫血模型和过程化设计是没有问题的,但在业务逻辑复杂了,业务逻辑、状态会散落到在大量方法中,原本的代码意图会渐渐不明确,我们将这种情况称为由贫血症引起的失忆症。?贫血模型c. 业务逻辑散落在大量的方法中d.在这些边界中严格保持模型的一致性,而不要受到边界之外问题的混淆。每个团队负责自己的模型,并为其他模型提供服务。上下文映射(Context Map)一个企业应用有多个模型,每个模型有自己的界定的上下文。
    来自:
    浏览:1221
  • 由参加领域驱动大会与自己所想的

    在DDD中常见二种设计模型,分别是贫血模型和充血模型。贫血模型 贫血模型是指领域对象里只有get和set方法,仅包含状态(属性),不包含行为(方法),采用这种设计时,需要分离出DB层,专门用于数据库操作。?但是这种模型整体架构清晰,自上而下单向连接。远程访问接口 -> Facade接口 -> Service服务 -> 领域层 -> DAO -> 数据库 充血模型 充血模型是贫血模型的相对定义,在这个模型中领域层的作用较大,不再是get和set方法的集合,不像贫血模型那样所有业务都集中在biz层或者service层中造成非常沉重难以拆分,但充血模型比较难以设计,需要有一定经验的设计师前期规划好,后期工作才能事半功倍,不然则会造成项目混乱。
    来自:
    浏览:188
  • 从今天起让我们忘记Java中的getset方法吧!

    首先,我们先聊一下最近一个比较火的领域驱动设计中的贫血、失血、胀血和充血模型。什么是贫血失血充血模型呢?简单来说:1、失血模型:模型仅仅包含类的属性和gettersetter方法,业务逻辑和应用逻辑都放到服务层中。这种类在Java中叫POJO或者Bean。2、贫血模型:贫血模型中包含了一些业务逻辑,但不包含依赖持久层的业务逻辑。这部分依赖于持久层的业务逻辑将会放到服务层中。可以看出,贫血模型中的领域对象是不依赖于持久层的。3、充血模型:充血模型中包含了所有的业务逻辑,包括依赖于持久层的业务逻辑。所以,使用充血模型的领域层是依赖于持久层,简单表示就是 UI层->服务层->领域层持久层。4、胀血模型:胀血模型就是把和业务逻辑不相关的其他应用逻辑(如授权、事务等)都放到领域模型中,这是一种极差的设计方式。看到这里,可能大家一脸迷茫!
    来自:
    浏览:166
  • 从今天起让我们忘记Java中的getset方法吧!

    首先,我们先聊一下最近一个比较火的领域驱动设计中的贫血、失血、胀血和充血模型。什么是贫血失血充血模型呢?简单来说:1、失血模型:模型仅仅包含类的属性和gettersetter方法,业务逻辑和应用逻辑都放到服务层中。这种类在Java中叫POJO或者Bean。2、贫血模型:贫血模型中包含了一些业务逻辑,但不包含依赖持久层的业务逻辑。这部分依赖于持久层的业务逻辑将会放到服务层中。可以看出,贫血模型中的领域对象是不依赖于持久层的。3、充血模型:充血模型中包含了所有的业务逻辑,包括依赖于持久层的业务逻辑。所以,使用充血模型的领域层是依赖于持久层,简单表示就是 UI层->服务层->领域层持久层。4、胀血模型:胀血模型就是把和业务逻辑不相关的其他应用逻辑(如授权、事务等)都放到领域模型中,这是一种极差的设计方式。看到这里,可能大家一脸迷茫!
    来自:
    浏览:1906
  • 一起玩转微服务(5)——分层架构

    领域模型又可以分为失血、贫血和充血3种。失血模型:基于数据库的领域设计方式就是典型的失血模型,只关注数据的增删改查。贫血模型:就是在domain object包含了不依赖于持久化的领域逻辑,而那些依赖持久化的领域逻辑被分离到server层。充血模型:充血模型跟贫血模型差不多,不同的是如何划分业务逻辑,就是说,约大部分业务应该放到domain object里面,而service应该是很薄的一层。这些可以说都是随着技术的不断发展,为了应对不同场景所演化出来的模型。而微服务的每个架构都可以再细分成领域模型,下面看一下经典的领域模型架构。值得注意的是,不要把Entity的属性和行为分离到Domain和Service两层中去实现,即所谓的贫血模型,事实证明这样的实现方式会造成很大的维护问题。
    来自:
    浏览:252

扫码关注云+社区

领取腾讯云代金券