¿Debería una página maestra de ASP.NET obtener sus datos de la vista?

He estado jugando con ASP.NET MVC en un sitio que contiene una página maestra.

ProductThumbnailControl un control de usuario MVC llamado ProductThumbnailControl . El control de usuario muestra un producto y una pequeña imagen en miniatura. La vista es una vista de ViewProduct que muestra información completa del producto: el control de usuario solo es un elemento de la interfaz de usuario en el sitio.

  public partial class ProductThumbnailControl : System.Web.Mvc.ViewProductControl { } 

Leí una entrada de blog que muestra cómo los controles de usuario consumen ViewData . Aprendí que el control del usuario puede obtener su modelo automáticamente desde la vista principal. Dado que consume la misma información, la Vista no necesita pasar explícitamente nada al control del usuario, lo que permite un marcado y un código más limpios.

Así que ahora he aprendido que la página maestra está usando la misma ViewData que la página. Esto significa que la página maestra en sí misma no tiene realmente un modelo para ayudar a renderizarse.

Pregunta

¿Cuál es la forma correcta para que una página maestra obtenga sus datos en primer lugar?

Pensé en intentar lo siguiente?

Podrías tener un SiteModel :

 //Arbitrary properties for example class SiteModel { public string PartnerId {get; set;} public ShoppingCart ShoppingCartContents {get; set;} public string CurrentUserId {get; set;} } 

La vista hereda de ella:

 class ViewProductModel : SiteModel { public Product Product {get; set;} } 

SiteModel sería consumido por la página maestra. Las vistas podrían utilizar los datos si fuera necesario, si necesitaban mostrar el correo electrónico del usuario actual en algún lugar.

¿Es esta una idea horrible?

¿Debería la página maestra obtener sus datos desde donde la necesite?

¿Qué pasa si quiero incluir un control de usuario en la masthead ?

¿De dónde obtendría su ViewData ya que solo hay un objeto ViewData para la página?

¿Tendría que usar esta horrible syntax que odio y pasar el control de usuario de la página maestra a un modelo explícito?

 Html.RenderUserControl("~/Views/Account/UserControls/Header.ascx", null, new { SelectedItem = "Profile" }) 

¿Cuál es la mejor manera de abordar este escenario?

Nuestra página maestra toma los datos de la vista. Usamos nombres de vista muy tipificados para nuestras vistas y en los métodos para esa implementación también agregamos datos de vista estándar que cada página necesita de nuestros objetos persistentes (como la información de la estructura del menú de la aplicación, la información del usuario para mostrar en la pantalla, etc.).

Esto tiene la desventaja de hacer que nuestros datos de visualización para la página maestra no estén tan fuertemente escritos como lo son para el objeto Modelo, pero funciona muy bien para nosotros.

Tu idea también es buena. Como la idea de la página maestra es similar a la idea de herencia, ¿por qué no usar la herencia para configurar los objetos del modelo? Podría ir un paso más allá y crear una fábrica de modelos que produzca los objetos de su modelo y establezca los datos de la clase base mientras lo hace.

Parece que mi solución es muy similar a la recomendación de Microsoft con una excepción clave. Estaba creando una clase de base ViewData, y ellos crearon una clase de base de Controlador, lo cual tiene mucho más sentido.

Sin embargo, parece que ambas ideas podrían (y deberían) trabajar en conjunto. El tutorial de MS a continuación utiliza un diccionario para almacenar datos de visualización, por lo que si tuviera un modelo fuertemente tipado, también necesitaría una clase de base para eso.

Tutorial de Microsoft MVC

Yo crearía un Controlador ShoppingCart (o controladores separados para cada inquietud) y mostraría los controles de uso que los usan con RenderAction que se encuentra en la DLL de futuros que puede descargar desde http://www.codeplex.com/asp.net. Es parte del código fuente de ASP.NET MVC.

El uso de un controlador base o un ‘modelo de sitio’ une demasiadas cosas, creando una pesadilla de mantenimiento y pruebas.