#NETRAF2017, un evento que la rompió!!

Buenas!

Les comento que tuve la suerte de participar como speaker en el #NETRAF2017, un evento de tecnologías .NET que se hizo en la ciudad de Rafaela el pasado sábado 20 de mayo. Un lujo todos los speakers de primer nivel que participaron, tanto de la ciudad como a nivel nacional.

En el mismo participé con dos charlas:

La plataforma .NET en el 2017:

En estos últimos tiempos ha habido varios cambios en la plataforma, por lo que es interesante hacer una revisión de dónde estamos parados como desarrolladores y qué alternativas tenemos disponibles. Por ello hice un repaso en general del estado actual de la plataforma y sus particularidades.

Las diapositivas utilizadas son las siguientes:

Chat multiplataforma con reconocimiento de voz:

A modo de cierre del evento, con Ezequiel aplicamos distintos conceptos que se vieron en el evento para desarrollar un chat multiplataforma (sitio web, app Android y app iOS). Para ello, utilizamos las siguientes tecnologías / plataformas:

Leer más »

Anuncios

Documentación automática en ASP.NET WebApi y soporte para arquitectura en capas

Buenas!

Como vimos en el post anterior, es muy sencillo el poder tener una documentación automática y detallada de nuestras WebApi’s. Sin embargo, el enfoque propuesto solamente nos sirve cuando todas las clases involucradas están en el mismo proyecto web.

Esto muchas veces no necesariamente es así. En una arquitectura en capas normalmente tendremos un proyecto separado con las clases que representan las entidades del dominio de nuestra aplicación, las cuales formarán parte tanto de requests y responses de la API. Además de que este esquema (con las clases de entidades separadas en otro proyecto) nos permite compartirlas de forma directa (a través de la DLL resultante) a los clientes de la API, por lo cual es una alternativa más que válida para cualquier caso real de implementación.

Veamos el siguiente ejemplo, donde tenemos nuestro proyecto web (WebApi) y una biblioteca de clases con nuestras entidades que interactuan en la API (WebApi.Contracts). En la API tenemos el controlador UsersController que retorna/recibe instancias de User:

DocumentacionWebApiOtrasAssemblies - EstructuraProyecto

Donde la clase User de contratos tiene el siguiente contenido:

Al ejecutar nuestra aplicación e ir a la documentación de la API, veremos que están las propiedades de la clase pero no la documentación que nosotros le hemos agregado:

Leer más »

ASP.NET WebApi: Documentación automática de nuestras API’s

Uno de los puntos importantes en el desarrollo de nuestras API’s RESTfull es tener una documentación adecuada para permitir y facilitar la tarea de integración de distintos clientes. Esto se debe de cierta forma a la diferencia que existe con respecto a un servicio SOAP, donde sí existe un archivo que contiene toda la definición del servicio y se utiliza para su integración.

En el caso de ASP.NET y sus servicios WebApi, esta funcionalidad viene integrada de forma nativa en el proyecto básico de este tipo. Luego de crearlo podremos ver la existencia del área HelpPage, la cual se encarga de crear la estructura de documentación asociada a nuestra API.

WebApiDoc - Area

Si ejecutamos la aplicación veremos en el menú superior el acceso API, el cual nos redirigirá al contenido de esa área.

WebApiDoc - Access

Leer más »

Internacionalización: soporte a formato de escritura Right-to-Left en ASP.NET MVC

Uno de los temas pendientes en esta serie de post’s de internacionalización que estamos viendo es el soporte a culturas con sentido de escritura de derecha a izquierda en ASP.NET MVC (Right-to-Left o su acrónimo RTL, el cual usaremos de aquí en adelante). Esto será necesario cuando nuestra aplicación deba dar soporte a culturas que utilizan dicho formato de escritura, como por ejemplo sucede con el árabe.

Siguiendo con el ejemplo que venimos utilizando en el post anterior lo primero que haremos será dar soporte al árabe como cultura de nuestra aplicación. Para ello inicialmente crearemos el archivo de recursos asociado a la cultura árabe, el cual utiliza la sigla “ar” y agregaremos el contenido de cada recurso en su idioma:

InternacionalizacionRTL - CrearRecursos

NOTA: Todo el contenido que usemos en este post escrito en árabe está traducido con Google Translate ya que no conozco dicho idioma. Si alguien conoce del idioma y considera que la traducción no es la apropiada se agradece el comentario.

Lo siguiente será agregar tanto el link que permite el acceso a dicha cultura, el valor dentro de las constantes de las culturas soportadas y la lógica mínima para reconocer y establecer dicha cultura con nuestro esquema de rutas donde se visualiza la cultura.

Leer más »

URL’s internacionalizadas en ASP.NET MVC

