3

我刚刚完成了一组桌子的设计，我在其中提出了一个我非常满意的架构！我以前从未在其他任何地方见过它，所以我很想知道我是否只是重新发明了轮子（很可能），或者这是否是真正的创新。

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

不要对细节大惊小怪：重点是可以定义很多工资率，每一个都以相当复杂的方式定义。工资率都有以下共同点：

  • 服务类型
  • 薪酬等级类型（枚举：固定金额/小时费率/分层费率）
  • 固定金额（如果 PayScaleType = FA）
  • 小时费率（如果 PayScaleType = HR）- 是的，可以合并到一个字段中，但由于我不会在这里讨论的原因，我将它们分开
  • 层级（1->n 关系，包含所有层级以及超过层级阈值后要支付的金额）

这些工资率适用于：

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

如果我必须遵循简单的蛮力方法，我将不得不为上述 3 个表中的每一个创建一个PayRate并PayRateTier克隆表，加上它们相应的 Linq 类，加上计算 3 个不同位置的速率的逻辑，以某种方式重构以重用计算逻辑。啊。这就像在数据库上使用复制和粘贴一样。

所以相反，我做了什么？我创建了一个中间表，我称之为PayRatePackage，只包含一个 ID 字段。我只有一个 PayRate带有强制 FK to的表PayRatePackage，以及一个PayRateTier带有强制 FK to的表PayRate。然后，与 和一样，DefaultCompanyPayRate对 具有强制性 FK 。PayRatePackageEmployeeRateEmployeeOverrideRate

如此简单 - 它有效！

（请原谅我没有附上图表；对于我已经解决了主要问题的 SO 问题，这将是一个很大的努力。如果很多人想看图表，请在评论中说出来，我会把一些东西放在一起。）

现在，我很确定这种简单有效的东西一定是在某个地方的正式设计模式中，我很想知道它是什么。还是我只是发明了一些新东西？:)

4

2 回答 2

6

我很确定这是策略模式

“定义一系列算法，封装每个算法，并使它们可互换。策略让算法独立于使用它的客户而变化。”

于 2009-07-15T17:13:07.063 回答
5

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

于 2009-07-15T18:30:13.600 回答