Encapsulate cas d'utilisation dans un logiciel

Question

J'écris habituellement des cas d'utilisation pour tous les logiciels que je développe. Pour chaque cas d'utilisation j'écris généralement un contrôleur qui dirige le flux (implémente un cas d'utilisation).

J'ai récemment commencé à développer des applications Web en utilisant Asp.net MVC. Une des meilleures pratiques de Asp.net MVC est de garder une logique très faible dans les contrôleurs. Je ne suis pas en mesure de comprendre comment vais-je changer ma conception pour en tenir compte.

Je veux essentiellement un moyen de résumer mes cas d'utilisation.

Answer 1

Créer un composant métier pour encapsuler les cas d'utilisation. Par exemple, si vous avez un système de gestion des congés que vous auriez des cas d'utilisation comme une demande de congé, d'approuver une demande de congé, rejeter une demande de congé, etc. Pour cela, vous pouvez créer un composant d'affaires (classe) appelée Gestionnaire de congés avec les méthodes (fonctions / opérations) comme « Appliquer », « approuver », « Rejeter », etc. Ces méthodes symboliseront votre cas d'utilisation. Ces méthodes prendraient vos entités commerciales et des classes de stockage de données en entrée et exécuter le cas d'utilisation.

class LeaveManager{
     int Apply(from, to);

     bool Approve(leaveApplicationId, approverId);

     bool Reject(leaveApplicationId, approverId);
}

Vous pouvez ensuite utiliser ce composant métier dans vos contrôleurs pour exécuter le cas d'utilisation en fournissant les paramètres requis.

Answer 2

Je pense avoir un modèle de graisse et contrôleur maigre est généralement une bonne pratique dans toutes les langues et non spécifiquement .NET MVC. Checkout cette belle qui passe par un exemple de scénario montrant les avantages d'un mode de graisse dans Ruby on Rails (mais les idées à appliquer toutes les langues).

Pour représenter les cas d'utilisation dans votre code, je pense un endroit bien meilleur pour eux est dans l'essai de cas plutôt que le contrôleur.

Answer 3

Poussez autant la logique métier à vos modèles et classes d'aide que possible, et utiliser les contrôleurs principalement pour le traitement des appels d'URL et instancier les modèles concernés, la récupération de ces données, et en poussant des données sur les points de vue. Les vues et les contrôleurs devraient avoir quelques décisions à prendre que possible.