Buscar contenidos

viernes, 6 de octubre de 2017

C# Método dinámico Verbo Post HttpClient WebAPIClient

Demo consumo WebAPI





Método WebAPI


    // POST api/values
        [HttpPost]
        public InfoPersonal Post(Persona persona)
        {
            InfoPersonal infoPersonal = new InfoPersonal()
            {
                personaId = persona.Id,
                celular = 123456,
                direccion="centro alajuela"
            };

            return infoPersonal;

  

Clase de Input Output de ejemplo


    public partial class Persona
    {
        public int Id { get; set; }
        public string Nombre { get; set; }
        public System.DateTime Nacimiento { get; set; }
        public int Edad { get; set; }
    }


    public class InfoPersonal
    {
        public int personaId { get; set; }
        public string direccion { get; set; }
        public int celular { get; set; }

    }

Clase para consumo de WebAPI



 public class WebAPIClientManager
    {
        string _baseAddress = "";

        public WebAPIClientManager(string baseAddress)
        {
            _baseAddress = baseAddress;
        }

        public TOutput VerbPost<TInput, TOutput>(string methodRouteURL, TInput modelInput, TOutput modelOuput)
        {
            using (System.Net.Http.HttpClient client = new HttpClient())
            {
                System.Uri baseUri = new Uri(_baseAddress);

                var requestUri = new Uri(baseUri, methodRouteURL);

                using (var requestWriter = new System.IO.StringWriter())
                {
                    var requestSerializer = JsonSerializer.Create();

                    requestSerializer.Serialize(requestWriter, modelInput);

                    var content = new StringContent(requestWriter.ToString(), System.Text.Encoding.UTF8, "application/json");

                    var responseMessage = client.PostAsync(requestUri, content).Result;

                    responseMessage.EnsureSuccessStatusCode();

                    var stream = responseMessage.Content.ReadAsStreamAsync().Result;

                    using (JsonReader jsonReader = new JsonTextReader(new System.IO.StreamReader(stream)))
                    {
                        var serializer = new JsonSerializer();

                        modelOuput = serializer.Deserialize<TOutput>(jsonReader);

                        return modelOuput;
                    }
                }

            }

        }

    }

jueves, 5 de octubre de 2017

Nueva tendencia; micro servicios




Nueva tendencia; micro servicios


¿Quién expone que es tendencia?

 


API tradicional…


Tradicionalmente, de forma local, una API (Interfaz de programación de aplicaciones) se expone a través de archivos DLL. Esto supone una dependencia de tecnología y versiones. En la Web, un API se expone a través de Servicios Web, que permiten que las aplicaciones cliente obtengan y realicen operaciones con los datos que el servicio expone.

Fortaleciendo el concepto de micro servicios


Una arquitectura de micro servicios, es un enfoque para desarrollar una aplicación software como una serie de pequeños servicios, cada uno ejecutándose de forma autónoma y comunicándose entre sí, por ejemplo, a través de peticiones HTTP a sus API.



§  Cada uno es independiente (sigue los principios SOLID)
§  Una forma de comprobar su independencia, es que, debería poderse cambiar su lenguajes de programación sin afectar su funcionamiento.
No hay reglas sobre qué tamaño tiene que tener cada micro servicio, ni sobre cómo dividir la aplicación en micro servicios, pero algunos autores como Jon Eaves caracterizan un micro servicio como algo, que a nivel de código podría ser reescrito en dos semanas.

Arquitectura Monolítico vs. Micro servicios


Imagina que queremos realizar una aplicación web, tipo Amazon, pero más sencilla. Los usuarios entran por nuestra web, ven los productos que tenemos en venta, y cuando compran un artículo, gestionamos el envío del producto a su domicilio.

Visión Monolítica


Una primera idea de cómo afrontar esta aplicación sería la siguiente arquitectura monolítica:
Podemos acceder a la página web de la tienda, realizar compras, etc., gracias a un servidor, una máquina que está ejecutando el código de la aplicación, que eventualmente se conecta a una base de datos para recuperar información.
Cuando un usuario compre un producto vía web, mostramos los productos disponibles, etc., la aplicación responderá, según la hayamos programado, pero el código de las distintas lógicas de negocio (inventario, pagos, envíos) aunque puede estar separado en distintos módulos del código, finalmente se empaqueta en un único ejecutable. A este modelo se le conoce como monolítico.
Si hago un cambio en el módulo de pagos, tendré que subir a producción de nuevo todo el código, incluido los módulos de inventario y envíos, a pesar de no haberlos cambiado.
Además, para escalar la aplicación (por ejemplo, dar servicio a muchos usuarios) tendré que ir ejecutando copias de mi aplicación bajo balanceadores de carga, que vayan re direccionando a los usuarios hacia un sitio u otro, en función de si el sistema está muy saturado. En este caso, tendré que replicar toda la aplicación, aunque solo sea el módulo de pagos el que concentre la sobrecarga.

Visión de Micro servicios

 

En vez de tener un único ejecutable, cada componente es un ejecutable por si mismo, y los servicios se comunican entre sí a través de llamadas.
En este caso también tenemos un micro servicio, que implementa la interfaz web con la que interactúan los usuarios y cierta lógica por debajo para llamar al micro servicio de pagos, inventario y envíos cuando sea necesario.

Beneficios de esta visión

§  Cada microservicio se puede desplegar de forma independiente: un cambio en el módulo de inventario, no afectará a los demás, solo tendremos que subir ese módulo.
§  Es fácil de entender, ya que la lógica de negocio está bien separada.
§  Facilita la gestión de equipos multifuncionales y autónomos
§  Es más fácil de escalar a nivel de software, ya que en lugar de replicar toda la aplicación y gestionarlo con balanceadores, replicaremos los micro servicios que tengan más carga.
Podemos formar equipos multifuncionales, que se encarguen de varios micro servicios, escalando el proceso de desarrollo de forma más sencilla.
-Bajo esta arquitectura, una buena práctica de trabajo, es separar a los equipos como unidades independientes integradas, ¿qué quiere decir esto? Que podemos tener una unidad de trabajo construyendo un Front-End y paralelamente podemos tener otra unidad, construyendo un Back-End.  Esto abre un abanico de posibilidades, por ejemplo, concentrar el conocimiento de negocio, en los equipos internos con los procesos Core como Back-End.


Observación de documentación


Ninguna arquitectura, ninguna lógica, ningún sistema, por robusto que sea, puede ser 100% exitoso, si carece de documentación.



Link artículos:
https://es.wikipedia.org/wiki/Sistemas_monol%C3%ADticos

miércoles, 4 de octubre de 2017

C# Conceptos Async / Await


Link artículo

C# 5: Async / Await

Muy buenas! Como dije en el post anterior estoy trasteando un poco con la Developers Preview de Windows 8 y la nueva API WinRT para crear aplicaciones Metro. El tema está en que esta nueva API está diseñada de forma muy asíncrona. Por suerte en C# 5 el uso de métodos asíncronos se ha simplificado mucho gracias a dos nuevas palabras clave: async y await. Y dado que, creedme, vais a tener que usarlas en cuanto os pongáis con WinRT me he decidido escribir este post para comentarlas un poco 🙂
async
Esta palabra clave se aplica a la declaración de un método pero, contra lo que se suele pensar por primera vez no declara que un método se ejecuta asíncronamente. La palabra clave async lo que indica es que este método se quiere sincronizar con métodos que se ejecutarán de forma asíncrona. Si no usáis async podréis seguir llamando métodos de forma asíncrona (de hecho hasta ahora lo veníamos haciendo), lo que no podréis hacer (de forma trivial) es sincronizaros con este método asíncrono. ¿Que significa sincronizarse con un método asíncrono? Fácil: esperar a que termine. Ni más, ni menos.
Es como si yo me voy a un bar y allí me encuentro a un colega. Me siento con él, y pido una cerveza, de la misma que está tomando él. Mientras me la traen hablamos de temas de la vida hasta que mi colega propone un brindis. Pero todavía no ha llegado el camarero con mi cerveza, así que yo y mi amigo nos quedamos esperando sin hacer nada a que el camarero llegue (sí, los dos somos un poco nerds). Cuando el camarero llega, hacemos el brindis y seguimos hablando.
Declarar un método como async es requisito indispensable para poder usar await.
await
Esa palabre clave es la que permite que un método que ha llamado a otro método asíncrono se espere a que dicho método asíncrono termine. Usando de nuevo el ejemplo del bar, cuando mi amigo dice de hacer el brindis debemos esperarnos a que llegue el camarero con mi cerveza.
La clave de todo es entender que desde el momento en que yo encargo mi cerveza al camarero (llamada al método asíncrono) hasta el momento en que decidimos que nos debemos esperar yo (con mi amigo) hemos estado haciendo otras cosas (hablando de la vida). Eso, de nuevo trasladado a código fuente, significa que entre la llamada al método asíncrono y el uso de await habrá más líneas de código fuente. Por lo tanto no usamos await cuando llamamos al método asíncrono, lo hacemos más tarde cuando queremos esperarnos a que dicho método termine (y recoger el resultado, es decir mi cerveza).
Así pues… sobre que aplicamos await? Pues todo método que quiera ser ejecutado asíncronamente debe devolver un objeto especial, que sea (ojo con la originalidad de los ingleses) awaitable. Sobre este objeto, es sobre el que llamaremos a await para esperarnos a que el método asíncrono finalice y a la vez obtener el resultado. ¿Y que es un objeto awaitable? Pues un conocido de la TPL que viene con .NET 4: Un objeto Task o su equivalente genérico Task<T>.
Métodos asíncronos
Para declarar un método que pueda ser llamado de forma asíncrona, lo único que debemos hacer es devolver un Task o Task<T> desde este método. Así se sencillo. Dejemos las cosas claras (al contrario que el chocolate): Devolver un Task NO convierte el método en asíncrono. Es la propia Task que es asíncrona. Podemos ver una Task como un delegate (o sea un método) que puede ser ejecutado de forma asíncrona. Trasladando eso de nuevo al ejemplo del bar, cuando yo pido la cerveza al camarero, le he encargado esta tarea y la he puesto en marcha. En términos de C# cuando llamo al método ServirCerveza de la clase camarero, este método me devuelve una Task<Cerveza>, que representa la tarea que he encargado al camarero. Luego yo debo poner en marcha esa tarea (con lo cual el camarero irá efectivamente a buscarla) y cuando toque esperarnos llamaremos a await sobre el objeto Task<Cerveza>. El resultado de llamar a awaitsobre una Task<Cerveza> es precisamente… un objeto de la clase Cerveza (mi cerveza para ser más exactos).
Código, código, código
Vamos a ver el ejemplo de la cerveza implementado en C# para que nos queden los conceptos más claros 😉
Para ello, dado que en la versión de VS2011 que viene con la Developers Preview de Win8 no podemos crear aplicaciones de consola, vamos a crear una aplicación Metro. En la vista principal pondremos 3 texblocks que nos permitirán ver cuando pedimos la cerveza al camarero, cuando nos la trae y como”hablamos” entre medias. El código XAML es muy simple:
image
Lo siguiente que necesito es una clase que represente a mi Camarero y un método que me permita pedirle una cerveza de forma asíncrona. Recordad que entonces debo declarar el método que me devuelva, no un objeto de Cerveza sino un objeto de Task<Cerveza>:
image
El método ServirCerveza de la clase Camarero espera un parámetro (el tipo de cerveza se quiere) y lo que hace es devolver una Task<Cerveza>. Como comenté una Task es parecido a un delegate sólo que es asíncrona, y en este caso una Task<T> se inicializa a partir de una Func<T> que le indica precisamente que se tendrá que hacer cuando se inicie la tarea. En nuestro ejemplo el camarero debe ir al almacén (que está lejos y es una operación que tarda un poco) y devolver la cerveza que se ha pedido.
Vayamos ahora a lo que ocurre cuando se pulse el botón:
image
Ponemos en txtInicial la fecha y hora en que pedimos la cerveza. Y llamamos al método ServirCerveza del camarero. Este método retorna en el acto y nos devuelve una Task<Cerveza>. En este momento la ejecución de la tarea del camarero todavía no ha empezado. Cuando llamamos a task.Start() empieza la ejecución de dicha tarea de forma asíncrona. Y a la vez, yo y mi amigo seguimos hablando de cosas de la vida. El código de HablandoDeLaVida() se ejecuta concurrentemente con el de la tarea definida en ServirCerveza. Al final mi amigo propone el brindis y como no tengo cerveza nos esperamos, usando await sobre el objeto Task<Cerveza> que había recibido. Con esto nos esperamos a que finalice dicha tarea y obtenemos el resultado (que dado que era una Task<Cerveza> el resultado es una Cerveza). Y listos.
Observad como la función Button_Click ha sido declarada como async para indicar que quiere llamar a métodos asíncronos y usar await para sincronizarse con ellos (esperar a que terminen).
El uso de async y await, junto con la clase Task de la TPL hace que en C#5 el crear y consumir métodos asíncronos sea tan fácil como ir al bar y pedir una cerveza! 🙂
Un saludo!
PD: Un comentario final, que quiero poner por completitud del post. Si declaráis un método async (porque quiereis hacer await sobre algún método asíncrono) pero a la vez este método async puede ser llamado de forma asíncrona y por lo tanto devuelve una Task<T>, entonces en la implementación del método async no es necesario que creeis la Task<T>, sino que podeis devolver directamente un objeto de tipo T. Es decir, en nuestro ejemplo el siguiente código:
image
Compila correctamente. El método devuelve una Task<Cerveza> pero a diferencia de antes no tengo que crearla explicitamente. Y eso es debido al uso de async en la declaración. Eso supongo que es porque en muchos casos se van a ir encadenando métodos asíncronos y así nos ahorramos el tener que definir las Task<T> de forma explícita. Pero insisto, no os confundáis: es Task<T> lo que hace que el método pueda ser llamado de forma asíncrona, no async. De hecho si os fijáis en la imagen el nombre del método está subrayado en verde y eso es porque el compilador me está avisando que he declarado un método async… que no usa await en ningún momento, cosa que no tiene sentido (porque la única funcionalidad de async es permitir que el método use await).

Ejemplo consumir un WebAPIClient

Link artículo #1

Link artículo Docs Microsoft #2

Link artículo #3