从 EF6 转到 EF Core 了,变化挺大
作者:V君 发布于:2021-6-27 14:19 Sunday 分类:折腾手记
月底了,还没发表这个月的文章,好方,那依旧水一水正在做的事情吧。
最近在拿起放置了好长时间的 VCommon 摆弄,试图将其迁移到 .NET 5+ 。目前刚完成 EF6 转到 Core 的迁移,前面的基础类库、IoC、AutoMapper 都还算挺顺利,从经典 EF 迁移到 Core 就没这么简单了。让我来水水这次的经历。
连接字符串配置。从经典 FrameWork 转到 Core 之后,config 文件和 ConfigurationManager 似乎不能再继续用,得改用 json 配置文件的方式,而且运行环境(单元测试、命令行工具)的适配也不一样。
审计字段和软删除。这一点上 Core 的 EF 和经典的没有差别,依旧重写 SaveChanges 方法,在里面按接口找出变更实体按需操作就可以了(别忘了调用基类方法)。
查询过滤器。这一点就比较坑了,首先 EF6 的 DynamicFilters 不支持 EF Core,其次 EF Core 自带的全局查询过滤器它不好用,于是只能把实现放在叠在 EF 上方的 Repository 层,反正业务逻辑通常也只使用 Repository,那就在向上层提供 IQueryable 之前先在内部根据过滤器状态做好前置条件(比如软删除之类的)。
目前经典 EF 转 Core 就只遇到过这几个问题。如果遇到更多问题再追加吧(希望不要
使用FluentMigrator和EntityFramework,实现相对可控的多库兼容CodeFirst体验
作者:V君 发布于:2019-8-31 15:49 Saturday 分类:折腾手记
- TL;DR -
1) 在 NuGet 找到并安装 FluentMigrator、EntityFramework、数据库提供程序、Dapper
2) 确认 App.config 配置、增加连接字符串并明确 providerName
3) 应用程序初始化时按需配置环境
4) 配置 MigrationRunner
5) 撰写、调试数据库初始化 Migration
6) 使用 EntityFramework 操作 FluentMigrator 创建的数据库,Enjoy it!
- 扯扯 -
我在之前的文章中提到过,EntityFramework的纯CodeFirst方式并不好吃,因此一直以“基于现有数据库的CodeFirst”方式使用EntityFramework,即先手动创建数据库,再对应数据库结构手打实体模型。这种方式需要将创建数据库的SQL脚本保存下来,以便反复部署。如果要兼容不同数据库还需要为它们分别保存SQL脚本。在数据库有变更时还得反复更新脚本,这太麻烦了。
直到最近折腾的一个 ToyProject 想要分别适配 MySQL 和 SQLite 才重新考虑这个问题,然后做了尝试,尽管总体来说并没有很优雅,也总比EF的纯CodeFirst要靠谱得多。接下来是细节展开,如果光是看TL;DR觉得一脸懵逼,应该能有所缓解。
- 展开 -
1) 实际安装的NuGet包分别是
✸ FluentMigrator.Runner : 这个包之后有一大堆依赖被自动追加,不要被DLL数量吓到唷
✸ Dapper : 在初始化MySQL时需要用到
✸ System.Data.SQLite : 已包含EF提供程序的依赖
✸ MySql.Data.Entity : 不解释
2) 确认 App.config 中的提供程序、配置连接字符串
✸ 安装最后两个包之后,App.config 会在以下两处自动增加提供程序
> configuration/entityFramework/providers
> configuration/system.data/DbProviderFactories
⚠ NuGet包自动加上的提供程序配置可能会有问题,咕狗爆栈可以找到解决方案
✸ 连接字符串 :configuration/connectionStrings/add 用起 providerName 与提供程序对应
3) 应用程序初始化
✸ DataDirectory :针对 SQLite 在当前 AppDomain 上设置配置数据文件路径
4) 配置 MigrationRunner
✸ 创建数据库 : MySQL在连接字符串中指定了数据库名称,但实际不存在的时候会炸
> 实例化 MySqlConnectionStringBuilder 获取并剔除连接字符串中的数据库名称
> 用未指定数据库的连接字符串打开连接,检测到数据库不存在则创建(用Dapper偷懒)
⚠ 对于 SQLite 仅需简单打开数据库连接就能创建数据库文件
✸ 根据连接字符串的 providerName 配置不同数据库提供程序,可以参考文档示例
5) 写 Migration
✸ 一般情况下只需要在 Migration 中无脑 Create 各种需要的表和索引就可以了
> 让我们来看看二般情 : 况针对 MySQL 使用 Execute.Sql 设置字符编码
6) 使用 EntityFramework,到这里就没太多可以扯的东西了
✸ 比起把连接字符串或其名称喂给 DbContext 我更喜欢直接给 DbConnection 实例
- EOF -
这就是本月的主要内容吗?从信息量上来说有点牵强呀…
在MySQL用EF6遇到的那些坑
作者:V君 发布于:2017-6-20 16:12 Tuesday 分类:挖坑经验
把在 MySQL 用 EF 遇到的各种坑记下来,挂起假古文
首次创建迁移(初始迁移)之前应做好预处理:
避免生成的SQL语句有架构名称(dbo), 不这样做将会在今后的更新迁移中掉坑.
不要等你发现之后再加上这句, 要重建数据库才能避免更多问题.
(先记一个,有新的坑再追加, (´∀((☆ミつ)
软件开发辅助工具 - 将EntityFramework实体文档注释搬进数据库(MSSQL)
作者:V君 发布于:2017-1-9 21:22 Monday 分类:我的应用
TL;DR[ 本体 ][ 源代码 ]
效果:生成SQL用于更新表和字段说明.
用法:直接运行,在弹出的打开对话框选择定义实体的程序集. (记得启用XML文档生成)
限制:尚不明确.
环境:需要.NET 4.5.2以上, 作为开发者不需要啰嗦更多.
扯扯:
虽然用上Code-first之后各种便利,然而当需要生成数据库注释用来给运维之类的提供方便时.
咕狗了之后发现并没有现成的工具,懵逼了一会儿. 又查了一下更新数据库注释的方法.
嗯嗯 MSSQL 比 MySQL 做起来方便多了. 于是这个小工具就诞生辣.
首先将打开对话框指定的程序集载入
遍历所有类 -> 筛选出有[TableAttribute]特性定义的类
遍历属性 -> 筛选出可读可写的非导航属性
收集表名,成员名(如果指定了Column特性,将取其指定的列名)
基于上述信息构建数据库更新SQL脚本.
(由于M$SQL新增和更新的分别是两个存储过程, 于是简化处理, 先新增再更新.
((报已存在的错误提示无视掉就可以了 _(:з」∠)_
将SQL输出到窗体控件
做这东西过程中遇到了几个有趣的现象, 尽管不是很高深.
0) 嵌套类全名用加号分隔类名
但是XML文档中仍然是用点分隔类名
1) 基类在不同的程序集
这时候就要按属性信息的定义类(DeclaringType)去找程序集对应的XML来读取注释了
2) 继承来自泛型的成员
在XML中泛型以"MyGenericClass`1"的方式表示,
需要区分泛型然后获取泛型定义(GetGenericTypeDefinition)
再读取全名才能得到XML中的名字格式,
如果直接取全名将会得到类似"MyGenericClass[Int32]"的格式.
解决ASP.NET Boilerplate与EntityFramework反复出现无用更新的现象[Update]
作者:V君 发布于:2016-10-23 15:49 Sunday 分类:挖坑经验
TL;DR
重写SaveChanges和SaveChangesAsync ,
在base实现调用之前增加以下代码,去除对前三个字段的无用更新的操作.
private static readonly HashSet<string> IgnoreCheckUpdateFields = new HashSet<string>
{
nameof(IAudited.CreationTime),
nameof(IAudited.LastModificationTime),
nameof(IAudited.LastModifierUserId),
nameof(Entity.Id),
};
private void BlockNeedLessUpdate()
{
//LEVEL 1: always CreationTime
var allModified = ChangeTracker
.Entries<ICreationAudited>()
.Where(p => p.State == EntityState.Modified);
foreach (var item in allModified)
item.Property(nameof(ICreationAudited.CreationTime))
.IsModified = false;
//LEVEL 2: only LastModificationTime LastModifierUserId
var allModified2 = ChangeTracker
.Entries<IAudited>()
.Where(p => p.State == EntityState.Modified);
foreach (var item in allModified2)
{
var changed = item.CurrentValues.PropertyNames
.Any(p => !IgnoreCheckUpdateFields.Contains(p)
&& false == item.CurrentValues[p]?.Equals(item.OriginalValues[p]));
if (changed) continue;
item.Property(nameof(IAudited.LastModificationTime)).IsModified = false;
item.Property(nameof(IAudited.LastModifierUserId)).IsModified = false;
}
}
听我扯扯:
由于ASP.NET Boilerplate首次启动/登录时很慢, 于是将EF生成的SQL语句打到调试输出.
发现大量的创建时间被更新的现象.
深入调查发现可能是因为 CreationAuditedEntity 在构造时初始化成 Clock.Now
然后EF从数据库读出值再次绑定,
造成 CreationTime 的 setter 被多次调用导致变更追踪机制懵逼.
粗暴地把所有对 CreationTime 的更新操作屏蔽就好了.
不知道是不是错觉, 这么做了之后发现调试启动速度快了70%呀.
ps. 或许 EF 的变更追踪没有 dbml 那么完善,它只监视赋值行为.然而 dbml 还检查了值变化.
Update:
随着继续调试又发现Tenant的LastModificationTime和LastModifierUserId被更新
然而并没更新到别的字段, 明显这样的更新动作是无用的.
进一步调试看起来EF只是简单的比较了两个装了箱的值, 然而在SQL层面又做了值重复过滤
导致这种尴尬现象.
blogger
Google Web Translator
热门日志
随机日志
最新日志
最新评论
- V君
@Quartz:(出现)... - Quartz
怎么不见人了呢... - V君
@Soar:DHCP 协议相... - V君
@Soar:当然是非... - Soar
@V君:谢谢 有空... - Soar
搞一个 1230v3+B85... - V君
@Soar:另外,也可... - V君
@Soar:iscsi服务端... - Soar
难怪这么卡,尤其... - Soar
clone了源码,提示...
分类
存档
- 2024年5月(1)
- 2023年7月(1)
- 2023年5月(1)
- 2022年11月(1)
- 2022年10月(1)
- 2022年9月(1)
- 2022年8月(1)
- 2022年7月(1)
- 2022年6月(1)
- 2022年5月(2)
- 2022年4月(1)
- 2022年3月(1)
- 2022年2月(1)
- 2022年1月(1)
- 2021年12月(1)
- 2021年11月(1)
- 2021年10月(1)
- 2021年9月(1)
- 2021年8月(1)
- 2021年7月(1)
- 2021年6月(1)
- 2021年5月(1)
- 2021年4月(1)
- 2021年3月(1)
- 2021年2月(1)
- 2021年1月(1)
- 2020年12月(1)
- 2020年11月(1)
- 2020年10月(2)
- 2020年9月(1)
- 2020年8月(1)
- 2020年7月(1)
- 2020年6月(1)
- 2020年5月(1)
- 2020年4月(2)
- 2020年3月(3)
- 2020年2月(1)
- 2020年1月(1)
- 2019年12月(1)
- 2019年11月(1)
- 2019年10月(1)
- 2019年9月(1)
- 2019年8月(2)
- 2019年7月(1)
- 2019年6月(1)
- 2019年5月(1)
- 2019年4月(1)
- 2019年3月(1)
- 2019年2月(1)
- 2019年1月(2)
- 2018年12月(2)
- 2018年11月(1)
- 2018年10月(3)
- 2018年9月(4)
- 2018年8月(6)
- 2018年7月(4)
- 2018年6月(1)
- 2018年5月(2)
- 2018年4月(2)
- 2018年3月(3)
- 2018年2月(1)
- 2018年1月(1)
- 2017年12月(1)
- 2017年10月(2)
- 2017年9月(1)
- 2017年8月(2)
- 2017年7月(1)
- 2017年6月(5)
- 2017年5月(2)
- 2017年4月(2)
- 2017年3月(3)
- 2017年2月(2)
- 2017年1月(2)
- 2016年12月(3)
- 2016年11月(2)
- 2016年10月(3)
- 2016年9月(4)
- 2016年8月(2)
- 2016年7月(4)
- 2016年6月(3)
- 2016年5月(1)
- 2016年4月(4)
- 2016年3月(3)
- 2016年2月(1)
- 2016年1月(5)
- 2015年12月(4)
- 2015年11月(5)
- 2015年10月(1)
- 2015年9月(6)
- 2015年8月(4)
- 2015年7月(1)
- 2015年6月(6)
- 2015年5月(3)
- 2015年4月(3)
- 2015年3月(2)
- 2015年2月(1)
- 2015年1月(3)
- 2014年12月(1)
- 2014年11月(1)
- 2014年10月(1)
- 2014年9月(3)
- 2014年8月(1)
- 2014年7月(1)
- 2014年6月(1)
- 2014年5月(3)
- 2014年4月(1)
- 2014年3月(1)
- 2014年2月(2)
- 2014年1月(1)
- 2013年12月(2)
- 2013年11月(2)
- 2013年10月(1)
- 2013年9月(3)
- 2013年8月(14)
- 2013年7月(7)
- 2013年4月(1)
- 2013年3月(4)
- 2013年2月(6)
- 2013年1月(6)
- 2012年12月(8)
- 2012年11月(6)