Etiqueta: ASP.NET MVC

#NETRAF2017, un evento que la rompió!!

#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:

Seguir leyendo “#NETRAF2017, un evento que la rompió!!”

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:

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

ASP.NET WebApi: Documentación automática de nuestras API’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

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

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

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.

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

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.

Seguir leyendo “URL’s internacionalizadas en ASP.NET MVC”

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:

Seguir leyendo “Eventos de conexión en SignalR”

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.

Seguir leyendo “Grupos en SignalR: administración y opciones de comunicación”

Opciones para comunicarse con los clientes en SignalR

Continuando con los post’s asociados a SignalR, ya hemos podido ver tanto la implementación de SignalR dentro de ASP.NET MVC cómo el concepto del ConnectionId para identificar de forma unívoca a un cliente. Sobre esto último hemos mencionado que en las formas de envío más avanzadas de SignalR se debe hacer uso de este valor.

Veamos cuales son las formas de conexión a clientes que tenemos disponibles desde el servidor hacia los clientes:

Broadcast:

Para mi esta es la forma más sencilla de enviar notificaciones, ya que se las enviamos a absolutamente todos los clientes conectados a nuestra aplicación sin necesidad de conocer quienes son.

Este es el ejemplo que venimos usando desde el primer post asociado a la implementaciónel primer post asociado a la implementación. Para hacer uso de esta opción el Hub usaremos el elemento Clients con la opción All, indicando luego la operación del lado del cliente que queremos invocar:

Seguir leyendo “Opciones para comunicarse con los clientes en SignalR”

Qué es el ConnectionId en SignalR y para qué nos sirve?

Siguiendo con la serie de post’s que estamos viendo asociada a SignalR nos llega el momento de analizar cómo hacer para poder diferenciar a qué cliente enviarle una notificación. En el ejemplo del post anterior lo que vimos es el uso más básico que implica el envío de las notificaciones a todos los clientes:

Sin embargo hay algo allí que debemos explicar: cómo maneja SignalR la registración e información de cada cliente? La respuesta es el “ConnectionId”.

Seguir leyendo “Qué es el ConnectionId en SignalR y para qué nos sirve?”

Implementando SignalR en ASP.NET MVC

Implementando SignalR en ASP.NET MVC

En la entrada anterior vimos algunos puntos asociados al funcionamiento general de SignalR y el planteo que propone. Lo que veremos en este nuevo post es cómo implementarlo en una aplicación ASP.NET MVC y lograr al menos una interacción básica.

Lo primero que haremos es definir el funcionamiento de nuestra aplicación. Lo que queremos lograr es armar un check-list compartido entre distintos usuarios, donde cuando uno de ellos marque un elemento como realizado o no, a los otros también les aparezca dicho estado actualizado. Para este ejemplo haremos algo muy básico, lo cual con el correr de los post’s de esta serie iremos haciendo crecer.

Comenzaremos con una aplicación ASP.NET MVC básica, instalando el paquete Nuget asociado a SignalR:

Install-Package Microsoft.AspNet.SignalR

Una vez finalizada la instalación, deberemos crear el archivo Startup.cs dentro de la raíz de nuestro proyecto web. Es en el mismo donde mediante OWIN estableceremos la inicialización de los mapeos necesarios para la interacción con SignalR, quedando el archivo de la siguiente forma:

ImplementacionSignalR - ClaseStartup
Definición de clase Startup usando OWIN

Hasta allí está lo que es la configuración inicial del proyecto. Lo posterior a hacer será crear el Hub que se encargará de la comunicación con los clientes. Para ello crearemos la carpeta Hubs dentro de la raíz del proyecto web, y dentro de la misma el elemento “SignalR Hub Class” con nombre NotificationHub: Seguir leyendo “Implementando SignalR en ASP.NET MVC”