所以我在某种情况下,我希望有一个包含要运行的类的对象数据库。它看起来像是:
id | Description | pricingClass
1 | "static pricing" | staticDeliveryPrice.class
2 | "Dynamic pricing" | dynamicDeliveryPrice.class
这样做的目的是允许我的编码灵活。我的想法是,这将允许多种方式来确定如何计算deliveryMethod的价格。
我担心的问题是,在这种情况下反映不好吗?有没有更好的方法呢?它是否遵循坚实的原则。(我会说是的,但我的一部分不同意)。
答案 0 :(得分:7)
您正在描述基于插件的架构。你真的需要这种灵活性吗?在以下情况下通常是必要的:
否则,它完全矫枉过正。您可以完全控制产品中的内容,因此您可以简单地依靠良好的旧多态来隔离功能的不同实现。
此外,将业务逻辑放入数据库并不是一件好事:你混淆了问题,你创建了强大的耦合(突然重命名类会变得烦人!),当然,它也是如此。很难通过查看代码来解释代码中发生的事情。