Meilleur endroit pour trier une liste de tâches

Question

Je crée une application Web qui est une application de gestion de processus. Une liste de tâches à faire sera affichée à plusieurs types d’employés. Chaque tâche terminée, elle est ensuite transférée au prochain employé sur lequel travailler.

La hiérarchie des tâches est Batch > Charger > Assemblée > Partie > Tâche. Il existe actuellement 8 règles pour déterminer quelle tâche doit être traitée en premier pour chaque type d'employé. Ces règles s'appliquent à la taille de la pièce et à la manière dont l'achèvement des pièces affectera la hiérarchie. Par exemple, si la partie A est complétée, il termine alors un lot entier, la partie B ne le permettant pas, car il reste encore des pièces dans son lot à compléter.

Quoi qu’il en soit, c’est l’aspect fondamental du fonctionnement du système. Ce que j’essaie de comprendre, c’est un moyen efficace, rapide et facile à maintenir, tout en gardant à l’esprit que les règles peuvent changer et que de nouvelles règles peuvent être ajoutées.

Au départ, j’avais l’intention de laisser la base de données (sql 2005) s’occuper de tout, mais je crains que les règles plus complexes ne soient difficiles à appliquer avec une base de données. Une autre solution consiste donc à extraire une liste de tâches dans un niveau intermédiaire, à créer une collection d'objets et à appliquer chacune des règles à la collection. Je ne doute pas que chaque règle puisse être traduite en T-SQL de manière isolée, mais le fait de choisir 8 critères au maximum, en fonction du type de tâche, vous semblera fastidieux.

L’avantage de l’approche de niveau intermédiaire est que je peux créer un système plus restreint dans lequel le flux de tâches peut être modifié, ce qui serait plus difficile dans la base de données, je pense.

Alors, que recommanderiez-vous? Y a-t-il une troisième alternative à laquelle je n'ai pas pensé?

EDIT [1] Juste pour nuancer un peu cette remarque, on ne s'attend pas à ce que la base de données change par rapport à ce que je développais initialement.

Answer 1

Il est difficile de déterminer à partir des détails de la question. Toutefois, si vous placez votre logique dans une couche de logique métier (intermédiaire), vos règles métier peuvent continuer à utiliser le même code, quelle que soit la base de données back-end. Si vous spécifiez T-SQL pour le moment, mais est-il possible qu'à l'avenir, vous passiez dans un environnement non-SQL Server?

Answer 2

Quelle plateforme? .NET 3.5 introduit LinqToSQL qui peut en faire un point discutable. Vous pouvez utiliser un modèle de stratégie pour sélectionner / construire une requête appropriée en fonction du type de tâche, puis laisser LINQ effectuer la traduction en SQL pour vous. De cette façon, vous pouvez construire la requête dans le code, mais la faire exécuter sur le DB.