c# - 设计提示，工资系统...重新发布

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) 中执行此操作有什么优势？

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

亲切的问候， Ashish Sharma

Answer 1

看完之后，我唯一的建议是查看 GoF 设计模式书中的策略模式。您可能希望使用脚本语言而不是您的主要编译语言来完成这些策略，但这样您会发现编辑它们更容易。

Answer 2

Depends how much decision points do you have in the algorithm. And how much change do you anticipate.

The all SP approach is likely to give you the best performance if your processing is uniform. This will allow you to take full advantage of the database caches and avoid the network bottleneck. Beware of cursors and queries with join criteria different than equals/not-equal (if you have these, the processing is usually better handled by a general purpose language).

If you go for an application, consider using rule management system to encode the rules outside of the database. This would give you maximum transparency and flexibility. Good free rule engines for Java is Drools (some people also like Jess which is a CLIPS clone). Not sure what are the .Net offerings, but in the worst case you can wrap Drools in a web service and use it from C#.

Answer 3

If payroll generation is an offline activity, then I would do it in sps and run them from scheduled jobs. There is no reason the application should be involved in this at all. If you want them to have the ability to run payroll out of schedule, the application could call the same sp.

Security issues you really need to consider in doing payroll: Do not anywhere use dynamic sql. No users should have direct rights to tables. All rights should be at the sp level (and no dynamic sql inthe sps either or you have to set rights at the table level). This is to limit the abilty of users to commit payroll fraud and is extremely important. Any payroll system that uses any dynamic sql is at risk for company employees to commit fraud by directly accessing the tables and doing things the application won't let them do. This is one reason why I would not accept any answer to your question except to use sps.

Business rules should be enforced at the database level for the same reason. You do not want someone using a query tool to add or change data that doesn't follow your business rules. This is extremely critical in payroll (or any other financial system). Use constraints where possible, triggers if the logic is more complex.

You need to audit all the tables including recording who made the changes to data and when.

Be very careful about which users can change the payroll calculation. Again security is the real issue here. Just because I'm a supervisor doesn't mean I should be able to change any employee's salary. This is easy to get wrong, so be very careful here.

Answer 4

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

为什么不结合两者的优点呢？即，将逻辑拆分为单独的组件，编写为 SP，从主 SP 调用？

这都是数据处理，除了调用主SP，为什么还要涉及“应用层”呢？

Answer 5

也许您想查看C# 中的敏捷原则、模式和实践，书中的核心示例是以敏捷方式设计工资单系统......