Est-ce un modèle de conception de manuel, ou ai-je inventé quelque chose de nouveau?

Question

Je suis tout juste sorti de la conception d'un ensemble de tables, dans lequel j'ai trouvé une architecture qui m'a beaucoup plu! Je ne l'ai jamais vu nulle part ailleurs, donc j'aimerais savoir si je viens de réinventer la roue (le plus probable), ou si c'est une véritable innovation.

Voici l'énoncé du problème: J'ai Employees qui peut chacun signer un contrat différent avec l'entreprise. Chaque employé peut effectuer différentes activités, et chaque activité peut avoir un taux de rémunération différent, parfois un montant fixe pour l'achèvement d'une activité, parfois un taux horaire, et parfois à un taux progressif. Il peut également y avoir un client spécifique qui aime particulièrement l'employé, alors quand il travaille avec ce client spécifique, il obtient un taux plus élevé. Et si aucun taux n'est défini, il obtient le taux de défaut de l'entreprise. Ne vous en faites pas sur les détails: le principal est qu'il y a beaucoup de taux de rémunération qui peuvent être définis, chacun d'une manière assez compliquée. Et les taux de rémunération ont tous ceci en commun:

• service Type
• type échelle salariale (Enum: Montant fixe/Taux horaire/hiérarchisé Rate)
• montant fixe (si PayScaleType = FA)
• Taux horaire (si PayScaleType = HR) - oui, pourrait être fusionné en un seul champ, mais pour des raisons que je ne vais pas entrer ici, je les ai séparés
• Tiers (relation 1-> n, avec tous les niveaux et le montant à payer une fois que vous avez dépassé le seuil du niveau)

Ces taux de rémunération applicable:

• société par défaut taux
• taux d'employés
• taux de dérogation aux employés (défini par client)

Si je devais suivre simple force brute approche, je devrais créer une table clone PayRate et PayRateTier pour chacun des 3 tableaux ci-dessus, plus leurs classes Linq correspondantes, plus la logique pour calculer les taux dans 3 sépara des lieux, refactoring en quelque sorte pour réutiliser la logique de calcul. Pouah. C'est comme utiliser copier et coller, juste sur la base de données.

Alors, à la place, qu'est-ce que j'ai fait? J'ai créé une table intermédiaire, que j'ai appelée PayRatePackage, consistant seulement en un champ ID. Je n'ai que une tablePayRate avec un FK obligatoire à PayRatePackage, et un tableau PayRateTier avec un FK obligatoire à PayRate. Ensuite, DefaultCompanyPayRate a un FK obligatoire à PayRatePackage, comme le font EmployeeRate et EmployeeOverrideRate.

Si simple - et ça marche! Excusez-moi de ne pas avoir joint de diagrammes, ce serait beaucoup d'efforts à faire pour une question de SO où j'ai déjà résolu le problème principal, si beaucoup de gens veulent voir un diagramme, s'il vous plaît dites-le Dans les commentaires, et je jette quelque chose ensemble.)

Maintenant, je suis sûr que quelque chose de si simple et efficace doit être dans un modèle de conception formelle quelque part, et j'aimerais savoir ce que c'est. Ou est-ce que je viens d'inventer quelque chose de nouveau?:)

Answer 1

Je suis sûr que c'est le Strategy Pattern

« Définir une famille d'algorithmes, chacun encapsuler, et les rendre interchangeables. Stratégie permet à l'algorithme varient indépendamment des clients qui l'utilisent. »

Answer 2

Semble comme la conception de base de données relationnelle pour moi. Vous avez généré une logique spécifique dans des entités spécifiques, et les avez réintégrées dans les tables d'origine ... Normalisation standard ...