Novedades en C#7

Como es habitual, con la salida de una nueva versión de Visual Studio/.NET Framework en camino, tenemos también una nueva versión de uno de mis lenguajes de programación preferidos: C# 7.0.

En este post simplemente voy a nombrar las características principales que se vienen, pero para mayor detalle pueden ir al post What’s New in C# 7.0 del .NET Blog o bien ver el video News Features in C# 7.0 de Mads Torgersen – presentado recientemente para el evento Connect(); -.

¿Qué se trae esta nueva versión C#? Dejemos que ellos nos cuenten muy brevemente y luego pasamos a detallar algunas de las novedades principales:

C# 7.0 adds a number of new features and brings a focus on data consumption, code simplification and performance.

Tengan en cuenta que no estamos ante la versión final, por lo que alguna de las cosas que se comentan a continuación pueden sufrir cambios.

Sigue leyendo

Cascade-Lambda pattern

Es momento de hacer más interesante el patrón anterior. Antes que nada recordemos cual fue el resultado final en ese momento:

new EmailManager()
    .Client("client")
    .From("from@sebys.com.ar")
    .To("to@sebys.com.ar")
    .Subject("Envio email")
    .Body("Este es el contenido del e-mail")
    .Send();

Como podrán notar, el método Send() es el que realiza la “acción final” en todas las instancias de EmailManager. Esto nos permite deducir dos cosas, la primera es que toda instancia de EmailManager “finaliza” cuando realizamos el envío de correo y la segunda es que implícitamente estamos diciendo que para realizar un nuevo envío de correo necesitamos crear una nueva instancia. Aunque el comportamiento es bastante lógico, nuestra API no es explicitamente clara en su comportamiento.

Para hacer explicito este comportamiento, podemos hacer uso de las expresiones lambda.

Para trabajar con expresiones lambda vamos a convertir el método Send() es un método estático y cambiar su firma para que acepte un delegado Action<T>. Este delegado debe tomar como parámetro una instancia de EmailManager. Por último vamos a invocar la acción dentro del método, previo a realizar el envío propiamente dicho:

public static void Send(Action action)
{
    action(new EmailManager());
    Console.WriteLine("Enviar correo...");
}

Ahora veamos como cambia la forma de invocar a EmailManager:

static void Main(string[] args)
{
    EmailManager.Send((mail) => mail.Client("client")
                                   .From("from@sebys.com.ar")
                                   .To("to@sebys.com.ar")
                                   .Subject("Envio email")
                                   .Body("Este es el contenido"));
}

Con esto logramos eliminar toda confusión acerca de como debe realizarse el envió del e-mail, ya que lo que el método Send() establece claramente donde debe “construirse” el correo y que puede enviarse una única vez por instancia.

¡Espero que les sea de utilidad!

Abstract Factory Pattern

Después de una larga ausencia por motivos personales, vuelvo al ruedo. En esta oportunidad voy a escribir una sería de artículos volviendo a unos de los temas que más me interesan en programación que son los patrones de diseño. Para esta serie de post – y los ejemplos – me base en el artículo “Moving forward with .NET – Design Patterns” de la edición número 16 de la revista DNCMag.

Antes de arrancar con este patrón, veamos algunas definiciones (Wikipedia):

1. A factory creates objects.

2. The abstract factory pattern provides a way to encapsulate a group of individual factories that have a common theme without specifying their concrete classes.

La interpretación e implementación de este patrón puede ser variable. Una variación del mismo puede ser el patrón Factory, sin embargo si nos basamos en la definición anterior, este patrón lo que busca es que alguien se encargue crear instancias de objectos sin necesidad de especificar la clase concreta.

Veamos un ejemplo – aplicación de consola con C# – para que nos ayude a comprender mejor este patrón:

public class Book
{
    public string Title { get; set; }
   
    public int Pages { get; set; }
        
    public override string ToString()
    {
        return string.Format("Book {0} - {1}", Title, Pages);
    }
}

class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine(CreateInstance("AbstractFactoryPattern.Book", new Dictionary<string, object>() {
            {"Title", "Gulliver’s Travels"},
            {"Pages", 10},
        }));
    }

    private static object CreateInstance(string className, Dictionary<string, object> values)
    {
        Type type = Type.GetType(className);
        object instance = Activator.CreateInstance(type);

        foreach (var entry in values)
        {
            type.GetProperty(entry.Key).
            SetValue(instance, entry.
            Value, null);
        }
        return instance;
    }
}

En este sencillo ejemplo, la generación de instancias se delega al método CreateIntances(). Al momento de invocarlo hay que especificar como parámetros el nombre de la clase que queremos instanciar y los valores de sus propiedades por medio de un diccionario (key: nombre propiedad, value: valor).

