c# - 设计提示，薪资系统...重新发布

Question

我们正在为客户设计薪资生成系统。

我们的目标组织具有如下层次结构:公司 -> 集群 -> 事业部(BU) -> 部门 -> 员工

员工的薪水由各种薪水部分组成。每个工资组成部分都有 3 个与之关联的规则，一个计算规则(将组成部分计算为另一个组成部分的百分比，或一个固定数字或固定数字的百分比)，一个资格规则(员工/部门是否有资格获得一个组成部分)和限制组件的最大值和最小值的约束规则。

这些规则是可编辑的，并且可以由用户最终用户编辑。此外，这些规则是自上而下继承的，但如果在较低级别定义，则较低级别的规则优先。

我们有一个包含出勤表、休假表、奖金表的数据库，这些规则也应该与这些表交互。

客户端将为多个客户端生成工资单，每个客户端托管一个单独的数据库实例。他们可能对每个组件都有不同的解释，并且可能有不同的组件。

我们只希望支持 SQL Server，工资生成将是一项离线事件。

我们对于将使用这些规则生成各个税收组成部分(包括税收减免、税收冲销、津贴等)的逻辑放在何处存在分歧。

有些人提倡神奇的 SP，它会获取员工 ID 并生成当月的工资单。其他人希望将逻辑拆分为单独的组件，这些组件将在应用层获取员工的相关数据并在那里计算这些组件。

我们的优先顺序是:1. 快速适应新客户变化的能力2.长期可维护性3.性能

这里 1 和 2 比 3 大很多，因为这将是一项线下事件。

可维护性和快速可定制性非常重要，我们将为不同的客户部署应用程序。客户 A 的薪酬构​​成规则可能为 ((0.3 * Basic) + 800)和客户 B 作为 (0.2 * 基本) + (0.1 * 出勤奖金)

SP 会在这里造成困惑吗，因为上面建议的规则将由最终用户指定，并且需要通过 Web UI 进行自定义。我们将不得不从 SQL 中解析公式。它有多难或多容易？与使用 SP 相比，在应用层 (C# .Net) 中执行此操作有什么优势？

对现有系统架构的建议和指示将非常有帮助。...是的，我们在系统的其他地方使用 LINQ to SQL。

亲切的问候，阿希什夏尔马

Answer 1

看完后我唯一的建议是查看 GoF 设计模式书中的策略模式。您可能希望使用脚本语言而不是您的主要编译语言完成这些策略，尽管这样您会发现编辑它们更容易。