实现领域驱动设计 - 使用ABP框架 - 通用准则
在进入细节之前,让我们看看一些总体的 DDD 原则
数据库提供者 / ORM 无关性
领域和应用程序层应该与 ORM / 数据库提供程序 无关。它们应该只依赖于 Repository 接口,而 Repository 接口不使用任何 ORM 特定的对象
下面说明这一原则的主要原因:
- 为了使您的 领域/应用程序 独立于 基础设施,因为基础设施可能在将来更改,或者您可能需要支持第二种数据库类型
- 通过将基础设施细节隐藏在存储库后面,使您的 领域/应用程序 专注于业务代码。
- 使您的自动化测试更容易,因为在这种情况下您可以模拟存储库
根据这一原则,解决方案中的任何项目都没有引用EntityFrameworkCore项目,除了启动应用程序
关于数据库无关性原则的探讨
上述原因1,深深地影响了你的领域对象设计(尤其是实体关系)和应用程序代码。假设您正在使用 EF Core 与关系数据库。如果你想让你的应用在以后切换到 MongoDB ,你就不能使用一些非常有用的 EF Core 特性
例如:
- 你不能假设 Change Tracking,因为 MongoDB 不能这样做。因此,您总是需要显式地更新已更改的实体。
- 您不能对实体中的其他聚合使用 导航属性 (或集合),因为这对于文档数据库是不可能的。更多信息请参见“规则:仅根据Id引用其他聚合”部分
如果你认为这些功能对你很重要,并且你永远不会偏离 EF Core,我们相信这一原则是值得延伸的。我们仍然建议使用 Repository 模式来隐藏基础设施细节。但你可以假设你在设计实体关系和编写应用程序代码时使用的是 EF Core。你甚至可以从你的应用层引用 EF Core 的 NuGet 包 来直接使用异步LINQ扩展方法,比如ToListAsync() (参见 Repositories 文档中的 IQueryable & Async 操作部分来获取更多信息)
表现层技术无关性
表现层技术(UI框架)是真实应用程序中变化最大的部分之一。在设计领域层和应用层时,完全不考虑表现层技术/框架是非常重要的。这一原则相对容易实现,而ABP的启动模板使之更加容易
在某些情况下,您可能需要在应用程序层和表示层中有重复的逻辑。例如,您可能需要在两个层中重复验证和授权检查。UI层中的检查主要是为了用户体验,而应用程序层和领域层中的检查是为了安全性和数据完整性。这是非常正常和必要的
关注状态变化,而不是报告
DDD关注领域对象如何变化和交互;如何创建实体并通过保持数据完整性/有效性和实现业务规则来更改其属性
DDD忽略报告和大规模查询。这并不意味着它们不重要。如果您的应用程序没有花哨的仪表板和报告,谁会使用它呢?然而,报告是另一个主题。您通常希望使用SQL Server的全部功能,甚至使用单独的数据源(如ElasticSearch)来进行报告。您将编写优化的查询、创建索引甚至存储过程(!)。您可以自由地做所有这些事情,只要您不将它们影响到您的业务逻辑
最新文章
- *HDU1907 博弈
- navicat 结合快捷键
- 用Open Live Account写博文的第一篇文章,立个flag
- BurpSuite拦截HTTPS请求
- 【7集iCore3基础视频】7-5 iTool2驱动安装
- bootstrap在jsp中怎么没有效果?
- 18:字符串-char型字符串
- poj 1062 昂贵的聘礼(最短路 dijk+枚举)
- 2D游戏编程4—Windows事件
- linux创建守护进程
- Java JDBC中,MySQL字段类型到JAVA类型的转换
- 浅析 C++里面的宏
- MVAPI第一个版本架构图
- 将firebug安装在chrome浏览器上
- Webdriver API之操作(二)
- DevOps之主机
- ionic2+Angular web端 实现微信分享以及如何跳转回分享出去的页面
- Scheme N皇后
- safari中input、textarea无法输入的问题
- word模板导出的几种方式:第二种:C#通过模板导出Word(文字,表格,图片) 占位符替换