Les vues ASP.NET MVC doivent-elles être paramétrées

Question

Dans asp.net mvc, j'ai pensé qu'il serait plus avantageux de spécifier des constructeurs paramétrés sur les classes d'affichage, contrairement à ViewData pour passer des données à la vue. De cette façon, la classe d'affichage pourrait être instanciée dans l'action et renvoyée à partir de là comme une implémentation de IView pour un rendu éventuel au client par l'infrastructure.

// An example of an action that returned one of two 
// views while passing a data objects from the current 
// scope. 
IView MyAction(discriminator){ 
    if(discriminator){ 
    return new MyView(SomeVal, SomeVal2) 
    }else{ 
    return new AnotherView(SomeVal1) 
    } 
} 

// An Example Definition for IView 
public interface IView{ 
    Render(stream OutputStream); 
} 

// An Example View Code Behind/Partial Class 
public partial class AnotherView{ 
    public AnotherView(string GimmeData){ 
    this.GimmeData = GimmeData 
    } 

    // This value could be accessed in the markup like: 
    // <%=this.GimmeData%> 
    public string GimmeData {get; set;} 
} 

Je pose cette question parce que j'ai personnellement trouvé des vues fortement typées inutile car il n'y a pas 1 ou 0, mais n nombre d'objets que je voudrais passer à la vue de l'action. Je trouve aussi que la collection ViewData est un peu trop "non typée" pour être très bien maillée avec le monde fortement typé .net. Un constructeur de paramétrage ou même des propriétés publiques sur la vue permettraient à l'implémenteur de la vue de spécifier un contrat sur les données nécessaires pour rendre la vue ou pouvant être affichées dans la vue. Cette approche encapsulerait efficacement la vue.

Pourquoi cela serait-il un mauvais design? Quels sont les avantages de la "collection viewdata"/"vue fortement typée" "façon" de transmettre des données de l'action à la vue. Est-ce que quelqu'un pense que ce serait une bonne idée?

---

mise à jour

J'ai eu un changement de cœur. Ce que j'ai réalisé est que la vue est vraiment juste sur le rendu. Une très bonne approche de conception est d'introduire Presentation Models qui représente les interfaces utilisateur disponibles dans votre application.

Si quelque chose peut être affiché ou non, il devrait y avoir un booléen dans votre modèle de présentation. Si quelque chose peut afficher du texte, il doit y avoir une chaîne pour cela dans votre modèle de présentation. Le modèle de présentation n'est pas anemic parce que vous l'utilisez pour encapsuler la logique de votre interface utilisateur. Par exemple, si un champ est vide, un autre champ est peut-être grisé. C'est une logique de présentation qui décrit la façon dont fonctionne votre interface utilisateur.

Une fois qu'un modèle de présentation a été introduit, les classes de pages génériques fonctionnent correctement, il vous suffit de passer la vue au bon modèle de présentation. Les modèles de présentation vous permettent de nettoyer le code dans votre vue ainsi que d'assurer la portabilité. Si l'on décidait de mettre en œuvre des winforms, ils n'auraient sérieusement besoin que de lier leur interface utilisateur au modèle de présentation.

De toute façon, je voulais juste faire un suivi parce que je ne suis plus d'accord avec ma suggestion originale. J'ai accepté la réponse de Travis parce que c'est essentiellement ce qu'il a proposé.

Answer 1

La convention consiste généralement à fournir un modèle de vue qui encapsule les données dont vous avez besoin dans votre vue. Vous pouvez ensuite passer cet objet fortement typé dans votre vue. Ainsi, par exemple, vous pourriez avoir un objet BlogDisplay qui ressemble à ceci:

public object BlogDisplayPage { 
    public string PageTitle {get; set;} 
    public BlogEntry Content {get; set;} 
    public IList<Comment> Comments {get; set;} 
    public IList<BlogEntry> RelatedEntries {get; set;} 
    public IList<BlogEntry> PreviousEntries {get; set;} 
} 

Excuse le contrivedness de l'exemple, mais je pense que vous comprenez ce que je veux en venir. De cette façon, vous pouvez avoir toutes les données associées à la vue dans un objet qui peut être facilement testé et géré. Cela a aussi l'avantage d'avoir des vues fortement typées utilisant des génériques. Je préfère cela à votre suggestion de constructeurs paramétrés parce que son intention est claire, et la création et l'agrégation de ces données vont être dans un endroit qui sera probablement plus facile à maintenir.