设计提示，工资系统...重新发布答案

【问题标题】：Design Hints, Payroll System...repost设计提示，工资系统...重新发布
【发布时间】：2010-09-17 13:06:54
【问题描述】：

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

我们所针对的组织具有如下层次结构：公司 -> 集群 -> 业务部门 (BU) -> 部门 -> 员工

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

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

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

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

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

我们对于将使用这些规则生成各个税收组成部分（包括税收减免、税收核销、免税额等）的逻辑放在哪里存在分歧。

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

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

这里的 1 和 2 比 3 重要得多，因为这将是一个离线活动。

可维护性和快速可定制性非常重要，我们将为不同的客户部署应用程序。客户 A 的薪资构成规则可能为 ((0.3 * Basic) + 800) 客户 B 为 (0.2 * Basic) + (0.1 * Atendance Bonus)

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

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

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

【问题讨论】：

标签： c# database oop n-tier-architecture

【解决方案1】：

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

【讨论】：

【解决方案2】：

也许你想检查一下Agile Principles, Patterns, and Practices in C# 书中的核心示例是以敏捷的方式设计工资系统......

【讨论】：

【解决方案3】：

有些人提倡魔法SP 这将需要一个员工 ID 和生成该月的工资单。其他人希望将逻辑拆分为单独的组件将获得员工的相关数据应用层并计算这些那里的组件。

为什么不将两者的优点结合起来呢？即将逻辑拆分成单独的组件，写成 SP，从主 SP 调用？

这都是数据处理，除了调用主SP，为什么还要涉及“应用层”呢？

【讨论】：

【解决方案4】：

如果工资单生成是离线活动，那么我会在 sps 中进行，并从计划的作业中运行它们。应用程序根本没有理由参与其中。如果您希望他们能够超期运行工资单，应用程序可以调用相同的 sp。

在进行工资核算时确实需要考虑的安全问题：不要在任何地方使用动态 sql。任何用户都不应拥有对表的直接权限。所有权限都应该在 sp 级别（并且在 sps 中也没有动态 sql，或者您必须在表级别设置权限）。这是为了限制用户进行工资欺诈的能力，并且非常重要。任何使用任何动态 sql 的工资单系统都存在公司员工通过直接访问表和做应用程序不允许他们做的事情来进行欺诈的风险。这就是为什么除了使用 sps 之外我不接受您的问题的任何答案的原因之一。

出于同样的原因，应在数据库级别强制执行业务规则。您不希望有人使用查询工具添加或更改不符合您的业务规则的数据。这在工资单（或任何其他金融系统）中极为关键。尽可能使用约束，如果逻辑更复杂则触发。

您需要审核所有表，包括记录谁对数据进行了更改以及何时更改。

请注意哪些用户可以更改工资计算。再次，安全是这里的真正问题。仅仅因为我是主管并不意味着我应该能够改变任何员工的薪水。这很容易出错，所以在这里要非常小心。

【讨论】：

可维护性是我们主要关心的问题，因为我们将为许多客户进行部署，每个客户都指定不同的规则。我们不想每次都重写我们的 SP。亲切的问候， Ashish S
相信我，工资单存在法律问题，安全性是所有工资单系统的首要问题，数据准确性是第二个问题，可维护性是第三个问题。没有一家头脑正常的公司会允许他们的工资单由不关心安全性的程序来完成。
可以控制访问（可能使用其他帐户）。 ...到目前为止，针对不同客户的部署和可定制性工作似乎是一个问题。此外，公式将由管理员通过 web-ui 输入并且必须在 SQL 中解析这一事实让我们陷入困境。
此外，Test DrivenDev、Interface Driven Dev 和单元测试框架不适用于存储过程，这让我们产生了两种想法。这些传统上会将我们的测试和开发工作减少一半:(是否有任何框架可以为 SP 做到这一点

【解决方案5】：

取决于您在算法中有多少决策点。您预计会有多少变化。

如果您的处理是统一的，那么全 SP 方法可能会为您提供最佳性能。这将使您能够充分利用数据库缓存并避免网络瓶颈。小心使用不同于等于/不等于的连接条件的游标和查询（如果您有这些，则处理通常由通用语言更好地处理）。

如果您选择应用程序，请考虑使用规则管理系统在数据库之外对规则进行编码。这将为您提供最大的透明度和灵活性。好的免费 Java 规则引擎是 Drools（有些人也喜欢 Jess，它是一个 CLIPS 克隆）。不确定 .Net 产品是什么，但在最坏的情况下，您可以将 Drools 包装在 Web 服务中并从 C# 中使用它。

【讨论】：