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

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

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

员工的工资由

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

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

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

客户端

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

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

我们分歧在于将使用这些

规则生成单个税收组成部分(包括税收减免、税收注销、津贴等(的逻辑放在哪里。

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

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

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

可

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

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

原始帖子在这里：设计提示，薪资系统...转贴...但是没有一个问题得到正确的回答。

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

亲切问候阿希什·夏尔马