Hace algunos meses en una entrada asociada a Internacionalización vimos cómo cambiar la cultura manualmente en ASP.NET MVC. En el mismo continuamos con mejoras sobre la internacionalización de nuestra aplicación para que más allá de reconocer de forma automática la cultura del navegador del usuario le demos la posibilidad de que pueda cambiarlo.

Algo que venía quedando pendiente de los post’s anteriores sobre este tema es el poder reflejar en la URL la cultura en la que se está visualizando el contenido. Esto tiene varios propósitos:

  • SEO: Como podemos ver en la documentación de Google asociada a la internacionalización, se recomienda hacer visible la cultura de la página que se está visitando. Esto da una mejora en lo que a indexación por parte del motor de búsqueda se refiere.
  • Usabilidad: Además del propósito del punto anterior, le permitir al usuario que utiliza nuestra aplicación el poder ver la cultura correspondiente al contenido que está visualizando. Esto también aplicaría a la hora de compartir ese contenido con otros usuarios.
  • Diseño: Podemos decir que es mucho más natural en el diseño y estructura del contenido de nuestra aplicación que el acceso según cada cultura se vea reflejado en diferentes URL’s.

Para esto continuaremos con lo ya visto en el post mencionado y en toda esta serie de internacionalización, modificando y ajustando algunos aspectos.

Lo primero sobre lo que debemos trabajar es en que la cultura sea visible en la URL de nuestra aplicación, trabajando para ello en las rutas configuradas. En ASP.NET MVC esto se encuentra en el archivo App_Start/RouteConfig.cs, teniendo la ruta por defecto el esquema {controller}/{action}/{id}. Como no queremos cambiar el comportamiento de ese esquema de rutas debemos modificarlo para agregar la cultura pero sin modificar el comportamiento base con las implicancias que conlleva.

Leer más »

Eventos de conexión en SignalR

Avanzando con la serie asociada a SignalR hay un punto que nos puede ser muy útil a la hora de diseñar la interacción de nuestra aplicación: los eventos de conexión.

Explicándolo de forma muy simplificada, hay tres cosas que pueden suceder en el ciclo de vida de la conexión entre el servidor y cliente:

  • Inicio de la conexión
  • Finalización de la conexión
  • Reconexión

Los dos primeros sucederán en todos los casos, ya que siempre se creará y finalizará una conexión. En cambio la reconexión solamente se dará en aquellos casos donde haya una interrupción momentánea en la conexión entre las partes.

Lo que nos ofrece SignalR es el poder agregar lógica ante el suceso de estos eventos, pudiendo personalizar alguna situación o agregar comportamiento adicional, tanto del lado del servidor como del cliente.

Comenzando por el lado del servidor, la clase Hub – de la cual heredan nuestras propias implementaciones – tiene los métodos necesarios para la gestión de la conexión y desconexión de cada uno de los clientes del mismo. Esto lo hace a través de métodos virtuales, lo que hace que en nuestra implementación podamos realizar un override de los mismos, agregando la lógica de negocio propia además de invocar a la implementación base.

La siguiente porción de código es la definición de la clase Hub provista en las librerías de SignalR, donde podemos observar los tres métodos virtuales que nos servirán para este propósito:

Desde el lado del cliente los métodos estarán disponibles en el código JavaScript generado por SignalR. Veremos dichos métodos en detalle en cada evento en cuestión, junto con la explicación de cada uno:

Leer más »

Grupos en SignalR: administración y opciones de comunicación

En el post anterior vimos las distintas formas que tenemos disponibles en SignalR para poder comunicarse con los clientes de la aplicación, siendo los grupos la forma más completa y compleja, y por lo tanto merecedora de su propio post 😉

Los grupos nos permiten concentrar varios clientes a través de un identificador global, lo cual nos permite poder comunicarnos con los mismos a demanda sin preocuparnos por los clientes en sí que están en el grupo, más allá del momento en el cual lo creamos. Esto nos permite separar la responsabilidad del uso de grupos en dos partes: administrar los grupos y comunicarse con los clientes que los componen.

Administrando los grupos

Comencemos por el primer punto, cómo crear un grupo y agregarle como integrante un cliente? Ambas cosas se hacen directamente en un mismo método, como se puede ver a continuación:

En el Hub de SignalR tenemos disponible el elemento Groups (al igual que Clients) sobre el cual podemos ejecutar la operación Add. En la misma deberemos pasar dos parámetros, el ConnectionId del cliente que queremos agregar al grupo y el nombre/identificador del mismo. Lo que pasará aquí internamente es que si no existe el grupo con el nombre indicado se creará el mismo y luego agregará el cliente. Cabe destacar que un cliente puede estar en todos los grupos que se requiera, o en ninguno.

Leer más »