薪资系统设计、SP 或应用层 (C#.Net) 中的业务逻辑、可维护性 - 重新发布

Question

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

我们所针对的组织具有如下层次结构： 公司 -> 集群 -> 业务部门 (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) 中执行此操作有什么优势？

原帖在这里： Design Hints, Payroll System...repost ...但没有一个问题得到正确回答。

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

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

Answer 1

您听说过选举或代表吗？

Answer 2

如果您正在寻找可以评估以字符串表示的公式的 .Net 解决方案，这里有一篇很棒的文章，详细介绍了使用 ANTLR and C# 创建计算引擎。有一个功能齐全的公式解释器可以解析字符串、构建 AST，然后评估表达式。此外，计算引擎是使用访问者模式实现的，因此如果您有想要执行的功能（例如数据库查找），您可以轻松地将自定义合并到您的解决方案中。

Answer 3

我总是尽量避免将业务逻辑放在数据库层。编写、调试和维护更加困难。此外，数据库通常是扩展成本最高的层。如果您最终需要增强系统以支持更多用户，则向系统添加新的网络服务器相对便宜且容易，但添加数据库实例变得昂贵，因为每个数据库都需要许可证和额外支持。

Answer 4

如果您将公式存储为例如 JEP（用于 java），则问题不大。只需将完整的公式保留为字符串：即：“pay=((0.3 * Basic) + 800)，然后将其解析为树。

您可以查看一些 jep 文档以获取信息，并从中获取想法。为您在此处发布的公式实施简单的求解器应该不会有问题。

我的建议：

• 将其保存在数据库中的字符串中
• 为 eval 和 parser 创建一个小型库。
• 将其解析为二叉树。 （比如 '+' 指向 800 也指向 ''）然后 '' 指向 'basic' 和 '0.3'
• 在它之后，您只需要一个简单的递归函数来解决它。

如果这些公式的复杂性不高，您可以在任何您想要的地方执行此操作，因为它不会花费您太多时间来处理它。