首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

模型类中的虚拟属性怎么会违反持久性忽略原则呢?

在模型类中,虚拟属性是指在类中定义但并不映射到数据库表中的属性。虚拟属性通常用于在模型中定义一些计算属性或与其他属性相关的衍生属性。虽然虚拟属性提供了一种方便的方式来扩展模型的功能,但在一些情况下可能违反持久性忽略原则。

持久性忽略原则是指数据库表的结构应该与领域模型保持一致,任何与数据库表无关的属性应该被忽略。这是为了确保数据库的一致性和完整性,以及提高系统的性能和可维护性。

虚拟属性违反持久性忽略原则的主要原因是它们在模型中定义了但并不映射到数据库表中,因此无法被持久化保存到数据库中。这可能导致以下问题:

  1. 数据库表的结构不符合领域模型:虚拟属性的存在会导致数据库表的结构与实际业务需求不一致,可能造成数据冗余或不完整的情况。
  2. 数据库操作的不一致性:由于虚拟属性无法被持久化保存到数据库中,当对模型对象进行数据库操作(例如保存、更新、删除等)时,虚拟属性的值将会丢失或不可用。
  3. 数据库查询的不准确性:当使用查询语句从数据库中检索数据时,虚拟属性的值将无法通过数据库查询直接获得,需要通过模型中的计算逻辑来获取。这可能导致查询结果的不准确性或不完整性。

为避免违反持久性忽略原则,可以考虑以下解决方案:

  1. 将虚拟属性转换为持久化属性:如果虚拟属性具有重要的业务意义,并且需要被持久化保存到数据库中,可以将其转换为真实的数据库列。这样可以保证模型与数据库表的结构一致性,但需要注意维护数据的一致性和完整性。
  2. 在需要使用虚拟属性的场景下进行计算:如果虚拟属性只在某些特定的业务场景下使用,并且不需要被持久化保存,可以在需要的时候通过模型的计算逻辑来获取虚拟属性的值,而不是在模型中定义它。

总结起来,虚拟属性在模型类中可以用于扩展模型的功能,但在设计模型时需要慎重考虑是否违反了持久性忽略原则。如果虚拟属性对业务逻辑重要且需要被持久化保存,可以将其转换为持久化属性;如果虚拟属性只在特定场景下使用且不需要持久化,可以通过模型的计算逻辑来获取其值。

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

DDD理论学习系列(9)-- 领域事件

忽略不相关领域活动,同时明确领域专家要跟踪或希望被通知事情,或与其他模型对象状态更改相关联 针对官方释义,我们可以理出以下几个要点: 领域事件作为领域模型重要部分,是领域建模工具之一。...它本质就是事件,不要将其复杂化。在DDD,领域事件作为通用语言一种,是为了清晰表述领域中产生事件概念,帮助我们深入理解领域模型。 2....客户成功支付了,却发现订单依旧为待付款,这会导致纠纷违反了聚合一大原则:在一个事务,只对一个聚合进行修改。在这个用例,很明显我们在一个事务对订单聚合和库存聚合进行了修改。...持久性(Durability):已被提交事务对数据库修改应该永久保存在数据库。 我们用一张图来理解一下: ? 在事务一致性保证下,上面的图示只会有两个结果: A和B两个操作都成功了。...数据一致性 举个简单例子,假设10个人,每人有100个虚拟币,虚拟币仅能在这10人内流通,不管怎么流通,最终虚拟币总数都是1000个,这就是数据一致性。

1.6K90

Python 工匠:写好面向对象代码原则

点击原文链接查看所有文章 在 上一篇文章 里,我用一个虚拟小项目作为例子,讲解了“SOLID”设计原则前两位成员:S(单一职责原则)与 O(开放-关闭原则)。...光说有点难理解,让我们用代码来看看一个在 Python 违反 Liskov 原则例子。 一个违反 L 原则样例 假设我们在为一个 Web 站点设计用户模型。...子类继承父,然后重写父少量行为,这看上去正是继承典型用法。但不幸是,这段代码违反了“里氏替换原则”。具体是怎么回事?让我们来看看。...让我们最后再总结一下吧: “L:里氏替换原则”认为子类应该可以任意替换父被使用 在使用方增加具体类型判断(isinstance),通常不是最佳解决方案 违反里氏替换原则,通常也会导致违反“开放-...关闭”原则 考虑什么是核心特征,然后为父增加新方法和属性可以帮到你 子类方法应该和父类同名方法返回同一型,或者返回支持更多操作子类型也行 子类方法参数应该和父类同名方法完全一致,或者更为宽松

