工资系统设计，SPs或应用层（C#.Net）中的业务逻辑，可维护性-重新发布

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

我们瞄准的组织具有如下层次结构： 公司->集群->业务单元（BU）->部门->员工

员工的工资由各种工资组成。 每个薪资组成部分都有3个相关规则：计算规则（将组成部分计算为另一个组成部分的百分比，或固定数字或固定数字的百分比）、资格规则（员工/部门是否符合组成部分的资格）和限制组成部分的最大值和最小值的约束规则

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

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

客户机将为多个客户机生成工资单，每个客户机托管一个单独的数据库实例。它们可能对每个组成部分有不同的解释，也可能有不同的组成部分

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

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

一些人提倡使用magic SPs，它将获取员工Id并生成当月的工资单。 其他人希望将逻辑拆分为单独的组件，这些组件将获取应用层中员工的相关数据，并在应用层中计算这些组件

我们的优先次序是： 1.快速适应新客户变化的能力 2.长期维修性 3.演出

这里的1和2比3大，因为这将是一项离线活动

可维护性和快速定制性非常重要，我们将为不同的客户部署应用程序。 客户A的薪资组成规则可能为（（0.3*基本）+800） 客户B为（0.2*基本）+（0.1*额外奖金）

SP会在这里造成混乱，因为上面建议的规则将由最终用户指定，并且需要通过web UI进行自定义。 我们必须解析SQL中的公式。它有多困难或容易？ 与使用SPs相比，在应用层（C#.Net）中这样做有什么好处？

原文如下： ……但没有一个问题得到正确回答

现有系统架构的建议和指针将非常有用。 …是的，我们正在系统的其他地方使用LINQ to SQL

亲切问候,，

---

Ashish Sharma

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

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

我的建议是：

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

---

如果这些公式的复杂程度不高，您可以在任何方面都这样做，因为它不会花费您太多的时间来处理它。

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

如果您正在寻找一个.Net解决方案来评估以字符串表示的公式，这里有一篇优秀的文章用于创建计算引擎的详细信息。有一个功能齐全的公式解释器，可以解析字符串，构建AST，然后计算表达式。此外，计算引擎是使用访问者模式实现的，因此，如果您有希望执行的功能，例如数据库查找，则可以轻松地合并cu将问题简化为您的解决方案。

您听说过Relection或delegate吗？

TLDR。您能简化您的问题吗？您可以在.Net中推荐任何关于此的库吗？