我刚刚设计完一组表格,其中我想出了一个令我非常满意的架构!我以前从未在其他地方见过它,所以我很想知道我是否只是重新发明了轮子(最有可能),或者这是否是真正的创新。
问题陈述如下:我有员工
,他们每个人都可以与公司签署不同的契约(Contract)。每个员工可以执行不同的事件,每个事件可能有不同的工资率,有时是完成一项事件的固定金额,有时是每小时工资,有时是分级工资。也可能有一个特定的客户特别喜欢该员工,因此当他与该特定客户合作时,他会获得更高的利率。如果没有定义费率,他将获得公司默认费率。
不要担心细节:主要的一点是,有很多工资率可以定义,每个工资率的定义方式都相当复杂。而且工资率都有以下共同点:
- 服务类型
- 薪资等级类型(枚举:固定金额/小时费率/分级费率)
- 固定金额(如果 PayScaleType = FA)
- 每小时费率(如果 PayScaleType = HR) - 是的,可以合并到一个字段中,但由于我不会在这里详细介绍的原因,我将它们分开
- 等级(1->n 关系,包含所有等级以及超过等级阈值后需要支付的金额)
这些工资标准适用于:
- 默认公司费率
- 员工率
- 员工覆盖率(按客户定义)
如果我必须遵循简单的强力方法,我将必须为上述 3 个表中的每一个创建一个 PayRate
和 PayRateTier
克隆表,以及它们相应的表Linq 类,加上在 3 个不同位置计算费率的逻辑,以某种方式重构以重用计算逻辑。啊。这就像在数据库上使用复制和粘贴。
那么,我做了什么?我创建了一个中间表,将其称为 PayRatePackage,仅包含 ID 字段。我只有一个 PayRate
表,其中包含 PayRatePackage
的强制 FK,以及一个 PayRateTier
表,其中包含强制 FK 支付率
。然后,DefaultCompanyPayRate
对 PayRatePackage
具有强制 FK,EmployeeRate
和 EmployeeOverrideRate
也是如此。
如此简单 - 而且有效!
(请原谅我没有附上图表;对于一个我已经解决了主要问题的问题来说,这将是一个很大的努力。如果很多人想看图表,请在评论,我会把一些东西放在一起。)
现在,我非常确定这种简单而有效的东西一定存在于某个正式的设计模式中,我很想知道它是什么。或者我只是发明了一些新东西? :)
最佳答案
我很确定这是 Strategy Pattern
“定义一系列算法,封装每个算法,并使它们可以互换。策略使算法能够独立于使用它的客户端而变化。”
关于sql - 这是教科书设计模式,还是我发明了一些新东西?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/1132674/