用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# 动态编译

« 解决VS2019+ReSharper载入解决方案后CPU占用过高卡死 | 在树梅派Raspbian上将Gogs安装到Systemd»

引用地址:

评论：

xhe
2019-08-03 23:34
不太了解公式功能的范围, 也不是很懂c#和linq, 查了一下好像是查询工具... 不过本质上这篇博文想做的就是把文本解析成ast(expression tree), 再用ast进行求值(eval), 只不过求值交给了linq. 如果是这样的话, 稍微提一些知道的东西供参考.

从文本解析成ast可以考虑用PEG(parsing expression grammar)的库, 基本上就是正则表达式. 比LL, LR这种传统parser入门简单迅速, 又比纯粹手写的recursive descent parser(gcc)方便. 用PEG比起文中要自己手动提取token要容易多了. 即使是c语言的parser, 看着c的spec应该很快就能抄出来.

唯一麻烦的地方是PEG并不支持左递归, 也就是exp = exp+n | [a-z]这样的语法, 会跳进死循环. 这句语法的意思是exp可能等于 exp紧跟一个n 或者 一个小写字母. PEG从左到右进行匹配, 那么首先匹配 exp+n, 然后exp+n由exp和n组成, 所以会去尝试解析exp, 然后就绕回来了. 不过通过重写语法可以多少避免问题, PEG仍然很实用.

然后接下来就有些分歧了, 有些人选择直接遍历ast进行求值, 比如math.js里那个运算. 还有就是像文中一样, 先编译成什么东西, 再进行计算. 我个人觉得这种需要大概是什么小型嵌入脚本吧, 写的可能也不会太长? 进行编译反而冗余, 直接遍历ast进行求值会快一点, 如果对性能有要求可以缓存部分计算结果. 通常做法是在每个ast节点上实现一个eval方法, 这个节点需要子节点的值就会去调子节点的eval... 以此类推.

不过如果ast比较大的话, 那么直接遍历ast就不值得了(运行时类型, 遍历消耗的资源什么的), 但是把ast编译成什么东西(比如bytecode, 甚至配合JIT)也比较微妙. 交给c#或者linq什么的自己编译, 好的一方面是他们会做中间优化, 还可能避免直接遍历ast的那种消耗, 把性能集中在计算本身上; 坏的一方面是优化本身也需要不少时间. 如果对性能有要求, 还是做profile看看哪个快吧(
回复
V君
2019-08-09 17:03
@xhe：C#的Linq对应不同理解，写出来的代码一样，但不同的上下文中编译出来的代码是不同的。
一种是匿名方法，和普通用法没有差别。
另一种则是表达式树，编译出树状结构表达式结构，通常用来翻译成SQL，也能在运行时编译成可执行的匿名方法来调用。可以直接写lambda，让编译器生成静态的表达式树，也可以通过系统提供的API动态创建一个个表达式节点然后凑到一块儿。为了实现动态行为，我们要动态生成。动态Linq是基于后者再做一层封装，把文本解析成一系列API调用。
回复

发表评论：

Powered by emlog 去你妹的备案 sitemap