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