管理员将创建促销代码并从预定义规则列表中进行选择。规则是约束,例如:
我可以将这些规则硬编码到代码中,或者我可以(希望)将业务逻辑存储在数据库表中并在运行中编译/执行它。每个业务规则都相对简单,可以通过Web管理员创建新规则。我想我可以编写一些关于创建所述规则的测试,以在一定程度上验证代码逻辑。
将规则逻辑存储在数据库中是一个非常糟糕的主意吗?
我认为硬编码所有这些规则并在每次添加新规则时重新编译都是愚蠢的。
注意:我读到System.CodeDom
会为我实时编译。
答案 0 :(得分:0)
如果你的意思是“将用C#编写的代码作为纯文本存储”在数据库中,然后即时编译,那么是的,这是一个坏主意。在将代码存储为数据的项目中工作了几年之后,我可以从经验中告诉你,这是一个你会后悔的决定。
最重要的原因是,将代码转换为数据意味着您永远不能更改此代码可能耦合到的接口/类。这意味着您最好能够预测并支持您现在可能关注的每个功能,这非常困难。这个自定义代码也可能有问题,速度慢,难以调试。
<强>更新强>
还有其他方法可以解决这个问题。查看此问题的一种方法是在数据库中存储RuleSpecification
个对象,这可能与这些类型的类型和参数列表一样简单。至于在web ui中配置它们,我首先要选择硬编码约束并能够配置参数(例如设置ExpirationDataRule
的数据)。这可能就足够了。
答案 1 :(得分:0)
为什么不在脚本语言中表达规则并在尝试添加促销代码时解释它们?
<强>拟订一项强>
不是存储需要编译的代码(C#或其他),而是在幕后将您的规则表达为javascript(如果您愿意,可以使用其他脚本语言,但javascript无处不在)。然后使用.NET javascript实现(JScript或其中一个可用的打开选项)来评估您的javascript。所以,你的js可能看起来像这样:
promo.timesUsed < 5 && cart.total >= 35.00
像JScript.Net和Java的Rhino这样的Javascript桥通常提供了获取运行时对象并将它们暴露给脚本上下文的能力。因此,在上面的示例中,promo
和cart
将是您公开给脚本上下文的C#对象。您现在唯一需要遵守的是您将向脚本上下文公开的对象。您可以将脚本文本传递给某种类型的eval方法,然后返回布尔值。您可以创建各种规则,并且只受可用数据的限制。