工资单系统设计，SPs或应用层业务逻辑(C#.Net)，可维护性- Repost

Question

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

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

员工的薪资由各种薪资组成。每个薪资组件都有与其关联的3条规则:计算规则(计算组件为另一组件的%，或固定数字或固定号码的%)，适用规则(员工/部门是否有资格获得组件)，以及限制组件的最大值和最小值的约束规则。

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

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

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

我们只希望支持Server，薪资生成将是一个脱机活动。

我们对如何将使用这些规则生成单个税收组件(包括减税、减税、免税额等)的逻辑进行了划分。

有些人提倡神奇的SPs，这将获得一个雇员的Id，并生成一个月的工资。其他人希望将逻辑分割成单独的组件，这些组件将获取应用程序层中的员工的依赖数据，并在那里计算这些组件。

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

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

可维护性和快速自定义性非常重要，我们将为不同的客户端部署应用程序。客户A可能有薪金构成细则as (0.3* Basic) +800，客户B可能有(0.2 * Basic) + (0.1 *补偿奖金)

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

最初的帖子是这样的：设计提示，薪资System...repost ...but没有一个问题得到正确的回答。

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

你好，阿什什·夏尔马

Answer 1

我总是尽量避免将业务逻辑放入DB层。编写、调试和维护更加困难。此外，DB通常是最昂贵的一层规模。如果您最终需要增强您的系统以支持更多的用户，那么向系统添加新的new服务器是相对便宜和容易的，但是添加DB实例将变得非常昂贵，因为每个DB都需要一个许可证和额外的支持。

Answer 2

如果像JEP (用于java)那样存储公式，那就没什么问题了。只需将整个公式保持为字符串:即："pay=((0.3 * Basic) + 800)，然后将其解析为树。

您可以看到jep文档中的一些信息，并从中获得一些想法。对于您在这里发布的公式，实现简单的求解程序应该不会有问题。

我的建议：

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

如果这些公式的复杂性不是很大，那么您可以在您想要的任何方面这样做，因为处理它不会花费那么多时间。

Answer 3

如果您正在寻找一个以字符串表示的计算公式的.Net解决方案，那么这里有一篇很好的文章，详细介绍了如何使用抗and和C#来创建计算引擎。有一个功能齐全的公式解释器，它解析字符串，构建AST，然后计算表达式。此外，计算引擎是使用Visitor模式实现的，因此，如果您有希望执行的函数(例如数据库查找)，则可以轻松地将自定义集成到解决方案中。