1K10
  • 【Go实现】实践GoF23种设计模式:SOLID原则

    长方形和正方形例子详细介绍,请参考【Java实现】实践GoF23种设计模式:SOLID原则 “LSP:里氏替换原则”一节 出现违反LSP设计,主要原因还是我们孤立地进行模型设计,没有从客户端程序角度来审视该设计是否正确...我们孤立地认为在数学上成立关系(正方形 IS-A 矩形),在程序也一定成立,而忽略了客户端程序使用方法。 该例子告诉我们:一个模型正确性或有效性,只能通过客户端程序来体现。...这句话貌似是矛盾,模块A需要使用模块B功能,怎么会让模块B反过来依赖模块A?这就是依赖倒置原则(The Dependency Inversion Principle,DIP)所要解答问题。...(2)抽象和细节 在前文“OCP:开闭原则”一节,我们可以知道,抽象就是众多细节共同点,抽象就是不断忽略细节出来。...如果一个具象是稳定,比如JavaString,那么高层模块依赖它也没有问题;相反,如果一个抽象接口是不稳定,经常变化,那么高层模块依赖该接口也是违反DIP,这时候应该思考下接口是否抽象合理。

    42250

    整洁架构、DDD 和 CQRS 简介

    ◆ 外围层 ◆ 持久层 持久层包含 应用层声明持久性接口实现。...它还包含专门持久性模型(数据访问),这些可能是也可能不是数据库表镜像(特别是如果您使用对象关系映射器,又名 ORM),或者可能代表数据库查询投影。...返回 DTO 上属性结构接近于第一范式,因为数据可能会从非规范化数据库查询返回,并且返回 DTO 结构通常会匹配用户屏幕或某些可由用户使用规范模型任何客户。...如果您需要在命令逻辑从数据库检索数据,那么您应该简单地使用 ORM 或其他方法直接查询数据库。请注意,这是一个典型例子,其中必须违反某些原则才能维护其他原则。...系统最内层,核心中心,是Domain层,它是使用DDD原则构建。应用层围绕着领域层,是核心一部分。应用层包含命令/查询内部业务编排逻辑、由外围层实现接口以及用于与外部层通信模型

    4.2K20

    【抽象那些事】缺失抽象

    抽象原则倡导通过精简和概括来简化实体:精简是删除不必要细节,而概括是找出并定义通用重要特征。 这是什么? 这是一个笑脸,那么我们是怎么知道这是一个笑脸?通过抽象。...违反抽象原则导致坏味 我们这篇博客主要讲解分析缺失抽象坏味,对于其它抽象坏味将在后面的博客讲解分析。 缺失抽象 使用一系列数据或编码字符串,而不创建或接口时,将引发这种坏味。...通常,由于缺失抽象,相关数据和行为将会分散在其它抽象,这将会导致两个问题l: 可能会向其它抽象暴露实现细节,违反封装原则 数据和相关行为分散在不同抽象,可能导致实体之间高度耦合,结果是代码脆弱且难以重用...因此,不创建必要抽象也违反了模块化原则。 缺失抽象潜在原因 未做充分设计分析 没有经过充分设计分析,很容易就会忽略创建抽象,而使用基本数据类型来完成任务。...重构建议是将必不可少字段提取到一个新(Rectangle),并且将操作这些字段方法移到这个

    975150

    【抽象那些事】缺失抽象

    抽象原则倡导通过精简和概括来简化实体:精简是删除不必要细节,而概括是找出并定义通用重要特征。 这是什么? 这是一个笑脸,那么我们是怎么知道这是一个笑脸?通过抽象。人脸数以亿计,却各不相同。...违反抽象原则导致坏味 我们这篇博客主要讲解分析缺失抽象坏味,对于其它抽象坏味将在后面的博客讲解分析。 缺失抽象 使用一系列数据或编码字符串,而不创建或接口时,将引发这种坏味。...通常,由于缺失抽象,相关数据和行为将会分散在其它抽象,这将会导致两个问题l: 可能会向其它抽象暴露实现细节,违反封装原则 数据和相关行为分散在不同抽象,可能导致实体之间高度耦合,结果是代码脆弱且难以重用...因此,不创建必要抽象也违反了模块化原则。 缺失抽象潜在原因 未做充分设计分析 没有经过充分设计分析,很容易就会忽略创建抽象,而使用基本数据类型来完成任务。...重构建议是将必不可少字段提取到一个新(Rectangle),并且将操作这些字段方法移到这个

    65730

    设计模式(06)——设计原则(1)

    那么判断依据是什么? 原因就是或模块职责判断是根据业务来定,并没有一个普遍认同规则。...但如果地址信息,只是一个值对象,也就是说其只是一个展示属性,那么放在这里就是合适。 综上所述,可以看到单一职责原则并不是设计出来就一成不变,其需要结合业务发展具体情况来判断。...那么如果按照开闭原则的话,该如何设计?...即A如果需要依赖B,不是通过在 A new 一个 B 出来,而是在外面创建好 B 后,传递给 A。通过这样方式,可以在需求改变,灵活替换传递参数(B 实现 C 接口的话)。...该定义其实在我们平常业务开发,不怎么会用到,因为我们平常就是高层依赖着底层,例如 Controller 依赖 Service,Service 依赖 Repository,该原则重点还是指导框架层面的开发

    16820

    【面试题】2018年最全Java面试通关秘籍第二套!

    注:本文是从众多面试者面试经验整理而来,其中不少是本人出一些题目,网络资源众多,如有雷同,纯属巧合!禁止一切形式碰瓷行为!未经允许禁止一切形式转载和复制,如有违反则追究其法律责任!...Java在什么时候会出现内存泄漏; Java大对象如何进行存储; rt.jar被什么加载器加载,什么时间加载; 自己写被什么加载,什么时间加载; 自己写两个不同是被同一个加载器加载吗...软引用和弱引用使用场景(软引用可以实现缓存,弱引用可以用来在回调函数防止内存泄露); 四、数据库 数据库索引,什么是全文索引,全文索引倒排索引是什么原理; 数据库最佳左前缀原则是什么?...Write机制,什么是Check Point); 什么是redo日志、什么是undo日志; 数据库隔离性是怎样实现;原子性、一致性、持久性又是如何实现; 什么是组合索引,组合索引什么时候会失效...操作系统虚拟地址、逻辑地址、线性地址、物理地址概念及区别; 内存页面置换算法; 内存页面置换算法; 进程调度算法,操作系统是如何调度进程; 父子进程、孤儿进程、僵死进程等概念; fork

    71810

    设计面向DDD微服务

    领域模型层是表达业务地方,在编程上体现为捕获数据和行为(具有逻辑方法)领域实体库 遵循持久性无感知和基础设施无感知原则 领域模型层必须完全忽略数据持久性细节,这些持久性任务应由基础设施层执行,因此...领域模型遵循持久性无感知原则很重要,但也不应忽略持久性问题 理解物理数据模型以及它如何映射到您实体对象模型仍然非常重要,否则你设计将会是空中楼阁。...应用层只协调任务,不能保存或定义任何域状态(域模型),它将业务规则执行委托给领域模型本身(聚合根和领域实体),这将最终更新这些领域实体数据。 总体来看,应用层是为实现前端用例地方。 3....一个示例是使用Entity Framework Core代码实现存储库模式: 该存储库模式使用DBContext将数据持久存储在关系数据库。...根据前面提到持久化无感知和基础设施无感知原则,基础设施层不得“污染”领域模型层。 ? 总结 在DDD,应用层依赖于领域和基础设施层,而基础设施依赖于领域层,但是领域层不依赖于任何层。

    65050

    持久化DDD聚合

    但是,请注意,按照顺序引入简单getter和setter很容易打破模型封装,并违反业务约束。 让我们看看会出什么问题。 2.2....在这段代码,我们手动将 totalCost 属性设置为零,这违反了一条重要业务规则。当然,总成本不应该是零美元! 我们需要一种方法来保护我们业务规则。让我们看看聚合根是如何起作用。 2.3....使用@Embedded注解只是向父表添加平面属性。除此之外,基本属性(例如字符串类型)仍然需要setter方法,这违反了预期值对象设计。...然而,如果我们想要完全兼容JPA,我们必须至少对默认构造函数使用受保护可见性,这意味着同一包其他可以在不指定属性情况下创建值对象。 3.2....注意,BSON文档复杂对象被简单地序列化为一组常规JSON属性。因此,即使是第三方(比如 Joda Money)也可以轻松序列化,而无需简化模型。 4.2.

    1.4K20

    精通Java事务编程(1)-深入理解事务

    事务不是先天存在;它是为简化应用层编程模型而人为创造。通过事务,应用程序可忽略某些潜在错误和复杂并发问题,因为DB会替应用处理好(称之为安全保证,safety guarantees)。...但主要还是靠应用程序定义数据有效/无效状态,DB 主要还是负责存储。 原子性,隔离性和持久性是DB 本身属性,而ACID一致性更多是应用层属性。...但分布式数据库实现事务,并没有什么原理障碍。但是否需要多对象事务?是否可能只用KV数据模型和单对象操作就能满足应用需求? 确有一些场景,单对象插入、更新和删除就够了。...但很多其他场景要求协调写入几个不同对象: 关系数据模型,表某行可能是另一个表外键。类似的,图数据模型,顶点有着到其他顶点多个边。...1.2.3 处理错误和中止 事务一大关键特性,若出错,中止所有操作,之后可安全重试。ACID DB基于此理念:若DB存在违反原子性、隔离性或持久性风险,则完全放弃事务,而非部分放弃。

    96830

    实践GoF23种设计模式:SOLID原则

    出现上面的这种违反LSP设计,主要原因还是我们孤立地进行模型设计,没有从客户端程序角度来审视该设计是否正确。...下面,我们总结一下在继承体系(IS-A)下,要想设计出符合LSP模型所需要遵循一些约束: 基应该设计为一个抽象(不能直接实例化,只能被继承)。...这句话貌似是矛盾,模块A需要使用模块B功能,怎么会让模块B反过来依赖模块A?这就是依赖倒置原则(The Dependency Inversion Principle,DIP)所要解答问题。...(2)抽象和细节 在前文“OCP:开闭原则”一节,我们可以知道,抽象就是众多细节共同点,抽象就是不断忽略细节出来。...如果一个具象是稳定,比如JavaString,那么高层模块依赖它也没有问题;相反,如果一个抽象接口是不稳定,经常变化,那么高层模块依赖该接口也是违反DIP,这时候应该思考下接口是否抽象合理。

    1K40

    译:持久化DDD聚合

    聚合设计 让我们想象一下,如果我们决定向Order所有属性(包括setOrderTotal)添加getter和setter,会发生什么。...在这段代码,我们手动将 totalCost 属性设置为零,这违反了一条重要业务规则。当然,总成本不应该是零美元! 我们需要一种方法来保护我们业务规则。让我们看看聚合根是如何起作用。 2.3....使用@Embedded注解只是向父表添加平面属性。除此之外,基本属性(例如字符串类型)仍然需要setter方法,这违反了预期值对象设计。...然而,如果我们想要完全兼容JPA,我们必须至少对默认构造函数使用受保护可见性,这意味着同一包其他可以在不指定属性情况下创建值对象。 3.2....注意,BSON文档复杂对象被简单地序列化为一组常规JSON属性。因此,即使是第三方(比如 Joda Money)也可以轻松序列化,而无需简化模型。 4.2.

    1.7K30

    里式替换(LSP)跟多态有何区别?哪些代码违背了LSP?

    整体上来讲,这个设计原则是比较简单、容易理解和掌握。今天我主要通过几个反例,带你看看,哪些代码是违反里式替换原则?我们该如何将它们改造成满足里式替换原则?...不过,你可能会有这样疑问,刚刚代码设计不就是简单利用了面向对象多态特性吗?多态和里式替换原则是不是一回事?...从刚刚例子和定义描述来看,里式替换原则跟多态看起来确实有点类似,但实际上它们完全是两回事。为什么这么说? 我们还是通过刚才这个例子来解释一下。...为了更好地理解这句话,我举几个违反里式替换原则例子来解释一下。 1....一般情况下,我们写代码都不怎么会违背它。所以,只要你能看懂我今天讲这些,这个原则就不难掌握,也不难应用。

    45330

    Effective.Java 读书笔记(8)关于equals方法

    ,一般来说是不会违反,如果你违反了这个规定,比如你创建了一个实例并把它加到一个集合,那么这个集合可能没有你刚刚加上去,太可怕了 对称性,第二个条件,即两个对象只要一个方向相等,那么就两个方向相等...,现实还是有可能会出一点错,举个例子,我们来看看下面的这个,实现了一个不区分大小写string,大小写在toString里面保留但是在比较时候忽略了 public final class CaseInsensitiveString...如果你完全没有重写发,直接使用Pointequals方法来实现,那么color信息就会被忽略,在不违反规范前提下,这是不被接受,假定你重写了equals方法,如果参数是其他color point...,原因很简单,我们在做前两次比较时候没有涉及到颜色,故颜色忽略导致传递性违反 那么应该怎么解决这个问题?...,这个替代原则说一个类型任意重要属性,也应该被子类型所持有,故这个类型任意方法都应该平等地作用于子类[Liskov87]。

    40940

    从直观物理学谈到认知科学,Sora不是传统物理模拟器盖棺定论了?

    作者回顾了 Sora 功能、工作原理以及它模拟 3D 场景属性意义,讨论了认知科学中直观物理学文献、机器学习「世界模型多义(多种解释)概念以及图像生成模型可解释性研究。...Sora 还必须学习游戏引擎概念才能满足目标。 物理引擎术语有些令人困惑,尤其考虑到 Sora 可能是在虚拟引擎 5 场景接受训练。...这是这类神经网络生成任意场景一致和逼真视频最有效方法,也可能是唯一方法。 那么,Sora 是否真的从 2D 视频归纳出物理定律?如前所述,这看起来可能就很荒谬。...然而这种观点受到了包括 LeCun、Gary Marcus 等在内多位 AI 大佬反对,这些批评者指出,Sora 生成视频公然违反了物理原理。...例如,在下面示例,人们可以看到明显时空不一致,包括生成视频违反重力、碰撞动力学、坚固性和物体持久性

    11910

    软考高级:系统设计基本原则概念和例题

    一、AI 讲解 系统设计基本原则是确保软件开发过程结构清晰、维护方便、扩展性好。下面是这些原则简要解释及例子: 抽象化:将复杂系统关键信息提炼出来,忽略当前步骤不相关细节。...例如,在设计一个电子商务系统时,可以把用户模块抽象为“用户管理”,关注用户增删改查功能,而不是用户具体属性。 自顶向下,逐步求精:从系统总体功能开始,逐步细化到具体子功能和操作。...在软件开发,一个典型例子是MVC模型,将应用程序分为模型(Model)、视图(View)、控制器(Controller)三个独立部分。...模块独立 题目 6: 如果一个系统更改需要频繁修改多个模块,这违反了哪个设计原则? A. 抽象化 B. 自顶向下,逐步求精 C. 信息隐蔽 D. 模块独立 答案及解析: 答案:C。...如果系统更改需要频繁修改多个模块,说明模块间耦合度高,违反了模块独立原则

    7800

    优雅代码秘密,都藏在这6个设计原则

    开闭原则 开闭原则,即对扩展开放,对修改关闭。 对于扩展和修改,我们怎么去理解它?扩展开放表示,未来业务需求是变化万千,代码应该保持灵活应变能力。修改关闭表示不允许在原来修改,保持稳定性。...比如一个C违反了单一原则,它负责两个职责P1和P2。当职责P1需要修改时,就会改动到C,这就可能导致原本正常P2也受影响。 如何更好理解?...比如你实现一个图书管理系统,一个既有图书增删改查,又有读者增删改查,你就可以认为这个违反了单一原则。因为这个涉及了不同功能职责点,你可以把这个拆分。...这时候大家可以看这个标准,来判断功能职责是否单一: 私有方法过多 你很难给起一个合适名字 代码行数、函数或者属性过多 中大量方法都是集中操作某几个属性 依赖其他过多,或者依赖其他过多...那有得修改代码了,显然这违反了开闭原则。顾客设计时,同具体购物平台绑定了,这违背了依赖倒置原则

    37040

    深入理解LSP:里氏替换原则

    说人话就是 新增功能时候 不会修改旧代码,只会新增 新代码。面向对象软件构造里面甚至提出了更严格软件设计原则:不修改代码。为什么不能修改?...如何使用:在代码中找到经常发生改变文件,可能是违反了单一原则负责了不关心东西,也可能是 违反了开闭原则,没有很好找出程序中共性行为,导致出现很多无用重复代码。...推荐书籍《unix编程艺术》solid之lsp:里氏替换原则在设计继承关系时候应该保证子类可以完全替换父忽略类型做特殊处理。...如果你需要在编写程序时候需要知道他具体类型才能继续编程那么就要注意是否违反了里式替换原则,不能完全替代父。必须要关心类型该怎么设计?...因此为了不给自己留下这种后患,同时也让代码表现力更强,因此模式匹配代码全部换成map去做。代码如何规避违反替换原则

    20810
    领券