这是一个教科书设计模式,还是我发明了一些新东西？

Question

我刚刚设计了一套桌子,我想出了一个我非常满意的建筑!我以前从未在其他任何地方见过它,所以我很想知道我是否只是重新发明轮子(最有可能),或者这是否是真正的创新.

这是问题陈述:我Employees有谁可以与公司签订不同的合同.每个员工可以执行不同的活动,每个活动可能有不同的工资率,有时是完成一项活动的固定金额,有时是小时费率,有时是分层费率.可能还有一个特定的客户特别喜欢该员工,因此当他与该特定客户合作时,他获得更高的费率.如果没有定义费率,他将获得公司违约率.

不要对细节大惊小怪:重点是可以定义很多工资率,每种工资率都相当复杂.而且工资率都有以下共同点:

• 服务类型
• 支付比例类型(枚举:固定金额/小时费率/分层费率)
• 固定金额(如果PayScaleType = FA)
• 每小时费率(如果PayScaleType = HR) - 是的,可以合并到一个字段中,但由于我不会进入这里的原因,我将它们分开
• 等级(1-> n关系,一旦超过等级阈值,所有等级和支付金额)

这些工资率适用于:

• 默认公司费率
• 员工率
• 员工覆盖率(按客户定义)

如果我必须遵循简单的暴力方法,我将不得不为上面3个表中的每一个创建一个PayRate和PayRateTier克隆表,加上它们相应的Linq类,再加上逻辑来计算3个不同位置的速率,不知何故重构以重用计算逻辑.啊.这就像在数据库中使用复制和粘贴一样.

相反,我做了什么？我创建了一个中间表,我打电话给它PayRatePackage,只包含一个ID字段.我只有一个 PayRate表具有强制性FK PayRatePackage,以及一个PayRateTier具有强制FK表的表PayRate.然后,DefaultCompanyPayRate有一个强制性的FK PayRatePackage,EmployeeRate和EmployeeOverrideRate.

这么简单 - 它的确有效!

(请原谅我没有附上图表;如果我已经解决了主要问题,那么我需要付出很多努力.如果很多人想要查看图表,请在评论中说明,我会把东西放在一起.)

现在,我很确定这个简单有效的东西必须在某个地方采用正式的设计模式,我很想知道它是什么.或者我刚刚发明了一些新东西？:)

Answer 1

我很确定这是战略模式

"定义一系列算法,封装每个算法,并使它们可以互换.策略允许算法独立于使用它的客户端."

Answer 2

听起来像关系数据库设计给我.您将特定逻辑分解为特定实体,并将它们键回原始表格...标准规范化...