我们构建类似工作流的应用程序。
用例1：用户可视化地构建一些工作流，然后运行它以查看结果。然后用户修复WF并再次运行，直到他满意为止。
用例2：完成WF后，用户将其安排为每天运行几次（可能多次）
我的朋友说：当用户保存他的WF时，让我们先将其模型保存到DB（这样我们以后可以打开），然后从该模型生成运行时间的c＃代码。
我说：让我们保存到DB。然后我们将构建一个在DB行上运行的通用运行时，并执行模型命令（类似interperter）。
你有什么看法？
答案 0 :(得分：3)
你说db包含循环和条件等流控制元素。 这告诉我你在db中存储的内容至少是一种简单的过程脚本语言。
当发生这种情况时，会有增强的压力使其更像是一种“真正的”语言。 需要像子程序这样的东西，包括参数，变量和表达式。
您可以通过使用实际语言而不是数据库中的一组行来启动此过程，并将其另存为文本文件。
然后“解释”它的一个好方法是实时生成C＃代码，并在运行中编译/运行它。 这实际上可以很快发生。
这样做的原因是：a）无需编写解释器，b）跳过未来的增强功能。
答案 1 :(得分：0)
我认为组合是理想的：
案例＃1：
只要用户没有安排WF使用你的方法（＃1）......
案例＃2：
当用户调度WF然后编译时（可能甚至是异步，只需要为第一次计划的运行做好准备）。
答案 2 :(得分：0)
我的看法是，每次修改它时等待重新编译工作流程都会变得乏味，我宁愿在“真实”运行时获得性能优势;所以我想我同意你的朋友。
这符合当前的.Net开发方法，其中源代码被编译为字节代码。一旦你“思考”你已经完成了源代码，那么你也可以编译它，对吧？此外，在您决定部署之前，您将获得编译时检查的所有好处。
当然JIT最终编译成机器代码 - 但是这个步骤通常不像第一部分那样长（源代码到字节代码）。