.NET Core 开发实战
肖伟宇
校宝在线架构师、SkyWalking .NET 探针贡献者、NetCorePal 组件库创建者
20086 人已学习
新⼈⾸单¥59
课程目录
已完结/共 61 讲
第一章:必备知识 (25讲)
时长 06:28
时长 02:13
.NET Core 开发实战
登录|注册
留言
22
收藏
沉浸
阅读
分享
手机端
回顶部
当前播放: 29 | 定义仓储:使用EF Core实现仓储层
00:00 / 00:00
高清
  • 高清
1.0x
  • 2.0x
  • 1.5x
  • 1.25x
  • 1.0x
  • 0.75x
  • 0.5x
网页全屏
全屏
00:00
付费课程,可试看
01 | 课程介绍
02 | 内容综述
03 | .NET Core的现状、未来以及环境搭建
04 | Startup:掌握ASP.NET Core的启动过程
05 | 依赖注入:良好架构的起点
06 | 作用域与对象释放行为:你知道IDisposable对象释放的时机和坑吗?
07 | 用Autofac增强容器能力:引入面向切面编程(AOP)的能力
08 | 配置框架:让服务无缝适应各种环境
09 | 命令行配置提供程序:最简单快捷的配置注入方法
10 | 环境变量配置提供程序:容器环境下配置注入的最佳途径
11 | 文件配置提供程序:自由选择配置的格式
12 | 配置变更监听:配置热更新能力的核心
13 | 配置绑定:使用强类型对象承载配置数据
14 | 自定义配置数据源:低成本实现定制化配置方案
15 | 选项框架:服务组件集成配置的最佳实践
16 | 选项数据热更新:让服务感知配置的变化
17 | 为选项数据添加验证:避免错误配置的应用接收用户流量
18 | 日志框架:聊聊记日志的最佳姿势
19 | 日志作用域:解决不同请求之间的日志干扰
20 | 结构化日志组件Serilog:记录对查询分析友好的日志
21 | 中间件:掌控请求处理过程的关键
22 | 异常处理中间件:区分真异常与逻辑异常
23 | 静态文件中间件:前后端分离开发合并部署骚操作
24 | 文件提供程序:让你可以将文件放在任何地方
25 | 路由与终结点:如何规划好你的Web API
26 | 工程结构概览:定义应用分层及依赖关系
27 | 定义Entity:区分领域模型的内在逻辑和外在行为
28 | 工作单元模式(UnitOfWork):管理好你的事务
29 | 定义仓储:使用EF Core实现仓储层
30 | 领域事件:提升业务内聚,实现模块解耦
31 | APIController:定义API的最佳实践
32 | 集成事件:解决跨微服务的最终一致性
33 | 集成事件:使用RabbitMQ来实现EventBus
34 | MediatR:轻松实现命令查询职责分离模式(CQRS)
35 | MediatR:让领域事件处理更加优雅
36 | HttpClientFactory:管理向外请求的最佳实践
37 | gRPC:内部服务间通讯利器
38 | gRPC:用代码生成工具提高生产效率
39 | Polly:用失败重试机制提升服务可用性
40 | Polly:熔断慢请求避免雪崩效应
41 | 网关与BFF:区分场景与职责
42 | 网关与BFF:使用JWT来实现身份认证与授权
43 | 安全:反跨站请求伪造
44 | 安全:防开放重定向攻击
45 | 安全:防跨站脚本
46 | 安全:跨域请求
47 | 缓存:为不同的场景设计合适的缓存策略
48 | 部署:演示一个部署流程
49 | ConfigMap:实现基本配置方案
50 | 配置:使用分布式配置中心方案版本化管理配置
51 | 健康检查:与Liveness、Readiness、Startup探测集成实现高可用
52 | 健康检查:搭建全量健康检查探针和看板
53 | ForwardedHeaders:确保服务在负载均衡下正常工作
54 | 安全:介绍强制HTTPS的两种方式
55 | 日志:与EFK日志三件套集成
56 | 日志:Exceptionless日志系统
57 | 追踪:集成SkyWalking .NET实现追踪
58 | 监控与告警:Prometheus与AlertManager
59 | 监控与告警:用Granfana实现监控看板
60 | prometheus-net:自定义监控指标利器
61 | 结课测试&结束语
本节摘要
登录 后留言

全部留言(22)

  • 最新
  • 精选
偏偏
老师,你好,关于仓储这块有个问题,需要指点一下,如果我每个微服务对应一个数据库,这时我的表分散开来,有时会涉及到多个库连表查询的问题,在配置中怎么提现关系,请问老师这块在微服务中应如何处理。 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
收起评论