ASP.Net Core: ViewComponent vs EditorTemplate / DisplayTemplate vs @inject


10

Así que estaba buscando una buena manera en ASP.Net Core para crear algunos "controles" que se procesen en una vista. Hasta ahora descubrí que hay 3 opciones, y quería obtener algunos comentarios sobre ellas.

  1. ViewComponents: son como mini controladores y usan métodos como acciones para renderizar desde una página de afeitar (ver). Creo que pueden tener una lógica autónoma para que no haya dependencia en ningún modelo de vista principal.

  2. Carpetas EditorTemplate / DisplayTemplate: existen en "Vistas / Compartidas /" y se pueden extraer en una vista pasándoles una propiedad de modelo (usando DisplayFor()o EditorFor()).

  3. @inject para ASP.Net Core: permite inyectar un tipo en una vista (¿No tengo idea si se puede asociar una vista parcial?).

  4. Estoy dejando de lado la posibilidad de incluir vistas parciales directamente, ya que no es mi intención el sistema de control que estoy transfiriendo.

  5. Ayudantes de etiqueta: también es posible inyectar el contexto de vista actual y crear controles a partir de estos.

En una aplicación ASP.NET MVC anterior, tenía algunos controles que se representaban desde las plantillas (# 2). Sin embargo, para .Net Core, estoy considerando posiblemente usar ViewComponents en su lugar (que parecen más potentes) para representar vistas de afeitar asociadas (los controles básicamente solo envuelven vistas de afeitar). Por el momento experimentaré con la conversión a ViewComponents, pero me encantaría recibir algunos consejos al respecto, gracias.

Respuestas:


2

Use ViewComponent si tiene alguna lógica de negocios para ejecutar. Es compatible con el principio de separación de preocupaciones (SoC). Puede inyectar parámetros a la clase ViewComponent desde la vista (use el archivo razor .cshtml). Las vistas de ViewComponent se pueden encontrar en Vistas / Compartido / Componentes . Puede ser fuertemente tipado. ViewComponent utiliza llamadas a métodos asincrónicos, por lo que los usuarios no tienen que esperar a que se cargue todo el contenido de una página completa. Además, ViewComponent se puede invocar como Tag Helper: debe agregar su ViewCompenent como Tag Helper utilizando la directiva @addTagHelpers. Esta característica brinda soporte para el editor de desarrolladores en la plantilla del editor de afeitar.

Use Editor / Display Template cuando edite o muestre ciertos tipos o clases. Por ejemplo, desea especificar que el objeto Producto debe aparecer con la tabla de especificaciones. Conserva el principio DRY en su aplicación MVC. Se puede usar como vista parcial que es un modelo vinculado al objeto que desea mostrar.


0

Mi enfoque es el siguiente ...

  1. Use ViewComponent para encapsular la lógica empresarial de cómo recuperar los modelos que se mostrarán
  2. Si la vista de destino es simple y / o única, coloque el html aquí directamente, de lo contrario, use DisplayTemplate para representar el modelo

La razón es que sigo teniendo una separación de preocupaciones entre la lógica comercial y la representación.

Como ejemplo práctico, tome algo como una estructura de menú específica del contexto; ViewComponent puede determinar qué menús mostrar y DisplayTemplate puede representar cada uno.


Tenga cuidado de usar estos para cargar datos. Un empleado mío hizo eso y luego, cuando queríamos construir una API REST para AJAX (por ejemplo, si alguien quería usar Angular), la lógica estaba en la API y NO en los componentes. ;) Si no usa una API REST para su sitio (que es común hoy en día), entonces los componentes se usan mejor para renderizar solo pasándoles datos por acciones del controlador y devolviendo el resultado. Al final, decidí usar Tag Helpers con un contexto de acción inyectado para construir mis controles como etiquetas en las vistas. Se ve mucho más limpio al final. ;)
James Wilkins

Inyecto el servicio de API en ViewComponent para adquirir realmente los datos: si necesitamos la misma lógica que devuelve el html de destino, por ejemplo, para usar ajax para actualizar el componente, lo expongo a través de un método de controlador.
Paul Hatcher
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.