设计提示，薪资System...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有什么好处？

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

你好，阿什什·夏尔马

Answer 1

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

Answer 2

也许你想检查一下C#中的敏捷原则、模式和实践，书中的核心例子是设计一个工资系统，敏捷的方式.

Answer 3

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

为什么不把两者的优点结合起来呢？也就是说，将逻辑分解为编写为SPs的独立组件，从主SP调用？

这都是数据处理，为什么涉及“应用层”而不是调用主SP？