强大的计费系统设计.我完全走错了方向吗？

Question

我正在使用实体框架在ASP.Net中开发酒店注册/计费应用程序.在为注册人生成账单时,我的客户有很多古怪的标准.客户可以根据他们的年龄,他们访问的具体日期,房间类型(双人床,单人床等)或者房间类型(而不是每晚每张床(非常标准...)计费系统计费.他们参加的会议,或全部四个......

这是我的图表:

作为一个相对年轻的编码员,我觉得我在"规则"表格的某个地方遗漏了一些东西.我正在尝试做的是允许管理员创建任意数量的ConditionalStatements("Age> 5"或"Age <10",其中"Age"是Statement.Value,'>'是Condition.Value,并且'5'是ConditionalStatement.Value)并将它们中的任意数量链接在一起,从而创建"规则".然后,管理员将该规则与各种RateSchedules相关联,然后该应用程序将能够为已注册停留的任何客户生成账单.

我觉得自己走在了正确的轨道上,而且这个解决方案的大部分都能以我需要的各种方式运作,但有些事情似乎并不合适.我有两个与"规则"创作有关的问题.

• 就"规则"设计而言,我做错了什么？每次管理员想要创建一个新规则时,我觉得生成一个新的RuleSet.ID是错误的.这是我应该以编程方式进行的吗？我是否应该完全重新考虑这个规则流程？

• 从实体框架/脚手架的角度来看,向数据库添加新规则的最佳方法是什么？默认的脚手架允许我一次插入一行,但是为了实际创建一个规则,我需要将一个RuleSet.ID与多个ConditionalStatement.ID相关联 - 但我无法想出一种方法来直观地使用EF脚手架..

任何指向正确的方向都非常感谢!谢谢 :)

编辑: 我根据对我的问题的回答进行了重新设计,但是在研究过程中偶然发现了微软的业务规则引擎:http: //msdn.microsoft.com/en-us/library/aa561216.aspx 以及数学表达式评估器: http://ncalc.codeplex.com/ 以防万一其他人在将来发现这个问题,这些链接可以提供帮助.谢谢你所有的帮助!

Answer 1

在数据库中对域进行建模通常是一种不好的做法。数据库应该是一个细节，所有逻辑都应该在代码中。为此，您应该进行设计以找出客户的需求，并在此基础上创建一个域。在这个阶段，坚持它们将非常简单。

例如，想象一个 PricingRule 抽象类和许多不同的实现，如 AgePricingRule、DatePricingRule、RoomTypePricingRule。然后您的 Bill 对象可以获取 PricingRules 并应用它们并获得最终价格。

需要存储的数据量并不复杂，只需对定价规则进行一些配置即可。