Conception du système de paie, logique métier dans les SP ou couche d'application (C # .Net), maintenabilité - republication

Question

Nous concevons un système de génération de paie pour un client.

L'organisation que nous ciblons a une hiérarchie comme suit: Société - > Cluster - > Business Unit (BU) - > Département - > Employé

Le salaire d'un employé est composé de différentes composantes de salaire. Chaque composante de salaire est associée à 3 règles: une règle de calcul (calculer le composant en tant que% d'un autre composant, ou% d'un nombre fixe ou d'un nombre fixe), une règle d'éligibilité (si un employé / service est éligible pour un composant) et une règle de contrainte qui limite le max et le min d’un composant.

**** Ces règles sont modifiables et peuvent être éditées par un utilisateur final utilisateur **. De plus, ces règles sont héritées du haut vers le bas, mais si elles sont définies à un niveau inférieur, la règle de niveau inférieur est prioritaire. **

Nous disposons d'une base de données contenant des tables d'assistance, de feuilles, de bonus et ces règles sont également censées interagir avec ces tables.

Le client générera une paie pour plusieurs clients, chacun hébergeant une instance de base de données distincte. Ils peuvent avoir chacun une interprétation différente de chaque composant et peuvent avoir des composants différents.

Nous souhaitons uniquement prendre en charge SQL Server et la génération de la paie sera une activité hors ligne.

Nous sommes divisés sur les endroits où placer la logique qui utilise ces règles pour générer les composants fiscaux individuels (qui comprend les déductions fiscales, les déductions fiscales, les provisions, etc.).

Certaines personnes préconisent des SP magiques qui prendront un identifiant d'employé et généreront une masse salariale pour ce mois. D'autres souhaitent que la logique soit scindée en composants distincts qui obtiendront les données dépendantes d'un employé dans la couche application et y calculeront ces composants.

L'ordre de nos priorités est le suivant: 1. La possibilité d'adapter rapidement les modifications aux nouveaux clients 2. Maintenabilité à long terme 3. Performance

1 et 2 dépassent 3 ici par un facteur important puisqu'il s'agira d'une activité hors ligne.

La maintenabilité et la personnalisation rapide sont très importantes, nous déploierons l'application pour différents clients. Le client A peut avoir une règle de composante salariale telle que ((0.3 * de base) + 800) et Client B en tant que (0.2 * Basic) + (0.1 * Bonus de présence)

Les SP vont-ils causer des dégâts ici, car les règles suggérées ci-dessus seront spécifiées par l'utilisateur final et devront être personnalisables via une interface utilisateur Web. Nous devrons analyser les formules à partir de SQL. Est-ce que ce sera difficile ou facile? Quel avantage y-a-t-il à utiliser cela dans la couche application (C # .Net) par rapport à l’utilisation de fournisseurs de services?

Le message original est ici: Conseils de conception, Système de gestion de la paie ... republication ... mais aucune des questions n'a été correctement répondue.

Des suggestions et des pointeurs sur l'architecture des systèmes existants seront très utiles. ... et oui, nous utilisons LINQ to SQL ailleurs dans le système.

Cordialement, Ashish Sharma

Answer 1

J'essaie toujours d'éviter de mettre la logique métier dans la couche de base de données. Il est plus difficile d'écrire, de déboguer et de maintenir. De plus, la base de données est généralement la couche la plus chère à mettre à l’échelle. Si vous devez renforcer votre système pour pouvoir prendre en charge un plus grand nombre d’utilisateurs, il est relativement peu coûteux et facile d’ajouter de nouveaux serveurs Web à un système, mais l’ajout d’instances de base de données coûte cher, car chaque base de données requiert une licence et une assistance supplémentaire.

Answer 2

Si vous stockez les formules comme par exemple dans JEP (pour Java), le problème ne se pose pas vraiment. Il suffit de conserver la formule complète sous forme de chaîne: "pay = ((0.3 * Basic) + 800)", puis de l’analyser dans un arbre.

Vous pouvez consulter une partie de la documentation jep pour plus d’informations et utiliser les idées à partir de là. 2 ne devrait pas être problématique d'implémenter des solutions simples pour les formules que vous avez publiées ici.

Ma suggestion:

• Conservez-le dans une chaîne, dans la base de données
• Créez une petite bibliothèque pour eval et l’analyseur.
• Analysez-le dans un arbre binaire. (comme "+" pointe vers 800 et pointe également sur "") puis le "" pointe sur "basique" et sur "0.3"
• Après cela, vous avez juste besoin d’une simple fonction récursive pour le résoudre.

Si la complexité de ces formules n’est pas très grande, vous pouvez le faire dans n’importe quel côté de votre choix car il ne vous faudra pas beaucoup de temps pour la traiter.

Answer 3

Si vous recherchez une solution .Net pour évaluer une formule représentée par des chaînes de caractères, voici un excellent article qui explique comment utiliser ANTLR et C # pour créer un moteur de calcul. Il existe un interpréteur de formule entièrement fonctionnel qui analyse les chaînes, crée un AST, puis évalue l'expression. De plus, le moteur de calcul est implémenté à l’aide du modèle Visiteur. Par conséquent, si vous souhaitez effectuer des tâches telles que les recherches dans la base de données, vous pouvez facilement intégrer la personnalisation à votre solution.

Answer 4

Avez-vous entendu parler de Reflection ou de délégués?