Si bien pueden pensar que se trata solo de un método que crea instancias, este patrón puede ser muy poderoso cuando necesitamos generar nuevas instancias dinámicamente y en tiempo de ejecución a partir de las entrada de datos de un usuario. Además este patrón juega un papel clave en la inyección de dependencias (en el enlace hay mas detalle al respecto).

Si bien el ejemplo anterior es una demostración muy puntual de este patrón, existen otras formas de implementación como la del siguiente ejemplo.

Espero que les sea de utilidad!

Cascade Pattern

A cuantos de nosotros nos tocó alguna vez escribir código como el que vamos a ver a continuación?

public class EmailManager
{
    public string Client { get; set; }
    public string From { get; set; }
    public string To { get; set; }
    public string Subject { get; set; }
    public string Body { get; set; }

    public void Send()
    {
        // Enviar correo...
    }
}

Teniendo la clase EmailManager, la instanciación seria mas o menos de la siguiente forma:

var email = new EmailManager();
email.Client = "client";
email.From = "from@sebys.com.ar";
email.To = "to@sebys.com.ar";
email.Subject = "Envio email";
email.Body = "Este es el contenido del e-mail";

email.Send();

Si prestan atención al código notarán que hay algunas cositas que podríamos mejorar. En primer lugar, vemos que la variable “email” se repite un importante número de veces antes de realizar la acción final, esto nos lleva a pensar que tenemos código redundante que se puede evitar. Por otro lado no queda claro si para realizar un nuevo envío puedo utilizar la instancia ya creada o debería definir una nueva, lo que puede resultar confuso para cualquier desarrollador.

Para resolver esto hagamos algunas pequeñas adaptaciones al código:

public class EmailManager
{
    private string client { get; set; }
    private string from { get; set; }
    private string to { get; set; }
    private string subject { get; set; }
    private string body { get; set; }

    public EmailManager Client(string client)
    {
        this.client = client;
        return this;
    }

    public EmailManager From(string from)
    {
        this.from = from;
        return this;
    }

    public EmailManager To(string to)
    {
        this.to = to;
        return this;
    }

    public EmailManager Subject(string subject)
    {
        this.subject = subject;
        return this;
    }

    public EmailManager Body(string body)
    {
        this.body = body;
        return this;
    }

    public void Send()
    {
        // Enviar correo...
    }
}

Lo que hicimos es agregar a cada propiedad un método que devuelve la instancia del objeto creado, lo que nos permite ir invocando nuevos métodos sin necesidad de escribir una nueva línea.

Veamos como es la nueva forma de instanciarlo:

new EmailManager()
    .Client("client")
    .From("from@sebys.com.ar")
    .To("to@sebys.com.ar")
    .Subject("Envio email")
    .Body("Este es el contenido del e-mail")
    .Send();

Como resultado, se logra eliminar código duplicado logrando más legibilidad y simplicidad de uso.

Algunos frameworks que nos ayudan con esta tarea son FluentValidation y NBuilder. Por último, un patrón alternativo y del que ya habíamos hablado en el post es Fluent Interface.

Espero que les sea de utilidad!

ASP.NET MVC y Knockout : ViewModel

Una situación muy común que nos encontramos cuando comenzamos a trabajar con Knockout y ASP.NET MVC es la inicialización del modelo de KO (estructura JS) a partir del modelo de la vista (objeto C#). Una alternativa es inicializar el modelo de KO por medio de una llamada ajax al servidor (por ejemplo invocar un servicio WebAPI que nos devuelva el modelo ya serializado). Sin embargo como explica Eric Hexter en este excelente post, la experiencia de carga de la página por medio del renderizado del servidor (server side rendering) al parecer sigue siendo la más óptima.

Por lo tanto tenemos por un lado un renderizado inicial del lado del servidor utilizando un modelo de vista para tal propósito y por el otro lado tenemos KO con su propio modelo. La pregunta es cómo transformamos el viewmodel de ASP.NET MVC al viewmodel de KO sin utilizar llamas Ajax?

Investigando un poco encontré una simple solución propuesta por Eric Hexter (ver enlace de arriba). Lo que él propone es que simplemente convirtamos el modelo de la vista en un objeto Json dentro del código javascript de la página. En el ejemplo utilizaremos el view engine Razor para tal fin.

Manos a la obra!

En primer lugar vamos a crear el método de extensión ToJson() que nos permitirá representar objetos de .NET en formato JSON:

JsonExtension

JsonExtension

Por medio de esta extensión vamos a tener disponible el modelo de la vista en formato JSON, lo que nos posibilitará utilizarlo en nuestra lógica del lado del cliente (código javascript). Ahora lo que necesitamos es mapear el objeto JSON a los objetos observables que utiliza KO. Quien nos permite realizar tal actividad es el siguiente plugin de KO: KnockoutJS Mapping plugin  (disponible por medio de Nuget):

PM> Install-Package Knockout.Mapping

Veamos qué tan simple es su uso (continuamos con el ejemplo del post anterior):

Serializando el view model.

Serializando el view model.

Algunos puntos importantes:

  • Referencias a las librerías de KO y KnockoutJS Mapping plugin.
  • Generamos la representación JSON del modelo de la vista (del servidor) por medio del método de extensión ToJSon() y lo escribimos en el script por medio del helper HTML Raw.
  • El resto debería ser historia conocida 😉

Bien, finalmente tenemos el cuerpo del documento HTML:

Estructura HTML

Estructura HTML

Y la generación – mock – del modelo (en este ejemplo en el método de acción Index del controlador Home):

Método de acción Index

Método de acción Index

Corremos la aplicación y deberíamos obtener el siguiente resultado:

Resultado :)

