Quelle est votre façon de transmettre des données à la page maître (en utilisant ASP.NET MVC) sans enfreindre les règles MVC?
Personnellement, je préfère coder le contrôleur abstrait (contrôleur de base) ou la classe de base qui est passée à toutes les vues.
Si vous préférez que vos vues aient des classes de données de vue fortement typées, cela pourrait vous convenir. D'autres solutions sont probablement plus correctes mais c'est un bel équilibre entre design et praticité à mon humble avis.
La page maître prend une classe de données de vue fortement typée contenant uniquement les informations qui la concernent:
public class MasterViewData
{
public ICollection<string> Navigation { get; set; }
}
Chaque vue utilisant cette page maître prend une classe de données de vue fortement typée contenant ses informations et dérivant des données de vue des pages maîtres:
public class IndexViewData : MasterViewData
{
public string Name { get; set; }
public float Price { get; set; }
}
Comme je ne veux pas que les contrôleurs individuels sachent quoi que ce soit sur la façon de rassembler les données des pages maîtres, j'encapsule cette logique dans une usine qui est transmise à chaque contrôleur:
public interface IViewDataFactory
{
T Create<T>()
where T : MasterViewData, new()
}
public class ProductController : Controller
{
public ProductController(IViewDataFactory viewDataFactory)
...
public ActionResult Index()
{
var viewData = viewDataFactory.Create<ProductViewData>();
viewData.Name = "My product";
viewData.Price = 9.95;
return View("Index", viewData);
}
}
L'héritage correspond bien au maître pour bien visualiser la relation, mais quand il s'agit de rendre des partiels/contrôles utilisateur, je vais composer leurs données de vue dans les pages, voir les données, par ex.
public class IndexViewData : MasterViewData
{
public string Name { get; set; }
public float Price { get; set; }
public SubViewData SubViewData { get; set; }
}
<% Html.RenderPartial("Sub", Model.SubViewData); %>
Ceci n'est qu'un exemple de code et n'est pas destiné à être compilé tel quel. Conçu pour ASP.Net MVC 1.0.
Je préfère diviser les éléments basés sur les données de la vue principale en partiels et les rendre à l'aide de Html.RenderAction . Cela présente plusieurs avantages distincts par rapport à l'approche d'héritage du modèle de vue populaire:
[~ # ~] modifier [~ # ~]
Erreur générique a fourni une meilleure réponse ci-dessous. Lisez-le s'il vous plaît!
Réponse originale
Microsoft a en fait publié une entrée sur la manière "officielle" pour gérer cela. Cela fournit une procédure pas à pas avec une explication de leur raisonnement.
En bref, ils recommandent d'utiliser une classe de contrôleur abstraite, mais voyez par vous-même.
Les contrôleurs abstraits sont une bonne idée et je n'ai pas trouvé de meilleur moyen. Je suis également curieux de voir ce que d'autres ont fait.
J'ai fait quelques recherches et suis tombé sur ces deux sites. Ils pourraient peut-être aider.
Astuce ASP.NET MVC # 31 - Passage de données aux pages maîtres et aux contrôles utilisateur
Je trouve qu'un parent commun pour tous les objets de modèle que vous passez à la vue est exceptionnellement utile.
De toute façon, il y aura toujours des propriétés de modèle communes entre les pages.
Je pense qu'une autre bonne façon pourrait être de créer une interface pour la vue avec une propriété comme ParentView d'une interface, de sorte que vous pouvez l'utiliser à la fois pour les contrôles qui ont besoin d'une référence à la page (contrôle parent) et pour les vues principales auxquelles il faut accéder à partir de vues.
Les autres solutions manquent d'élégance et prennent trop de temps. Je m'excuse d'avoir fait cette chose très triste et appauvrie presque un an plus tard:
<script runat="server" type="text/C#">
protected override void OnLoad(EventArgs e)
{
base.OnLoad(e);
MasterModel = SiteMasterViewData.Get(this.Context);
}
protected SiteMasterViewData MasterModel;
</script>
Donc, clairement, j'ai cette méthode statique Get () sur SiteMasterViewData qui renvoie SiteMasterViewData.
L'objet Request.Params est modifiable. Il est assez facile d'y ajouter des valeurs scalaires dans le cadre du cycle de traitement des demandes. Du point de vue de la vue, ces informations auraient pu être fournies dans QueryString ou FORM POST. hth