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

Question

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

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

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

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

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

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

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

对于使用这些规则生成各个税收组成部分（包括税收减免、税收冲销、津贴等）的逻辑的放置位置，我们存在分歧。

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

我们的优先顺序是：1.适应新客户的更改的能力2。长期可维护性3。表现

这里 1 和 2 比 3 重要很多，因为这将是一项线下活动。

可维护性和快速可定制性非常重要，我们将为不同的客户部署应用程序。客户a可能具有（（0.3 *基本） + 800）和客户b为（0.2 * basic） +（0.1 * Atendance Bonus）

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

原帖在这里：设计提示、薪资系统...转发...但没有一个问题得到正确回答。

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

亲切的问候，Ashish Sharma

Answer 1

我总是试图回避将业务逻辑放在数据库层中。编写，调试和维护起来比较困难。此外，DB通常是最昂贵的规模层。如果您最终需要增强系统以支持更多用户，那么向系统添加新的Web服务器相对便宜且容易，但添加数据库实例会变得昂贵，因为每个数据库都需要许可证和额外支持。

Answer 2

如果您将公式存储为 JEP（用于 java），那么这就不是什么大问题。只需将完整的公式保留为字符串即可：IE："pay=((0.3 * Basic) + 800) 然后解析成一棵树。

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

我的建议：

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

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

Answer 3

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

Answer 4

你听说过反思或代表吗？