Saltar al contenido

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web ASP.NET Core, MVC, Blazor, SignalR, Entity Framework, C#, Azure, Javascript... y lo que venga ;)

18 años online

el blog de José M. Aguilar

Inicio El autor Contactar

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web
ASP.NET Core, MVC, Blazor, SignalR, Entity Framework, C#, Azure, Javascript...

¡Microsoft MVP!
martes, 24 de marzo de 2015
ASP.NET CoreCuando hace unas semanas hablábamos de la desaparición del Web.config en ASP.NET Core, seguro que a muchos os surgió una duda en cuanto a las consecuencias que esto podría tener en aplicaciones MVC: ¿y qué ocurre con el Web.config que encontrábamos en la carpeta /Views o /Area/<AreaName/Views?

Pues a ver si este post nos lo aclara un poco ;) Pero eso sí, siempre tened en cuenta que las nuevas versiones están aún en beta y algunas cosas pueden cambiar.



Como recordaréis, en versiones usábamos este archivo de configuración básicamente para tres cosas:
  • Primero, para evitar el acceso directo a los archivos de vista desde el exterior. Para ello, en la implementación por defecto de este archivo se añadía un handler que respondía a todas las peticiones con un “not found”.
           
  • Segundo, para indicar cuál es el tipo base de las vistas por defecto, es decir, la clase de la que heredarán los objetos que representan a las vistas de nuestra aplicación. Sólo era necesario tocarlo si queríamos modificar la clase base por algún motivo, como añadir propiedades personalizadas.
     
  • Tercero, para incluir globalmente, a todas las vistas afectadas, espacios de nombres de clases o elementos utilizados en ellas, como helpers, view-models y otros, y así ahorrarnos el introducir los @using en todas ellas.
La siguiente porción de código corresponde a uno de estos archivos Web.config, y están señalados los puntos donde se realizan las tareas anteriores:



En ASP.NET Core MVC 1.0, estas tareas siguen pudiéndose hacer de alguna u otra forma, pero dado que no existen los archivos Web.config, se consiguen de otra manera.

1. Evitar el acceso directo a la carpeta Views

La carpeta wwwrootBueno, esto no es que se haga de otra forma… directamente es que no es necesario. En el servidor web sólo estarán accesibles los archivos que cuelguen de la nueva carpeta wwwroot y ahí no encontraremos las vistas, por lo que problema solucionado.

Y en todo caso, aunque no fuera así, ASP.NET Core no servirá archivos salvo que le indiquemos lo contrario, es decir, que incluyamos en el pipeline el middleware encargado de hacerlo. Y en él podemos configurar explícitamente las carpetas que contienen los archivos estáticos, por lo que nunca se podría llegar a una carpeta que no nos interesara.

2. Cambiar el tipo base de una vista

Si queremos cambiar la clase base de una única vista, obviamente no necesitamos un archivo independiente para ello. Bastará con usar en ella la directiva @inherits, que ya estaba presente en versiones anteriores de Razor:

@inherits MyBaseView

Sin embargo, aún no he conseguido dar con la forma de modificar la clase base por defecto en todas las vistas de la aplicación. Existe alguna referencia a cómo se hacía con versiones alfa/beta anteriores, pero en la actualidad no funciona bien, y todos mis intentos adicionales de momento han sido infructuosos.

Seguiremos atentos a ver cómo se desarrollan los acontecimientos, aunque ciertamente el hecho de que pueda añadir propiedades a una vista usando la directiva @inject hace que la herencia no sea necesaria en muchos casos, por lo que tampoco es algo que me quite el sueño en este momento.

3. Importar espacios de nombres en todas las vistas

La importación de namespaces en todas las vistas de nuestra aplicación es bastante cómoda porque evita que tengamos que introducir @using repetidos en todas ellas cuando usan componentes definidos en los mismos espacios de nombres.

Esto lo haremos, como siempre, utilizando la directiva @using de Razor, pero en lugar de hacerlo en cada una de las vistas, lo haremos de forma general en el nuevo archivo _GlobalImports.cshtml, del que ya hemos hablado en otra ocasión.

Probablemente os preguntaréis que por qué no usar para ello el clásico _Viewstart.cshtml, y la respuesta es sencilla: sólo se ejecuta con vistas completas, y no parciales o layouts, por lo que el ámbito de aplicación sería menor. Por esta razón, en MVC _ViewStart.cshtml se ha dejado exclusivamente para introducir código ejecutable de inicialización de vistas (como puede ser el establecimiento de la propiedad Layout), y las directivas que queramos aplicar globalmente nos las llevaremos a _GlobalImports.cshtml.

El archivo _GlobalImports.cshtml es muy similar a _ViewStart.cshtml: se encuentra en su misma ubicación, se procesará al ejecutar las vistas, y se aplicará a todas las que se encuentren en su jerarquía de directorios. Sin embargo, a diferencia del segundo, no sólo se ejecutará en las vistas “principales”, sino también en las parciales y layouts. Por tanto, todas las vistas que se encuentren por debajo de la carpeta del archivo de importaciones globales heredarán las directivas especificadas en éste.

Actualización: _GlobalImports.cshtml se denomina _ViewImports.cshtml a partir de la beta 5.

Bueno, y con esto hemos acabado por hoy. Como habréis visto, tras la desaparición del Web.config de las carpetas de vistas en ASP.NET Core, más o menos podremos conseguir el mismo resultado que antes, simplemente se trata de acostumbrarnos al nuevo escenario ;)

Publicado en Variable not found.

2 Comentarios:

Unknown dijo...

Estimado José.
Tal vez no sea el lugar adecuado para realizar esta pregunta pero bueno te la hago.
Estoy trabajando en un proyecto MVC5 en la cual para tener una mejor organización del proyecto decidí crear ÁREAS en lugar de meter todo en la misma bolsa, pero en dichas ÁREAS se crean automáticamente un web.config (en la subcarpeta view) por cada ÁREA. investigando lei que esto es para configuraciones personalizadas para cada ÁREA, y si no aplicaré dichas configuraciones adicionales no tiene sentido tener esos web.config's y puedo eliminarlos, efectivamente los elimine y no veo que afecte a mi aplicación, y quisiera que me orientes al respecto, quisiera ir por el camino adecuado al trabajar con ÁREAS y creo que tengo 3 caminos: 1. No trabajar con ÁREAS, trabajar con ÁREAS y eliminar el web.config, 3. trabajar con ÁREAS y dejar el web.config que viene por defecto.

José María Aguilar dijo...

Hola!

Las áreas pueden ser interesantes para "trocear" aplicaciones grandes y hacerlas más manejables. Si tu proyecto tiene un tamaño que lo requiere, no veo nada malo en utilizarlas; yo las uso en muchos proyectos y no he encontrado contraindicaciones destacables en hacerlo.

En cuanto al web.config, deja el que viene que por defecto. Su utilidad inicial es impedir que se pueda acceder directamente al contenido de esas carpetas (igual que el que tienes en /views), aunque también pueden usarse para importar namespaces y otras cosillas. No te vendrá mal tenerlos ahí.

Saludos!