Una de las novedades de VS2017 es el soporte integrado para Docker: podemos desplegar fácilmente nuestras soluciones en contenedores locales y depurar nuestro código Docker que se ejecuta en un contenedor. Pero… ¿cómo funciona exactamente?
**
**
Que NuGet ha supuesto una revolución en .NET es más que evidente. Lejos han quedado aquellos tiempos en que gestionábamos las dependencias como podíamos. Poco a poco el modelo de desarrollo está migrando de estar basado en “dependencias a ensamblados” a “dependencias a paquetes”, y a medida que netcore vaya teniendo una mayor relevancia esto irá a más.
Pero esta gestión semi-automatizada de las dependencias también trae sus propios quebraderos de cabeza…
En nodejs es muy común hablar del “npm hell” o el infierno que puede suponer la gestión de paquetes usando npm. Que al cabo de un tiempo alguien se baje el código de tu repositorio y que no le funcione o bien que actualices un paquete y se terminen rompiendo 400 más, es algo muy (demasiado) habitual. ¿Tenemos en .NET un nuget hell?
Nota: Este post es sobre ASP.NET Core 2 Preview 1. Algunas cosas pueden cambiar en la versión final.
¿Quien se acuerda de las ASP.NET Web Pages? Salieron tampoco hace tanto, más o menos junto con MVC3 y les acompañaba un producto propio (WebMatrix). Su objetivo era proporcionar un modelo de desarrollo basado en páginas (a lo Webforms) en contraposición del modelo basado en controladores de MVC.
He de reconocer que nunca les presté mucha atención y tengo la impresión que el resto del mundo tampoco. Su objetivo creo que era ofrecer una puerta de entrada rápida a ASP.NET ofreciendo un modelo sencillo de páginas. Su principal problema es que era difícil integrarlo en un proyecto “más grande” que estuviese hecho en ASP.NET MVC y así tener partes usando “Web Pages” y otras en MVC. Y, honestamente, montar un proyecto complejo en un modelo basado en páginas, no termino de verlo.
Personalmente las olvidé hace tiempo y por eso el anuncio de “Razor Pages” en ASP.NET Core 2 me sorprendió bastante. Pero la realidad es que Razor Pages es otra cosa bastante más interesante que las antiguas “Web Pages”…
Un buen amigo escribía lo siguiente el otro día en twitter:
_Me ha estallado un ojo hoy
Él estaba en contra del uso de 404 para indicar que no se encuentra un determinado recurso. A partir de aquí se sucedieron varios tweets y eso me ha motivado a escribir este post sobre códigos de retorno en una API REST, con MIS opiniones al respecto, por supuesto! Y como digo siempre, todo debate será bienvenido!
Desde sus inicios Visual Studio contiene el concepto de solución como grupo de proyectos. Es más, no puedes abrir un solo proyecto siempre debes abrir una solución (si abres un proyecto VS crea una solución que contiene el proyecto de forma automática).
Como idea, hace años no estaba mal. Y que quede claro: en según que contextos puede seguir siendo válida. Pero en muchos otros, solo aporta problemas: el desarrollo de software ha cambiado mucho, las formas en como usamos los IDEs no son iguales, pero VS sigue anclado a este obsoleto sistema de gestionar proyectos.
Buenas! Vamos a explorar en este post la interfaz IStartupFilter, por lo general un desconocido de ASP.NET Core, pero bueno… que está por ahí y no está de más conocerlo un poco. ¡Vamos allá!
El otro día Antíoco Llanos lanzaba el siguiente tweet:
(Siempre las mismas dudas. Que dependa mi capa de negocio de EF para usar sus IDbSet o no… ¿abstraer la abstracción?)
Contesté yo con algunas sugerencias y eso derivó en otra conversación paralela, así que me parece una buena idea poner algunas pinceladas sobre como podemos abordar ese aspecto. Por supuesto y como digo siempe: no hay balas de plata y no existe la arquitectura para todo. Cada proyecto debe analizarse para valorar la arquitectura a abordar, o arquitecturas porque se pueden usar distintas en un mismo proyecto. Así, este post no tiene más pretensión que contarte algunas ideas, pero las conclusiones que saques de ellas son cosa tuya 😉
Si desarrollas una aplicación en ASP.NET y/o ASP.NET Core, te puede interesar una nueva librería que ha sacado el equipo de .NET: HealthChecks. Esa librería (muy sencilla) contiene lo que necesitas para poder validar que un determinado recurso externo (SQL Server, API remota, etc) está funcionando y también para que decidas lo que significa que un recurso “está funcionando”.
El otro día estuve hablando con Joan Jané, sobre la funcionalidad que se está valorando para C#7 o (probablemente, dado su estado) más adelante. A falta de un nombre mejor llamaré a esa funcionalidad “Default method implementation” porque así se conoce en Java, donde esa funcionalidad ya existe.
Joan y yo teníamos puntos de vista totalmente opuestos a dicha característica, mientras que para mi era un añadido muy interesante al lenguaje, Joan se alineaba más con las tesis que Fernando Escolar expone en un post en su blog. Para Fer, esa feature es la peor idea que ha tenido Java en los últimos años. A mi me da la sensación que verlo así es no entender exactamente que añade esa característica y analizarla desde una posición demasiado rígida. Joan argumentaba problemas relacionados con SOLID, generalmente con el SRP y con la segregación de interfaces. En este post voy a comentar lo que, desde mi punto de vista, permitiría esa característica de estar disponible. Y por qué, no solo no es una mala idea, si no, a priori, todo lo contrario (tanto en Java como en C# por más que se empecine Fer en decir lo contrario).
En el post anterior vimos como empaquetar y desplegar en Docker una sencilla aplicación (un hello world) en asp.net core. En este post vamos a ver como desplegar en Docker una aplicación asp.net core (con sus controladores y vistas) y también ver como lo podemos usar usando una imagen base que no tenga el SDK, solo el runtime.
¡Vamos allá!