29 | 定义仓储：使用EF Core实现仓储层-.NET Core开发实战-极客时间

老师，你好，关于仓储这块有个问题，需要指点一下，如果我每个微服务对应一个数据库，这时我的表分散开来，有时会涉及到多个库连表查询的问题，在配置中怎么提现关系，请问老师这块在微服务中应如何处理。 1. 如果跨库联查应该在仓储层怎么定义，这种情况会延时。 2. 如果添加本地冗余表，会形成大量表和同步任务，不好维护。 3. 有没有一个中间件可以做到隔离数据库分库实现细节，在业务外层就相当于一个数据库。如果使用mysql这种情况该如何实现。 4. 如果使用newsql类的数据库，如tidb是不是可以解决掉。

作者回复: 如果是类似汇总报表这样的诉求，则应该通过数据汇聚的方式解决，类似数据仓库如果是常规业务列表查询，则看是否可以通过分别查询，应用层处理合并。如果这种关联查询需求非常多，则说明你微服务拆分有问题，考虑合并服务

2020-03-12

4

3

小嘿呗

能不能基于dapper实现一个dbcontext

作者回复: 你会发现最终实现出来跟EF差不多

2020-03-03

2

2

dao

老师,可以给出一下整个项目的顶层设计图吗?或者更好的是整个架构图.这样有全局观,听起来也更轻松点.谢谢.

作者回复: 后面章节会有

2020-03-07



1

养猪(jnn)小能手

老师您好，我在用ef core操作mysql数据库的时候，在使用linq或lambada表达式的时候，当在循环里面使用的时候，总会提示要先把datareader关闭后才能操作。但是始终没有想出如何将上一个访问链接关闭的方法。希望老师能讲解一下，谢谢

作者回复: 查询后使用ToList方法获取集合

2020-05-21





张文君

老师您好。之前我做得系统都是DB First的方法构建DB跟仓储层的mapping。感觉DDD的设计，code first的方法比较对。但是如果要建立数百张表，code first写类似orderEntityTypeConfiguration的类，很费时间。请问有没有其他方法可以用code first凸显领域，创建表也不用写这么多代码呢？

作者回复: 哪怕你做code first，最终还是要定义模型与数据库的映射关系的，EntityTypeConfiguration写法让你显式定义映射关系，使得设计表达更明确。虽然说约定大于配置，但显式地设计表达比约定更加明确易懂。

2020-05-19

2



SuperSnow

老师好，上面和您够通的那个问题，我当时对skuitem建立了仓储类，因为保存涉及到提交数据和数据库数据的双向对比。用ef并没有什么好的方法，如果采用整体删除相应goods的sku，然后再整体insert，我感觉这种方式太重了。毕竟以产品为聚合根，在修改商品信息时，总得涉及sku的处理。像对于这种特殊场景的话，我个人觉得是否对非聚合根的类也建立仓储类，以增加操作的方便性。在体现上还是ddd的思想体现，并不是传统三层的，毕竟sku在设计上还是属于以goods为聚合根的，还是在一个聚合里，在少部分特殊场景这样落地也应该是合理的吧?

作者回复: 可以先取出goods对象，然后操作它的skuitem，然后保存goods

2020-04-15





SuperSnow

老师，有一个问题想沟通一下。在repository层，我看到声明了IAggregateRoot接口，这就说明只有聚合根才有资格拥有仓储类。但在实际情况中，如果这种约束的话，一个聚合下非聚合根实体的数据操作都要通过聚合根这个实体来进入操作，道理肯定是这么个道理，但是在落地的时候实现起来会比较麻烦。比如一个Goods表和一个GoodsSkuItems表，一对多的关系，在进行更新的时候，涉及到sku数据的添加、删除操作，（更新可不用进行重复更新操作），那此时就需要进行库与前端的数据对比，此时涉及数据库的添加、删除，最后一并事务提交操作。如果只有一个GoodsRepository类，实现起来感觉不是很方便，如果有一个SkuItemRepository类就会很容易了。所以，我在想聚合的划分其实还是站在业务的角度进行把控，在实现上可以酌情调整，只要不跑出DDD思想，实现时不用太教条。毕竟两个实体类如果一个仓储操作方便可以一并化，如果不方便分别搞两个仓储类也未尝不可，毕竟还是在一个聚合范围内。所以，我想IAggregateRoot可以声明在实体类中，在仓储类层面可以不用声明了吧，以上是我的个人理解。

作者回复: 你举例的删除skuitem，用ddd的思维，就是删除某一个good的某个skuitem，要从good这个聚合根找到这个skuitem，然后删除如果你为skuitem创建了仓储，意味着你可以直接删除某一个特定的skuitem，那就说明它拥有全局唯一标识，它等同于聚合根了。从方便的角度看，确实方便了，但是未来在些业务的时候，这个对象可以从两个仓储修改和处理，哪个写法是正确的姿势呢，团队成员大概率可能倾向于方便的那个做法，最终变成了原来的三层架构，一个表一个仓储。另外现在EF这么强大，你的举例，从good聚合根来处理，写法上也不会很复杂吧

2020-03-25





d(ŐдŐ๑)成(๑ŐдŐ)b

老师，实际开发中，如果因为order表过大需要将address拆到另一张表的情况，但是address是值对象不是实体，代码层面要如何适应这种情况？

作者回复: 业务模型可以不变，仅仅修改实体与数据库的映射关系

2020-03-15

4



小喵喵

如果不用EF，还有什么办法实现呢？总觉得ef性能比较差。

作者回复: EF Core 的问题是在复杂查询上生成的SQL会比较复杂，在SQL调优上定位问题略显复杂。如果使用CQRS模式，则数据写入使用EF Core，查询可以考虑使用其它轻量级的ORM，发挥各自的优势。

2020-03-09

2



峰

如果不用ef如何实现值对象映射呢？

作者回复: 实际上EF映射出来也是两种情况，一种是主表上加对应的字段，一种是映射到另外一张表。不用EF的话，要实现领域模型到仓储会非常复杂，难以维护。

2020-03-04

4



收起评论