La mejor manera de vista personalizada de datos?

Question

¿Cuál es la forma más práctica para agregar propiedades personalizadas a un lado ancho ViewDataDictionary?

Vamos a suponer un caso simple:

public ActionResult Index()
{
  // ViewData["Title"] = "Home";
  ViewData.Title = "Home";
  return View();
}

La primera cosa que viene a la mente es una clase personalizada y el uso de "nuevo" en un controlador de base de la aplicación:

public class CustomDataDictionary : ViewDataDictionary
{
  public string Title { get; set; }
}

public class ApplicationController : Controller
{
    public new CustomDataDictionary ViewData { get; set;} 
}

Te estoy asumiendo también tendría que hacer una CustomViewPage también correspondiente con la misma propiedad para utilizar el diccionario de datos vista personalizada de los puntos de vista también.

La segunda cosa que viene a la mente es la creación de una clase ViewDataDictionaryExtensions.

En tercer lugar, utilizar un "Vista Modelo". Mi carne con Visualización de modelos que están siempre creando uno y pasándolo a la vista parece que repetir siempre lo mismo una y otra vez en el código del controlador, al menos en comparación con las dos opciones anteriores.

El verdadero objetivo es que cada aplicación puede tener un conjunto básico de propiedades en el ViewData que tienen sentido para que las aplicaciones de propósito. Tiendo a alejarse de depender de las claves de diccionario, y sería bueno tener propiedades reales para otros desarrolladores confían en saber qué datos se establecen. Además, las teclas pueden ser fácilmente mal escritas.

Los tres métodos de hacer el trabajo. Lo que han hecho otras personas?

Answer 1

En el extremo, al menos para esta aplicación, fui con tener una clase un AppViewModel base. Controller.OnActionExecute / ed mira para ver de ViewData.Model se establece y si no lo es, una instancia de AppViewModel se pone en su lugar por lo que todas las páginas tienen un modelo consistente para trabajar con (Model.Title, Model.IsAuthenticated, Modelo .User, etc)

acciones del controlador Entonces más detalladas tienen una subclase de AppModelView que consigue ajustado a ViewData.Model ya sea manualmente en la acción misma, o conjunto en el OnExecute / ed a través de un atributo.

No mucho código en absoluto, sino que impide la repetición de la misma edad, crear el código / juego en todas las acciones del controlador. Y para mí, que mantiene los datos de vista como un paquete en vez de estorbar encima de la API del controlador.

Answer 2

Re el problema con los nombres mal escritos conseguir -. Eso es lo que son constantes para

Para ViewData a ser escrito adecuadamente, lo que se necesita para heredar etc; de manera que cuando usted ha hecho eso, me pregunto si no podría tan fácilmente añadir algo de código común en el controlador que establece una clave.

Con una llave parece, al menos para mí, la respuesta compleja menos -. Que también trabaja en el mayor número posible de casos (es decir, cuando cierto código sólo conoce un IDictionary<string,object> básica)

También puede estar interesado en esta pregunta relacionada .

Answer 3

Todos los suena como si fuera a trabajar. Calculo que uno elige depende de cuáles son sus requisitos / necesidades. (Respuesta realmente única e informativo, no?)

Su pregunta era "¿Qué han hecho los demás?" aunque. Así que, si estás de votación, I han utilizado el enfoque de constantes para aplicaciones más pequeñas recientemente. No he hecho una aplicación empresarial MVC todavía, pero me imagino que probablemente haría una clase base que hereda controlador y define las propiedades adicionales. Y si quería pasar a los que constantemente a la vista Me similarmente tienen una clase base para mis modelos. Sin embargo, esto tendría que ser utilizado juiciosamente - incluso si formalmente escribir ellos, todavía actuar mucho como globales. Así que hay que tener cuidado, por supuesto.