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

abp vnext2.0核心组件之DDD组件之实体结构源码解析

接着abp vnext2.0核心组件之模块加载组件源码解析和abp vnext2.0核心组件之.Net Core默认DI组件切换到AutoFac源码解析集合.Net Core3.1,基本环境已经完备,接下去就是构建领域层,vnext整个领域层大致分为聚合根、实体、值对象、事件实体、仓储、服务等等,内容较多,所以我打算分随笔进行介绍.首先介绍领域实体。注:这边所说的实体,是abp团队提供的抽象.如果不了解领域相关的知识,建议阅读<<领域驱动设计:软件核心复杂性应对之道>>需要一定设计模式的功底.如果设计模式不了解,请移步本人的设计模式分类.我也是略懂,所以本文有不当之处,请指正!谢谢!另外提一点,贫血的领域模型和充血的领域模型有本质的区别.有兴趣的可以研究研究,后续有时间我也会补充随笔,大家一起来探讨.

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

如何运用领域驱动设计 - 存储库

在上一篇文章中,我们已经了解过领域驱动设计中一个很核心的对象-聚合。在现实场景中,我们往往需要将聚合持久化到某个地方,或者是从某个地方创建出聚合。此时就会使得领域对象与我们的基础架构产生紧密的耦合,那么我们应该怎么隔绝这一层耦合关系,使它们自身的职责界限更加清晰呢?是的,这就要用到我们今天要讲的内容 - 存储库。在很多地方,我们喜欢叫它为仓储,特别是在现有的AspNetCore应用中,大量的应用都在引入Repository这种东西。那么究竟什么是存储库呢?我们现在的使用方式是正确的吗?它在领域驱动设计中又扮演着怎样的角色呢?本文将从不同的角度来带大家重新认识一下“存储库”这个概念,并且给出相应的代码片段(本教程的代码片段都使用的是C#,后期的实战项目也是基于 DotNet Core 平台)。

03

Entity Framework 系统约定配置

Code First之所以能够让开发人员以一种更加高效、灵活的方式进行数据操作有一个重要的原因在于它的约定配置。现在软件开发越来越复杂,大家都试图将软件设计的越来越灵活,很多内容我们都希望是可配置的,但是过多的配置也会带来很大的工作量,解决这个问题的方法就是约定。对于一些简单的,不太可能经常变化的内容我们以一种约定的方式进行设计。使用过其他ORM框架的朋友可能知道一般ORM都有对应的映射配置文件(一般是一个Xml文件),但是EF并没有。在EF中是以一种约定的方式进行表、列同实体类进行映射的,与此同时为了提高最大的灵活性EF中可以通过Fluent API和Data Annotations两种方式对映射进行灵活配置。

02
领券