Si vous préférez que vos vues aient des classes de données de vue fortement typées, cela peut vous convenir. D'autres solutions sont probablement plus correctes mais c'est un bon équilibre entre le design et l'aspect pratique, IMHO.
La page maîtresse contient une classe de données de vue fortement typée qui ne contient que les informations qui la concernent :
public class MasterViewData
{
public ICollection<string> Navigation { get; set; }
}
Chaque vue utilisant cette page maîtresse 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îtresses :
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 comment assembler les données des pages maîtresses, j'encapsule cette logique dans une fabrique 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 à la relation maître-vue, mais lorsqu'il s'agit de rendre des éléments partiels ou des contrôles utilisateur, je composerai leurs données de vue dans les données de vue de la page, 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); %>
Il s'agit uniquement d'un code d'exemple qui n'est pas destiné à être compilé tel quel. Conçu pour ASP.Net MVC 1.0.