Resultado 🙂

Como pueden ver esta es una forma muy simple de bindear el modelo de la vista del servidor al modelo de la vista del cliente.

Espero que les sea de utilidad!

Herramienta para validar nuestras expresiones regulares

En estos días me encontré con Regex Hero, una herramienta que nos ayuda a construir y validar expresiones regulares – regex – para .NET. El uso es bastante sencillo e intuitivo, por un lado escribimos la expresión regular y por el otro la cadena de caracteres que queremos comprobar. Sobre dicha cadena de texto se ira coloreando el contenido que cumple con el patrón de búsqueda:

Regex Hero

Regex Hero

Además nos provee de otras características, como las opciones de regex, construcción de código C# y VB y una galería de ejemplos entre otras.

Si bien es una versión limitada (de prueba) es una muy buena opción para tener en el set de herramientas, solo hay que tenerle paciencia a algunos banners comerciales 🙂

Mas herramientas:

Espero que les sea de utilidad!

Patrón PRG

En esta oportunidad vamos a hablar del patrón PRG (Post-Redirect-Get) el cual es aplicable en el desarrollo web. Tal como el nombre nos sugiere, lo que se logra con esta técnica es que la respuesta a una petición POST sea una re-dirección que nos permita obtener una nueva página por medio de una petición GET.

Antes que nada veamos, utilizando un escenario bastante común en los sitios web, el problema de no aplicar este patrón. Imaginemos un formulario de contacto, en donde el usuario carga información y se envía a un servidor web que la recibe y procesa. Por último informamos al usuario que la operación se realizó con éxito por medio de una nueva página.

En este último punto es donde arriba el problema, ya que si el usuario por esas cosas de la vida se le ocurre actualizar esta última página (F5) aparecerá el siguiente cuadro de dialogo:

Dialogo

Dialogo

El primer problema con esta advertencia es que el usuario posiblemente no entienda el mensaje (en el cual se pregunta si quiere volver a enviar la información del formulario). Por este motivo posiblemente intente reenviar la información cuando ya lo hizo!.

En el caso de hacerlo (botón “Reintentar”) se volverá a realizar la petición POST y nuevamente estaremos procesando la lógica del formulario de contacto (o el formulario que corresponda). Esto, entre otros problemas, nos puede generar registros duplicados, notificaciones duplicadas, etc …  :/

Para prevenir estos casos lo que PRG nos sugiere es lo siguiente:

  1. Recibimos una petición POST con los datos del formulario y ejecutamos la lógica que corresponda.
  2. Respondemos al cliente con una redirección (código de estados HTTP 30x) para que el navegador sepa que debe solicitar otra página (en el ejemplo sería la pantalla que informa que los datos de contacto se enviaron correctamente).
  3. El navegador obtiene esta página mediante una petición GET.

Vista la teoría, vamos a la práctica.

Aclaración: en el siguiente ejemplo voy aplicar el patrón PRG en una aplicación ASP.NET MVC pero es totalmente posible hacerlo en cualquier otra tecnología web (WebForms, PHP…).

Siguiendo el ejemplo de arriba, nuestro método de acción debería quedar  mas o menos así:

Aplicando el patrón PRG

Aplicando el patrón PRG

Muy simple, no?! En un post anterior vimos lo facil que es hacer re-direcciones en ASP.NET MVC. Veamos la respuesta del servidor luego de procesar la petición POST:

Respuesta del servidor

Respuesta del servidor

En primer lugar la respuesta a la petición POST es una re-dirección (HTTP Status 302). En segundo lugar se solicita la página “de agradecimiento” por medio de una petición GET, la cual es devuelta con éxito (HTTP Status 200). Si ahora al usuario se le ocurriera actualizar la página, el navegador le retornará la última petición realizada (petición GET).

Como pueden ver, aplicar esta patrón es muy simple, aún más con ASP.NET MVC (solo basta con modificar la respuesta en nuestro método de acción).

Espero que les sea de utilidad 🙂