3

Je pense que je commence à être confus avec le travail d'un contrôleur dans MVC.ASP.NET MVC - Travail des contrôleurs

J'ai un service qui expose cinq fonctions:

  • liste des paquets dans la file d'attente
  • package get
  • package suppression
  • accepter paquet
  • nier paquet

Mon Le contrôleur ASP.NET MVC dépend de ce service, et ca n exécute généralement un appel de service sur une action. Je suis heureux jusqu'à présent.

La deuxième partie est ensuite la construction du résultat ViewModel. Si je fais cela à l'intérieur du contrôleur, le contrôleur a maintenant une liste de dépendances qui explosent - chaque action ajoutée augmente les dépendances afin de construire le modèle de vue, et celles-ci sont toutes héritées par le contrôleur. Je n'aime pas ça beaucoup. Je construis ce contrôleur qui dépend de N différents constructeurs de modèles de vue, mais en utilisant seulement un d'entre eux par demande. J'ai donc pensé à extraire tout cela et à appliquer des filtres d'action spécifiques à chaque modèle de vue. Je n'ai pas encore fait ça, mais ça semble aller.

La question que cela soulève pour moi est: quelle est la responsabilité du contrôleur? Si je finis par extraire le modèle de vue dans des filtres, mon contrôleur ne fait qu'un peu plus qu'une route qui exécute un appel de service (et fournit un plugin de filtre). Si je laisse plutôt mon contrôleur responsable de la construction de chaque modèle de vue, cela devient un gâchis.

Il semble que je veuille presque instancier une action par requête, pas un contrôleur, et j'utilise juste des filtres pour y arriver?

+0

Cette question a besoin de quelques exemples de code. –

Répondre

4

Avez-vous des ViewModels et Poco-Models dédiés? Si c'est le cas, vous pouvez gérer les données des services à l'intérieur du ViewModel. Je suis assez content de ce problème.

public class PackageViewModel() 
{ 
    public PackageDetail{get;set;} 
    public int PackageID{get;set;} 
    public List<Package>Packages{get;set;} 
    public string SomeFilterCriteria{get;set;} 

    publlic void FillPackageList(IPackageService packageService) 
    {  
     Packages = packageService.GetPackages(SomeFilterCriteria);  
    } 
} 

Contrôleur:

public ViewResult ListPackages(PackageViewModel model) 
{ 
    model.FillPackageList(PackageService); 
    return View("ListPackages",model); 

} 

Je ne comprends pas ce que vous entendez par "vue maquettistes".

+0

"Afficher les constructeurs de modèles" peut se référer à l'affectation de valeurs d'un objet DTO à un objet viewmodel. Je le fais actuellement dans mes contrôleurs - je ne sais pas si c'est le bon mouvement ou non, mais l'alternative que je vois est de passer un DTO au constructeur d'un viewmodel, dont je ne suis pas sûr qu'il soit meilleur. – Sinjai

2

Le contrôleur est supposé orchestrer toutes les actions que vous souhaitez effectuer dans votre vue. Si vous placez cette logique dans des filtres d'action, elle continue à faire la logique par demande d'itinéraire, elle sera simplement plus propre dans votre cas.

Questions connexes