Quand la fonctionnalité devrait-elle être disponible dans son propre contrôleur?

Question

Je travaille sur une application web qui doit présenter des graphiques sur différentes pages. Chaque page correspond à un contrôleur et chaque contrôleur qui a besoin d'un graphique a une interface avec un ChartService. Le service demande un graphique à un fournisseur tiers. Il renvoie ensuite une image enveloppée dans du code HTML avec JavaScript en tant que chaîne directement dans le flux de sortie. Le service ChartService doit être fourni avec des données et d'autres paramètres tels que la période et le fichier modèle.

Dois-je faire abstraction de la fonctionnalité de cartographie dans son propre contrôleur? Chaque type différent de graphique pourrait être servi par une méthode d'action différente sur le ChartController.

Mais serait-ce un problème alors que je sers certaines de mes pages à partir de plusieurs contrôleurs? Quelles sont les directives pour déterminer quand la fonctionnalité devrait avoir son propre contrôleur?

Answer 1

On dirait que vous n'avez rien à changer. Vous avez supprimé le service tiers à l'intérieur d'un wrapper afin que vos contrôleurs ne dépendent pas directement de ce service spécifique. Créer un nouveau contrôleur dans ce cas équivaudrait à créer un wrapper autour de votre wrapper.

Créez un nouveau contrôleur lorsque vous souhaitez ajouter un comportement à l'application.

Answer 2

Dave,

je voudrais avoir une BaseController abstraite que votre contrôleur principal hérité de. le contrôleur de base aurait toutes les fonctionnalités requises avec les parties prioritaires du contrôleur enfant appropriées. sans connaître le contexte complet de votre dilema, cela peut être ou non une approche faisable (ou souhaitable) mais c'est celui que j'emploie à travers tous mes contrôleurs à l'heure actuelle.

[modifier] - la beauté de cette approche est que si vous êtes chanceux, 75% de la fonctionnalité BaseController restera avec seulement 25% de la fonction étant overriden et/ou des fonctionnalités sur mesure ajoutée pour que le contrôleur de l'enfant . Cela vous donnerait un paradigme très propre car chaque nouveau type de graphique aurait son propre modèle/contrôleur avec des noms de méthodes d'action potentiellement identiques, rendant ainsi le coût de 'l'entrée' pour les nouveaux types de graphiques très peu coûteux.

jim

Answer 3

OMI, Si vous avez une section "tracer" avec des années url comme

charts/income 
charts/expenditure 

alors un contrôleur dressant une carte logique. En outre, si par exemple votre contrôleur de cartographie est appelé exclusivement par des requêtes ajax à partir de diverses pages, alors un chartingController a encore du sens. Mais si vous allez avoir urls comme

products/list 
products/yearlyStockChart 
employees/details 
employees/performanceChart 

alors vous voulez un ProduitsController avec liste() et yearlyStockChart() actions, et un employeesController avec des détails() et les actions performanceChart(), à la fois contrôleur en utilisant un service de cartographie.