使用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) 浏览(23)

解决VS2019+ReSharper载入解决方案后CPU占用过高卡死

作者:V君 发布于:2019-8-15 11:56 Thursday 分类:折腾手记

TL;DR
0)杀掉卡死的VS2019进程
1)删除位于以下目录的解决方案缓存
 %UserProfile%\AppData\Local\JetBrains\Transient\ReSharperPlatformVs??\v???_????????\SolutionCaches
2)删除解决方案下的 .vs 文件夹
+)重新打开解决方案,不再卡死

~扯扯时间~

在用SourceTree从Git仓库拉取更新后,打开vs发现长时间没响应,CPU占用很高。
掏出Procexp看看他在干啥,发是一条线程占用很高
在clr.dll!GetMetaDataInternalInterfaceFromPublic的地方
咕狗得出结论是ReSharper,就尝试清缓存了,果不其然问题解决了,美滋滋

~相关话题~

另外,如果在更新SVN且有冲突,在合并前就打开解决方案也可能导致卡死,
需要先在外部解决冲突合并项目文件,因为错误的项目文件结构会让VS或ReSharper懵逼

这po就当作餐前甜点,晚些再整理这个月的主要内容 乂目

标签: 软件开发 软件故障诊断

评论(2) 引用(0) 浏览(74)

用C#实现用户自定义公式计算

作者:V君 发布于:2019-7-13 13:33 Saturday 分类:挖坑经验

