小白常识asp.net sql 框架选择 以及高手交流pk实录

EF Core官方文档：​​https://docs.microsoft.com/zh-cn/ef/​​​ FreeSql官方文档：​​http://freesql.net/guide.html​​ SqlSuger官方文档：​​http://www.codeisbug.com/Home/Doc​​

术语DDD

Ken：EF Core是坑多，但是熟悉了，用来开发DDD你就会发现非常适配，根本就不会出现所谓的超复杂的查询，因为那些都是违反DDD领域模型设计的理念，正常下面是不会设计出来这样的模型
读写分离涉及到业务情况，不能全靠ORM自动完成，因为读写分离一般使用的是数据库主从复制，主从复制涉及到数据同步延迟的问题，一般对于关键的操作，都需要从主库查出来然后再更新或者删除主库，不能从库读，然后主库删改
我们读写分离是框架层面实现的，定义了两个仓储IRepository、IQueryRepository，其中IRepository指向的主库，IQueryRepository指向从库，而从库就是可能通过中间代理动态创哈希到不同的数据库milo：
EFCORE针对简单场景业务不复杂的还行
不然弊端就出来了薛定谔的猫：
EF原生的批处理性能确实不咋地
这个问题几年前就有了，ef团队的态度就是，我知道这个问题，但我就是不改
批量插入的功能，还是用的非常多的
扩展跟原生自带，差别还是有的
Ecore include 里面一开始不能做筛选，默认都是带上导航属性的全部数据
Ken:问题EF本来就不是干这个的(批处理)
orm还要写原生sql批处理，本来就不适合应用orm
EF是为DDD而生，不是为了访问数据库，访问数据库有ado.net
批出来本来就是难点，即使不是EF也没把发，
ado.net也就只是还有个BlukCopy的
你都用到批量插入，还有上门状态管理 还有什么状态管理 单次要插入过千条数据是什么业务
而且EF的BlukCopy大把扩展
EF是针对DDD而设计的
不搞DDD用EF就是画蛇添足
所以说你把他当成数据库访问组件你就是不明白他的设计理念
来到现在这家公司，什么都是上云技术， 数据库的读写分离，在云服务那边就是一个 配置，给钱就行
我目前也是这样想的， IRepository 可以实现聚合根接口，聚合根接口里面提供保存的savechanges 操作追梦者
一个数据库访问组件，用这要扩展，用那要扩展，实在不知道哪里香了
efcore 团队那帮人，估计不做应用项目 做一套 erp 回来再去开发 efcore 才有真心得
常见的需求，读写分离，批量插入，分表分裤
efcore 解决的痛点，我觉得没多少人能说明白
哪有万金油，efcore "ddd" 换个行业再用自己熟悉的那套试试
昨天另一个群看到有人后悔为什么当初没选freesql sqlsugar，他现在研究efcore读写分离头疼清茶
ef/efcore表达的是orm思想，这个门槛不低，理解不了很正常
我们用的是聚合根，efcore读写分离不麻烦
ef/efcore的底层是ddd(听得懂自然懂)

ado.net，

，这都头疼，后面的东西多着，估计是太菜
再来个表达式树或者Emit，不得直接跪倒

我们头疼的是业务领域划分
考虑过多聚合根模式，但最终选择在聚合根内部实现读写分离

萌新
我想的比较简单, 先弄两个库,做个主从同步, 然后配置两个数据库的链接, 生成两个上下文对象, 程序员自己决定使用哪个上下文,完事
现在都是用的云数据库, 已经不在过多考虑这方面的事情了, 不行就加钱升配置
我现在不喜欢讨论DDD,因为我觉得落地太困难,成本较大
efcore 底层是 ddd云淡风轻
其实我觉得这种就直接用cqrs配合你这个最好了 读和写分开
关于(我想的比较简单, 先弄两个库,做个主从同步, 然后配置两个数据库的链接, 生成两个上下文对象, 程序员自己决定使用哪个上下文,完事)

薛定谔的猫：我最开始就这么做的，后来看了看 mycat，我感觉的我想法简直就是乞丐版