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

Powered by emlog 去你妹的备案 sitemap