使用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 -

这就是本月的主要内容吗?从信息量上来说有点牵强呀…

标签: 软件开发 C# 数据库 ORM

评论(0) 引用(0) 浏览(1096)

在MySQL用EF6遇到的那些坑

作者:V君 发布于:2017-6-20 16:12 Tuesday 分类:挖坑经验

把在 MySQL 用 EF 遇到的各种坑记下来,挂起假古文


首次创建迁移(初始迁移)之前应做好预处理:

避免生成的SQL语句有架构名称(dbo), 不这样做将会在今后的更新迁移中掉坑.

不要等你发现之后再加上这句, 要重建数据库才能避免更多问题.

 

(先记一个,有新的坑再追加, (´∀((☆ミつ)

标签: 软件开发 C# 数据库 ORM

评论(0) 引用(0) 浏览(1331)

软件开发辅助工具 - 将EntityFramework实体文档注释搬进数据库(MSSQL)

作者:V君 发布于:2017-1-9 21:22 Monday 分类:我的应用

TL;DR
[ 本体 ][ 源代码 ]

效果:生成SQL用于更新表和字段说明.
用法:直接运行,在弹出的打开对话框选择定义实体的程序集. (记得启用XML文档生成)
限制:尚不明确.
环境:需要.NET 4.5.2以上, 作为开发者不需要啰嗦更多.


 

扯扯:

 

点击查看原图

 

点击查看原图

 

虽然用上Code-first之后各种便利,然而当需要生成数据库注释用来给运维之类的提供方便时.
咕狗了之后发现并没有现成的工具,懵逼了一会儿. 又查了一下更新数据库注释的方法.
嗯嗯 MSSQL 比 MySQL 做起来方便多了. 于是这个小工具就诞生辣.


首先将打开对话框指定的程序集载入

 遍历所有类 -> 筛选出有[TableAttribute]特性定义的类
  遍历属性 -> 筛选出可读可写的非导航属性
 收集表名,成员名(如果指定了Column特性,将取其指定的列名)

 按对应定义抓取XML文档里的注释

 基于上述信息构建数据库更新SQL脚本. 
  (由于M$SQL新增和更新的分别是两个存储过程, 于是简化处理, 先新增再更新. 
   ((报已存在的错误提示无视掉就可以了 _(:з」∠)_

 将SQL输出到窗体控件

由用户自行丢进SSMS执行,结束.


做这东西过程中遇到了几个有趣的现象, 尽管不是很高深.


0) 嵌套类全名用加号分隔类名
 但是XML文档中仍然是用点分隔类名

1) 基类在不同的程序集
 这时候就要按属性信息的定义类(DeclaringType)去找程序集对应的XML来读取注释了

2) 继承来自泛型的成员
 在XML中泛型以"MyGenericClass`1"的方式表示,
 需要区分泛型然后获取泛型定义(GetGenericTypeDefinition)
 再读取全名才能得到XML中的名字格式,
 如果直接取全名将会得到类似"MyGenericClass[Int32]"的格式.



标签: 软件开发 C# 数据库 ORM

评论(0) 引用(0) 浏览(1504)

[不理想]使用EntityFramework6 Code First操作SQLite[Update1]

作者:V君 发布于:2016-9-15 20:22 Thursday 分类:折腾手记

这段时间一直在用EF6CF+MySQL忙得没完没了.终于到了假期,试试SQLite和EFCF看看手感如何吧!


新建项目开始折腾吧,从nuget上获取程序包,System.Data.SQLite 1.0.103

然后就是一坨自动依赖 Core/EF6/Linq, 删除EntityFramework.SqlServer引用

删除App.config,咱用SQLite就是想做个便携本地应用, 当然尽可能的在代码中配置


创建数据库上下文类, 继承DbContext

然后是类似MySqlEfConfiguration一样打一个特性上去, 发现并没有自带.

从爆栈上面找到个看起来靠谱的写法.结合问题和答案加到项目中.

然后就是添加迁移配置来创建数据库了, 就算不能自动变更也要来个初始化迁移来建库.

在程序包管理器控制台选择对应项目, 键入 Enable-Migrations 回车.

经过几次自动发起的生成, 尽管有报错, Migrations 文件夹和配置类出来就可以了.


接着还是像使用MySQL一样配置代码生成器, 在迁移配置类构造中追加配置

SetSqlGenerator , 这时发现生成器也没有自带, 网上还有很多说不支持

不过还是在爆栈找到了生成器的实现. 使用答案中的类实例作为生成器.

刚下下来的代码是编译不能的, 根据Resharper提示更换了命名空间才能用.


在数据库上下文类新增无参构造,给base传递Sqlite连接实例,

第二个参数true表示上下文拥有连接实例,可以自动释放.

走一下新增初始建库迁移吧! 在程序包管理器控制台输入 Add-Migration Init 回车!

用来创建数据库的初始迁移就出来啦! 尽管Up/Down方法体内什么都没有!


有了迁移, 那么生成一下SQL看看, 仍然是包管理器控制台, 键入 Update-Database -Script

又是几次自动发起的生成, 然后一个空的sql文件冒了出来... 哈哈 当然, 咱么还没加表呢!


赶紧加表看看效果吧! 回到数据库上下文类增加公开可读写属性IDbSet<T> T是你的实体类.

删除Migrations里的*******_Init.cs, 删除已有的数据库文件

以后要改变数据库都要删除它们再重新Add-Migration,

并且只能有第一次, 因为目前Sqlite的EntityFramework似乎还不支持自动迁移...

这也就是给文章标题打上[不理想]标签的原因.

这次的迁移Up/Down方法体里面有东西了, 分别是创建和删除表.

生成的sql文件crate table语句也出来了.

理所当然的发现没有迁移历史表 __MigrationHistory 的创建语句.


接下来是直接创建数据库, 包控制台里面输入 Update-Database 去掉后面的 -Script 参数

这时应该会在exe旁边冒出连接字符串中指定的文件名啊? 怎么什么都没有?

用Everything搜索文件名才发现, 原来这货跑到系统目录去生成了, 我去 _(:з」∠)_


于是接着咕狗,然后爆栈解决问题, 通过应用域里面类似环境变量一样的方式指定路径.

终于在指定位置自动创建了数据库, 对于每次结构变更只能重建数据库... 凑合着用吧.


Update1:

不同表名相同字段并且是外键时会创建同名索引导致SQL执行错误

需要在 MigrationSqLiteGenerator 以下方法做修改来解决

 Generate(CreateIndexOperation) 

 Generate(DropIndexOperation)

将索引名称后缀上表名就可以了, 

ltextWriter.Write(opeCriacaoIndex.Name + "_" + RemoveDBO(opeCriacaoIndex.Table));

ltextWriter.Write(opeDropIndex.Name + "_" + RemoveDBO(opeDropIndex.Table));

尽管Drop操作现在也没机会用得到, 先也修改吧, 哪天迁移功能受支持就可以直接用了.


标签: 软件开发 C# 数据库 LINQ ORM

评论(0) 引用(0) 浏览(1513)

重新认识EntityFramework, 比较几个LINQ数据访问/ORM库

作者:V君 发布于:2016-5-27 9:29 Friday 分类:挖坑经验

前些年我曾说过 Entity Framework 就是个坑 

但自从最近试着摆弄 ASP.NET Boilerplate Project 对Entity Framework大有改观.

原来版本6之后的Entity Framework完全可以把dbml dbLinq linq2db sqlite-net远远甩在后头.


dbml - LINQ to SQL 类

◆能从数据库生成设计器代码, 也能先设计再生成数据库

◆完整的复杂查询/投影支持

◇仅限MsSQL


dbLinq - 上者的一个类似克隆一样的实现 GitHub 

◆支持多种数据库

能从数据库生成设计器代码, 不支持自动创建数据库

◇复杂查询/投影不完善

 

linq2db - 近些年发起的开源LINQ数据访问/ORM库, 看起来是上者的重新实现 GitHub 

◆支持多种数据库

◆完整的复杂查询/投影支持

能从实体类生成数据库, 也能从数据库生成实体类(T4)

 

sqlite-net - 轻量级sqlite数据访问实现, 因为轻量所以没太多功能 GitHub

◆单个源码文件加到项目即可使用

跨平台直接调用原生实现, 不依赖ADO.NET

○简单的LINQ支持

◇不支持复杂查询/投影


Entity Framework 6+ - 着看怎么完爆上面这堆

◆上述除了轻量级之外的所有优点

◆多种开始方式: CodeFirst,DbFirst,ModelFirst. (不过 CodeFist 就够了)

,能按你对模型类的变更生成数据库更新脚本

◇目前尚未发现缺点

使用一段时间后总算是找到了些缺点(?),可能是考虑到兼容不同数据库 

 LINQ表达式解析依赖于提供程序实现,

 比如MySQL提供程序实现的表达式解析器的解析和投影就BUG满满,

 具体表现为各种操作符报不支持或者导航属性投影字段混淆.


总之赶紧来用这货吧 ゚∀゚)σ

偷偷更新:其实EF的迁移并不太好使,还是基于现有数据库的CodeFirst跟Dapper混搭好 乂目

标签: 软件开发 C# 数据库 LINQ ORM

评论(0) 引用(0) 浏览(1832)

Powered by emlog 去你妹的备案 sitemap