这次主要是讨论各种已知的实现方式,然后扯扯目前的实现,并非着急解决问题。
因此没有TL;DR (pia

如果你着急,可以先看看我目前选择的实现方式,已经托管在公开的GOGS了。

按用户定义的计算公式做各种数据操作,在业务系统中并不罕见。
最近就遇到了这样的需求,新项目,可以比较宽松地选择实现方式。
(我不会说现有老项目也有公式计算,使用基于SQL的实现方式,比较恶心)

说到公式计算其实就是动态行为嘛!
我首先想到的就是将用户输入处理成Linq表达式文本(如关键字、字段名称替换),
然后再喂给动态Linq表达式解析解析器,最后编译成委托去执行。
经过实践发现这种方式存在许多限制,不合适用在太开放的用户自定义公式的场景。
停止进一步尝试,表达式解析引擎不是那么容易魔改的,投入咕狗的怀抱寻找更合实现方法。

咕狗一圈回来一共找到了5种方式,分别是:

  • SQL(和老项目的方式一样,相当恶心)
  • DataTable的Compute方法(同样恶心)
  • JScript:Eval(运行效率?弱类型脚本语言并不好吃)
  • 造(找)轮子(后序式计算或其他自行实现,如ToolGood.Algorithm
  • 代码编译执行(需要考虑资源释放,也就是要创建独立的AppDomain并在用完之后卸载掉)

(用动态Linq方式居然一个人也没有?编译出来的委托还带自动垃圾回收释放内存呢!)

造轮子是不可能造轮子的光是表达式解析就是个课题了,
用别人做好的东西又担心有风险,主要是在PM的要求下别人的东西好不好修改这方面。
那就只剩下凑代码编译来执行了。

扯一扯目前的做法吧,还是分成几个步骤来实现:

  1. 中文标识符映射
  2. 提前浮点类型转换
  3. 编译代码
  4. 调用已编译的代码
  5. 释放资源(TODO)

为了使用户体验更友好,字段名、部分函数名、操作符之类的玩意儿,允许用户以中文代替。
那么第一步就是将这些中文标识符提取出来,替换成可编译的代码标识符。
最初的实现方式是粗暴地按空格分割表达式项,逐个检索字典替换。
后来发现这样做太糟糕,总不能让用户把操作数和运算符都用空格分开吧?
老早就知道动态Linq表达式解析器里面有解析表达式项地实现了,试着扒一扒。
弄出一个专门提取表达式项的玩意儿,除了不支持字符转义和全角符号,其他方面还凑合吧。
连续两个中文标识符肯定是要用户自己以空格分开,现在第一个步骤已经相对完善。

尽管以代码编译的方式解决了动态Linq表达式不支持的持隐式转换,
但C#中的浮点类型们似乎还是有些水火不容。他们是decimal和double、float,
我们需要根据使用场景来决定兼容的转换方向,
比如计算金额的时候,应该提前将double和float转换成decimal;
再比如要计算参数的时候先将decimal转成double,再去计算,以避免编译失败。
(虽然不知道有没有用decimal保存参数的场景,先提前做好准备吧)

编译代码就简单得多了,只要确定委托签名,就凑出只有一个静态方法的类的可编译代码。
将凑好的代码喂给CSharpCodeProvider的CompileAssemblyFromSource,
稍微看看编译结果有没有问题,就能通过反射取得编译后的方法,把它作为委托放到字段里;
如果发现有编译错误,那就将错误信息整合到异常消息丢出去。

调用代码这一步没什么好扯的了,已经将表达式编译成明确的委托,
只需要将参数怼进去,结果就会返回来。如果还不清楚,那就看看我做的PoC界面实现吧!

最后一个步骤就稍稍有些麻烦了,说是要改变整个格局都不为过。
打算集成到具体项目再考虑,并没有包括本文提供的Poc中,现在只能干巴巴地扯一下。
参考上面提到的链接,在.NET域之间穿梭是一个相当麻烦的事情,
他的工作机制决定了能传输的形式——要求可序列化,且域之间的对象是不能直接引用的,
要通过代理对象去操作,其参数似乎也要求可序列化,这样就很大条了。
就算能很好地控制出入参数,在大量计算地时候还是有不小的序列化开销。
我的方案是把操作颗粒度划得更大一些,整个计算操作在域里面进行,包括数据源的获取,
这样就减少了绝大部分跨域操作,甚至还有敦促垃圾回收的作用。
那么问题来了,是将计算结果跨域传回来呢?还是在域里面就包括输出的动作?
这就要视具体情况来确定了…


那么,每月至少刷一次的存在感就扯到这里,我们下个月再见(pia

标签: 软件开发 C# 动态编译

评论(2) 引用(0) 浏览(81)

在树梅派Raspbian上将Gogs安装到Systemd

作者:V君 发布于:2019-6-16 18:52 Sunday 分类:折腾手记

TL:DR
- 从官方网站下载压缩包并解压到 /opt/gogs
- 修改 /opt/gogs/scripts/systemd/gogs.service 配置各种路径
- 将 /opt/gogs/scripts/systemd/gogs.service 复制或创建符号连接到 /etc/systemd/system/
- 执行 sudo systemctl enable gogs
- 执行 sudo systemctl start gogs
- 此时服务已经启动,访问默认端口,进入安装向导

不扯。

标签: 软件开发 个人服务器 源码管理 linux

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

[ALPHA]适用于Notepad++的Markdown插件

作者:V君 发布于:2019-5-12 6:04 Sunday 分类:我的应用

TL;DR

本站下载:[ 本体32位 ][ 本体64位 ]

源代码 ]

效果: 增加一个可拆分、停靠的插件窗口,呈现Markdown,可导出PDF
限制: 支持大部分常见的Markdown语法,数学符号,图表目前还不支持
环境: 已使用Notepad++ v7.6.6在Win10和Win7SP1确认
技巧: 等你来发现。。。

点击查看原图

使用方法:

1)确定Notepad++位数和版本,下载对应本体,解压到插件目录的NppMarkdownRenderer文件夹
2)启动Notepad++点击工具栏中的点击查看原图按钮,或通过插件菜单
NppMarkdownRenderer打开插件窗格

目前待实现的功能:
1) 样式表管理
2) PDF导出选项(如背景启用和边距)

FAQ:
1)Notepad++提示错误,无法加载插件。
 有两个常见的原因会导致插件无法顺利在Notepad++启动时加载。
 - 在Win7可能是缺少.NET,可从官方网站获取最新版。
 - 缺少CRT库,可以从官方网站下载安装或者直接将散装文件(32,64)解压到插件目录
2)插件窗口显示ERROR: Only Markdown(*.md) supported
 - 将当前文件保存成扩展名为.md的文件,然后任意变更或来回切换选项卡即可
3)崩溃、卡死和其他BUG
 - 请把重现步骤反馈到评论中
 - 具备开发能力者请调试源代码

扯扯:
 总算是发布了第一个看起来可以用了的版本,虽然还有许多功能只做了界面还没实现。。。
 其实没有Notepad++也可以运行
MarkdownRenderer.Test.exe来体验一番 乂目

标签: 软件开发 插件 C# Interop HybridApp

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

Powered by emlog 去你妹的备案 sitemap