Francesc Jaumot

La importancia de una buena arquitectura

Francesc Jaumot — Mon, 01 Oct 2012 22:28:00 GMT

¿Qué es una arquitectura de software y que nos puede ofrecer?
En el área de software, una arquitectura nos identifica los elementos más importantes del mismo, es decir, nos da visibilidad global a todos los pasos a seguir para desarrollar.

¿Por qué es importante? Porque necesitamos una arquitectura para entender el sistema, organizar su desarrollo, plantear la realización del software y hacerlo evolucionar.

En un desarrollo de software se nos plantearán muchas dudas y casuísticas que deberemos saber cómo abordar desde un primer momento. En este planteamiento es muy importante responder a preguntas sencillas… ¿Quién? ¿Cuándo? ¿Cómo? ¿Dónde?… relacionadas con la solución para los requisitos técnicos y operacionales de nuestro sistema. Las respuestas a estas preguntas nos definirán qué componentes forman el sistema, cómo se relacionan y cómo llevan a cabo la funcionalidad.

Es muy importante tener en cuenta que las arquitecturas de software no responden únicamente a requisitos estructurales, sino que están relacionadas con aspectos de rendimiento, usabilidad, reutilización, restricciones tecnológicas e incluso cuestiones estéticas.

Arquitecturas y metodologías
Existen muchas metodologías de desarrollo de software; desde métodos muy pesados a muy ligeros que aparecen cómo respuesta al excesivo formalismo de otros métodos.

En un sistema con casos de uso que definen una secuencia de acciones entre el usuario y el sistema, visto desde un punto de vista arquitectónico, no todos los casos de uso tienen la misma importancia dónde es aconsejable destacar aquellos que nos ayudan a evitar los riesgos más importantes y sobre todo los que representan la funcionalidad básica del sistema que se debe realizar.

Cómo primera fase se debe diseñar una arquitectura base que defina nuestro sistema, lo haga robusto y sobretodo, cumpla la funcionalidad especificada.

!Una arquitectura se debe adaptar siempre a nuestra necesidad, y en ocasiones, una arquitectura puede suponer una penalización a nuestro sistema.

Tipos de arquitecturas
Hoy en día existen muchos tipos de arquitectura y todos ellos aportan su granito de arena. Lo más común en una arquitectura es que se base en un conjunto de tipos para obtener las principales ventajas de cada uno de ellos.

Debemos tener en cuenta que los diferentes tipos de arquitecturas son definiciones abstractas de cómo dividir en partes más pequeñas el sistema y de cómo estas partes deben interactuar entre si.

Cómo citación y mención a las más importantes tenemos: Cliente – Servidor, N-Layer, N-Tier, Orientado a Objetos, Presentación desacoplada, DDD (Domain Driven Design), Orientación a servicios… entre otras.

Hasta aquí todo muy bonito y perfecto… pero… ¿Cómo diseñamos una arquitectura para nuestro sistema de software?

Layers vs. Tiers
Antes de nada se debe distinguir los conceptos de Layers (Capas) y Tiers (Niveles).

El primero de ellos se refiere a desacoplar elementos de forma jerárquica de roles y responsabilidades, proporcionado una separación de las preocupaciones que tenemos en el software sin tener en cuenta la localización física de estos componentes en servidores o diferentes lugares.

El segundo desacopla de forma física los segmentos de estos elementos que se encuentran en diferentes servidores dando cómo resultado un despliegue distribuido proveyendo mejoras de escalabilidad, disponibilidad y utilización de recursos.

Ambos son importantes y se deben tener presentes, pero separar la lógica de nuestro software en N-Layers es importante para nosotros, para el cliente y para nuestro equipo. Nuestras necesidades de IT, nos indicarán si debemos usar N-Tier o no.

Ambas hacen referencia a la que es para mí una gran frase: ¡Divide y vencerás!

Próximos pasos…
En este conjunto de artículos me voy a basar, principalmente, en una arquitectura de N-Layer con orientación al dominio para ASP.NET MVC 4 con sintaxisRazor y C#. Esta arquitectura lleva conmigo un par de años y sin duda, me ha proporcionado enormes ventajas en proyectos pequeños, medianos y grandes en su justa medida.

En los próximos artículos iremos definiendo estos pequeños subsistemas de nuestro sistema de software.

[ie9] Jump Lists en la web

Francesc Jaumot — Sat, 18 Sep 2010 17:45:00 GMT

Hola a todos/as!! Internet Explorer 9 ya es beta y trae un monton de novedades. Una de las características que más me esta llamando la atención es el "Site Pinning". Esto nos permite añadir un acceso directo a la página en la barra de tareas de la família de versiones de Windows 7 y además "Jump Lists". Estas listas proporcionan navegación directamente de la página que estamos visitando. Sus usos no tienen límites, lo podemos usar para que nuestro usuario acceda a los sitios más importantes de nuestra web o también lo podemos usar de forma dinámica (esto en el próximo post) dentro de nuestras aplicaciones web realizadas en cualquier lenguaje.

¿El código? Muy sencillo y entendible. Es a base de etiquetas meta, Microsoft ha añadido una nueva llamada "msapplication-task" que es la que permite realizar esto. He realizado un ejemplo simple, en una página HTML sin nada de especial añadiendo esto:

Y luego arrastrando la pestaña de nuestra página hacía la barra de tareas de Windows 7 obtenemos el siguiente resultado,

El atributo de "application-name" es el nombre que queremos que aparezca en la Jump List, si no lo especificamos, nos aparecerá el título de la página. El "msapplication-tooltip", ocpional, es el texto que aprecerá cúando nos situemos con el ratón encima y la página no este abierta. Por último, "msapplication-task" que añade los ítem de menú para la navegación.

¿Fácil verdad? Y, creo, que de gran utilidad.
Un saludo!!

[sql] Procedimientos almacenados vía CLR

Francesc Jaumot — Wed, 15 Sep 2010 16:22:00 GMT

Hola a todos/as!!!! Hoy, voy a explicar una de las tantas cosas que nos permite hacer SQL Server.Desde la versión de SQL Server 2005 podemos crear procedimientos almacenados codificados en algún lenguaje .NET. Al poder codificar el procedimiento almacenado por medio código. Net nos permite tener acceso a ficheros de una forma eficaz, realizar validaciones con expresiones regulares, acceso a servicios web, etc ….

Voy a realizar un ejemplo de un procedimiento almacenado en SQL Server 2008 que recibe como parámetro una ruta física de un fichero, y este es almacenado en una tabla. La estructura de la tabla es sencilla, tiene un identificador, el nombre del fichero, el contenido del fichero y el tamaño del fichero.

En cualquiera de los IDE de Visual Studio, deberemos elegir cómo nuevo proyecto el tipo "Base de datos" y estableceremos en el la conexión a la BD con la que queremos albergar el procedimiento almacenado. Para ello, agregamos un nuevo elemento del tipo Procedimiento almacenado y le indicamos el nombre del mismo. El código sería este,

public partial class StoredProcedures

{

[Microsoft.SqlServer.Server.SqlProcedure]

public static void InsertarFicheros()

{

}

};

Una vez realizato esto, deberemos añadir un parámetro al procedimiento que va a ser la ruta del fichero. Realizamos una referencia al espacio de nombres System.IO para acceder al fichero. Dentro del procedimiento, escribimos el código necesario para obtener el nombre del fichero, su contenido y el tamaño, y creamos un objeto SqlCommand para insertar en la tabla de la base de datos. Nos tenemos que fijar que el prcedimiento es estático y publico, para que pueda ser llamado desde cualquier parte. Además al procedimiento tenemos que indicar el atributo [Microsoft.SqlServer.Server.SqlProcedure].

El código sería este,

    [Microsoft.SqlServer.Server.SqlProcedure]
    public static void InsertarFicheros(string ruta)
    {
        //Obtenemos el nombre del fichero
        string NombreFichero = Path.GetFileName(ruta);
        //Obtenemos el contenido del fichero
        byte[] Contenido = File.ReadAllBytes(ruta);

        using (SqlConnection cn = new SqlConnection("context connection=true"))
        {
            string sql = "insert into Ficheros (Nombre, Fichero, Tamaño) VALUES (@Nombre, @Fichero, @Tamaño)";
            SqlCommand cmd = new SqlCommand();
            cmd.Connection = cn;
            cmd.CommandType = CommandType.Text;
            cmd.CommandText = sql;

            SqlParameter p;

            p = new SqlParameter();
            p.ParameterName = "@Nombre";
            p.Direction = ParameterDirection.Input;
            p.SqlDbType = SqlDbType.VarChar;
            p.Value = NombreFichero;

            cmd.Parameters.Add(p);

            p = new SqlParameter();
            p.ParameterName = "@Fichero";
            p.Direction = ParameterDirection.Input;
            p.SqlDbType = SqlDbType.VarBinary;
            p.Value = Contenido;

            cmd.Parameters.Add(p);

            p = new SqlParameter();
            p.ParameterName = "@Tamaño";
            p.Direction = ParameterDirection.Input;
            p.SqlDbType = SqlDbType.Int;
            p.Value = Contenido.Length;

            cmd.Parameters.Add(p);

            cn.Open();
            cmd.ExecuteNonQuery();
            cn.Close();
        }
    }

Visto el anterior código, es importante destacar varias cosas. Indicamos “context connection=true” como cadena de conexión indicando que la base de datos a la que queremos conectarnos es la misma en la que nos encontramos. Debemos de crear un objeto command y configurarlo con la sentencia a ejecutar,y crear los parámetros necesarios para la sentencia. El parámetro fichero es del tipo Varbinary para almacenar los bytes del fichero. Abrimos, ejecutamos el procedimiento y cerramos la conexión.

Ahora solamente falta, generar el proyecto e implementarlo en la base de datos. Vamos al menú Generar, y primero generamos el proyecto y a continuación lo implementamos. Si vamos a la base de datos, podemos ver que se ha creado el ensamblado y el procedimiento almacendo.

Si ejecutamos ahora, nos dará el siguiente error:

Mens. 6263, Nivel 16, Estado 1, Línea 1
La ejecución de código de usuario en .NET Framework está deshabilitada. Habilite la opción de configuración "clr enabled".

Este problema es porque no tenemos hablitiada la ejecucción de código .NET (CLR). Para habilitarlo lo podemos realizar de dos formas, una en modo diseño y otra por SQL. Lo que os guste más, yo os explico las dos. Si lo hacemos mediante una instrucción SQL, tan solo debemos utilizar el procedimiento almacenado sp_configure de la forma siguiente:

ALTER DATABASE Prueba SET TRUSTWORTHY ON

Esto también se puede hacer mediante vista diseño en el mismo menú que he citado anteriormente. Lo sé, es largo Todavía no hemos terminado. Falta dar permisos al ensambla que hemos creado para poder tener acceso externo. Esto también lo podemos hacer de dos formas; si lo hacemos por código, debemos ejecutar las siguientes líneas de código:

CREATE ASSEMBLY SqlProcedimientos
FROM 'D:\VuestraRutaDeEnsamblado\SqlProcedimientos.dll'
WITH PERMISSION_SET = EXTERNAL_ACCESS

Y si lo hacemos por diseño, debemos hacer click con el botón derecho encima del ensamblado, propiedades y en el conjunto de permisos indicamos Acceso Externo o External Access (dependiendo del idioma de la base de datos).

Y ahora sí!! Si ejecutamos el procedimiento, nos insertará los datos del fichero en nuestra tabla!

exec InsertarFicheros 'C:\GraciasPorLeerMe.jpg'

[sql] Envío de mail desde SQL Server 2008

Francesc Jaumot — Sun, 25 Oct 2009 23:55:00 GMT

Hola de nuevo a todos/as!!

Esta vez toca SQL Server 2008. Hace unos días un exprofesor mío y amigo mio Jose Cousiño ,que podriamos decir que ha sido mi mentor en .net y al cúal le debo mucho :) , me explico cómo enviar correos des de SQL Server. El caso es que muchas veces necesitamos mandar correos cuando se realiza una operación en nuestra base de datos, y el envío de correo lo realizamos desde la aplicación, pero debemos de saber que se puede hacer desde el mismo servidor de bases de datos.

Para enviar los correos desde el servidor debemos de hacer varias cosas:

1. Crear un Profile para mandar los correos (Un Profile es un perfil de base de datos)
2. Envío del correo con el procedimiento almacenado msdb.dbo.sp_send_dbmail

Para crear el Profile hay dos formas, por diseño o por código. Nosotros únicamente vermos cómo se hace por diseño si a alguién le interesa por código que lo pida y lo envío.. A ello! los pasos a seguir serán los siguientes:

1. En Sql Server Managment Studio, vamos al nodo Administración / Correo electrónico de base de datos

2. Botón derecho envima del nodo "Correo electrónico de base de datos", y seleccionamos "Configurar Correo Electrónico de base de datos". Aparece un asistente que vamos a explicar detalladamente. En el primer forumlario pulsamos siguiente,

3. En el siguiente formulario, tenemos las siguientes opciones

a.     Instalar Correo electrónico de base de datos
b.     Administrar cuentas y perfiles de Correo electrónico
c.     Administrar seguridad de Perfil
d.     Ver o cambiar parámetros del sistema

Seleccionamos la primera opción para crear el Profile.

4. En el siguiente formulario vamos a crear ya el Profile y luego le añadiremos la cuenta de correo

Rellenamos el nombre de Perfil y pulsamos el botón agregar, en el cual vamos a configurar una cuenta de correo. Esta cuenta de correo puede ser cualquiera, pero generalmente cuando lo utilicemos en una empresa, utilizaremos una cuenta del servidor Exchange corporativo. Para indicar la cuenta de correo, tendremos que rellenar el siguiente formulario

-       Nombre de cuenta: Nombre de la cuenta de correo
-       Descripción: Breve descripción del nombre de cuenta.
-       Servidor smtp saliente

Dirección de correo electrónico: dirección de la cuenta de correo que enviará los correos, ejemplo sql@servidor.com
Nombre para mostrar: ponemos el nombre que se quiere mostrar, por ejemplo “Correo Sql”
Nombre del servidor: Indicamos el servidor smtp que utilizaremos para enviar al correo.

- Autenticación: Muchas veces nuestro servidor smtp necesita autenticación para poder enviar los correos. Las posibilidades son

Autenticación de Windows.
Autenticación básica: Tenemos que indicar usuario y password
Autenticación anónima: La cuenta de correo no necesita auteticación

Una vez configurado todos los valores necesarios, aceptamos y pulsamos siguiente para que se cree el Profile. Bien, ya tenemos configurado todo para que nos funcione, ahora veremos cómo se envía el correo y ya estará listo para usar. Para enviar el correo debemos ejecutar el procedimiento alamacenado de la base de datos msdb “sp_send_dbmail”. Este procedimiento almacenado tiene algunos parámetros importantes:

-       @profile_name: nombre del Profile con el que se va a enviar el correo.
-       @recipients: lista de direcciones de correo electrónico, separadas por punto y coma, a las que se va enviar el correo.
-       @copy_recipients: lista de direcciones de correo electrónico, separadas por punto y coma a las que se va a mandar el correo en “con copia”.
-       @subject: asunto del correo.
-       @body: cuerpo del correo.
-       @body_format: Indica el formato del correo. Solamente puede tener alguno de estos dos valores: TEXT O HTML.
-       @importance: indica la importancia del correo. Solamente puede contener alguno de estos valores: low, normal o high.
-       @sesitivity: indica la confidencialidad del correo. Solamente puede contener alguno de estos valores: normal, personal, prívate o confidential.
-       @file_attachments: Lista de nombre, separados por punto y coma de los archivos que se adjuntan al correo. Se debe de indicar las rutas absolutas.
-       @query: consulta que se ejecuta para rellenar el correo.
-       @mailitem_id: identificador del correo que se ha enviado.

Veamos un ejemplo que envía un correo en formato html.

EXEC msdb.dbo.sp_send_dbmail
@profile_name = 'NombreProfile',
@recipients = 'contoso@contoso.com',
@body = '<p style="color:blue">Esto es una prueba de html</p>',
@body_format = 'HTML',
@subject = 'Correo de prueba desde Sql Server'

Para poder ejecutar el procedimiento almacenado, el usuario debe tener permisos en la base de datos msdb para execute. Si el usuario con el que estamos ejecutando el procedimiento almacenado no tiene permisos sobre el procedimiento almacenado sp_send_dbmail dará un error. Para solucionarlo tenemos que ir a la base de datos msdb, a su nodo seguridad, y damos botón derecho encima del usuario y seleccionamos propiedades. En la pantalla que aparece seleccionamos la función DatabaseMailUserRole, y con eso ya podemos ejecutar el procedimiento almacenado.

¡Espero que os guste y podaís utilizarlo en vuestros code's! :)

[.net] MTOM cómo codificación de ficheros en WCF

Francesc Jaumot — Tue, 15 Sep 2009 19:31:00 GMT

MTOM (Mecanismo de optimización de transmisión del mensaje), como su nombre indica, es un mecanismo para transmitir datos binarios grandes con basicHttpBinding. De forma predeterminada, basicHttpBinding envía y recibe los mensajes en XML y este tipo de encoding del mensaje debe ser habilitado en la configuración de nuestro proyecto cómo veremos más adelante.

El objetivo de usar MTOM en vez de otro encoding de mensajes, no es otro que optimizar la transmisión de grandes cargas binarias. Al contrario, esta codificación cuándo se usa para pequeñas cargas añade una sobrecarga innecesaria en nuestro mensaje por lo que debemos saber cuándo debemos usarlo, aunque teniendo en cuenta los documentos que se usan hoy en día y la calidad de las fotografías seguramente lo uséis la gran mayoría de las veces.

Antes de empezar os recomiendo que os bajéis el código de ejemplo y lo vais siguiendo con lo que explicaré. Como veréis dentro de la solución que he creado, hay dos carpetas: Cliente y Servidor. La primera de ellas tendrá un proyecto WinForms que nos servirá para subir/bajar archivos y la segunda el servicio WCF. Lo primero que vamos a ver es un sencillo servicio en WCF que nos permitirá subir y bajar archivos de cualquier tipo. Es facil, la interface IService.cs tendrá dos métodos; uno para subir ficheros con el atributo IsOneWay = true para indicar que este método no va a devolver mensaje de respuesta y otro para obtener el fichero. Además dos clases, PeticionDescarga y Fichero. Esta última implementara la interfaz IDisposable para asegurarnos que al terminar la transmisión podremos vaciar el flujo de datos.

Cómo MTOM transmite el mensaje por SOAP debemos formatear las clases cómo tal, así que la clase Fichero contendrá las propiedades NombreFichero y Peso con el atributo [MessageHeader(MustUnderstand = true)] que nos indica que ambas propiedades pertenecerán a la cabecera SOAP (Header) del mensaje y nos permite especificar si el Header deberá ser analizado y comprendido por el destinatario o no. Sí esta a true, al enviar los datos se espera que el receptor comprenda la cabecera y los tenga en el DataContract. La propiedad FicheroBytes tiene el atributo [MessageBodyMember()] que nos indica que será el cuerpo del mensaje.

Ahora viene lo complicado, ¿Cómo hacemos que nuestro servicio transfiera sus datos a través de la codificación MTOM? Configurando el binding de nuestro servicio. Para ello nos situamos en el archivo Web.config y nos deberá quedar, además de las otras etiquetas, la configuración del servicio así:

<system.serviceModel>
   <bindings>
      <basicHttpBinding>
         <binding name="MTOMBinding" maxReceivedMessageSize="1048576" messageEncoding="Mtom" transferMode="Streamed">
         </binding>
      </basicHttpBinding>
   </bindings>
   <services>
     <service name="Service" behaviorConfiguration="ServiceBehavior">
       <endpoint address="" binding="basicHttpBinding" bindingConfiguration="MTOMBinding" contract="IService"/>
     </service>
   </services>
   <behaviors>
     <serviceBehaviors>
       <behavior name="ServiceBehavior">
         <serviceMetadata httpGetEnabled="true"/>
         <serviceDebug includeExceptionDetailInFaults="true"/>
       </behavior>
     </serviceBehaviors>
   </behaviors>
</system.serviceModel>

Como veís, le indicamos que la codificación del mensaje será con MTOM y a través del transporte http. Las propiedades a destacar y de importacia són maxReceivedMessageSize que nos indica el tamaño máximo del mensaje total expresado en bytes y transferMode que lo estableceremos a Streamed indicando así que no será un transporte almacenado en un búfer si no que será transmitido, es decir, solo deberán ser almacenadas las cabeceras SOAP y el cuerpo del mensaje será transmitido cúando se haga la petición. Cómo le hemos indicado que será transmitido ahora maxBufferSize deberá ser menor o igual que maxReceivedMessageSize ya que a diferencia de este, maxBufferSize unicamente limita el tamaño máximo de la cabecera SOAP. Para que lo podaís entender mejor, maxBufferSize configura el búfer de WCF que almacena la cabecera del mensaje mientras se procesa el mensaje en el extremo del cliente y no la totalidad del mismo mensaje. Así pues, nuestra cabecera SOAP contendrá el nombre del fichero y el peso tal y cómo hemos configurado la interficie IService.

El servicio no tiene más, lo que haremos ahora es la implementación de la interface y el código de los métodos que no explicaré ya que son muy básicos, aunque podéis preguntar si tenéis cualquier duda por supuesto y además lo más complejo lo he comentado. Algo simple, dentro de Service.cs tendremos implementados los métodos SubirFichero y DescargarFichero.

El método SubirFichero, recibirá una instancia de la clase Fichero con la información del archivo a subir: su nombre, tamaño y el contenido en un stream de bytes. Este método tendrá un FileStream que va a escribir a disco en una ruta concreta el stream de bytes recibido, o sea, el archivo. Y el método DescargarFichero hará todo lo contrario, recibirá una instancia de la clase PeticionDescarga con el nombre del archivo a obtener y va a crear una instancia de la clase Fichero,es decir, el nombre, su longitud y el contenido en un stream devolviendo esta instancia cómo resultado de la llamada al método.

Hasta aquí todo lo que se refiere al servicio, ya lo tenemos terminado y ahora nos toca hacer la parte de cliente. WCF siempre debe de tener almenos un EndPoint así que a esta aplicación cliente le añadiremos una referencia a un servicio, el que hemos hecho, del que deberemos obtener la URL para saber dónde está hospedado. La podremos ver en la barra de direcciones ejecutando el servicio independientemente. Aunque el servicio este configurado, el cliente tiene total libertad para decidir cómo actuar con el servicio cómo por ejemplo en nuestro caso le estamos indicando que únicamente (como servicio) podremos recibir 1Mb y mediante Streamed. El cliente debe responder con acuerdo a nuestras configuraciones pero por ejemplo puede hacer que el tamaño máximo que se envié al servicio sea de 0,5Mb.

Bien, los parametros a configurar del lado cliente van a ser el maxBufferSize, maxReceivedMessageSize y transferMode. Se debe indicar que el tamaño maximo sea igual o menor que el tamaño que permite el servico (>= 1mb), en caso contrario el servicio lanzará una excepción indicando que no soporta un tamaño superior. Con el último parámetro debemos tener cuidado, debe ser transferMode="StreamedResponse" porqué nuestro servicio espera recibir las cabeceras SOAP en un buffer y recibir la transmisión del mensaje al momento del envío. De esta forma evitamos tener un buffer con miles de bytes debido al gran peso del fichero.

Comentar que las carpetas de subida y descarga se crearan dentro de los proyectos correspondientes. La de subida dentro del App_Code del servicio y la de descarga dentro del bin del cliente.Para obtener el código, que esta adjunto, debeís abrir el archivo MTOM.rar y copiar cada una de las subcarpetas que contiene Projects y WebSites dentro de las carpetas de proyecto de Visual Studio 2008 y abrir la solución Ficheros.sln. Está echo con el Framework 3.5 y c#, como no :)

Espero que no dudéis en preguntar y que os guste el post! Happy code!

[.net] Concurrencia y procesos asíncronos

Francesc Jaumot — Tue, 26 May 2009 18:48:00 GMT

Una de las cosas que más quebraderos de cabeza nos pueden ocasionar a todos nosotros es la concurrencia de usuarios en las aplicaciones que diseñemos. Por suerte, además de conocer los algoritmos más típicos (Panadería, Dekker, Patterson, Productor-Consumidor…), .NET nos facilita bastante la implementación de esta tarea.

Hace pocos días en un diseño técnico de una aplicación Web, el cliente nos plantaba un proceso crítico que tendría la aplicación y que debería ser estable pasase lo que pasase. Además, con una dificultad añadida, el proceso podía durar horas y al finalizar debería mostrar un mensaje al usuario.

Dado esto, encontré la solución más viable para el proceso: trabajar en segundo plano sincrónicamente.

Para ello, deberemos hacer uso de los delegados y de las librerías System.Threading, System.Runtime.Remoting.Messaging y de System.Runtime.CompilerServices.

Como primer paso, además de crear una nueva aplicación de consola en C#, deberemos crear una clase con un delegado:

public class ClassAsyncCallback

{

delegate bool deleg();

}

El segundo paso, es crear los métodos que se van a usar en el proceso síncrono dentro de la clase; uno que llamará a la función que va a realizar el trabajo y otro que será llamado al terminar el primer proceso:

[MethodImpl(MethodImplOptions.Synchronized)]

public bool ProcessCritial()

{

//Ejecutamos el proceso

}

Acordaros de que un delegado es tipo que hace referencia a un método, es decir, el comportamiento del delegado y el método es exactamente el mismo y además, este debe tener la misma firma, valor devuelto, parámetros…que el método.

En este método, aparece algo nuevo, es el atributo declarativo en la declaración del método [MethodImpl(MethodImplOptions.Synchronized)]. Este atributo sirve para indicar que ese método estará sincronizado y que todo lo implementado en él es un proceso crítico. Funciona del mismo modo que la clase Monitor, internamente, declara un semáforo que gestiona la entrada única de un subproceso en él método y pone en espera al resto. Al finalizar, libera el método y deja entrar al siguiente proceso. Así sucesivamente.

El motivo de utilizar este atributo en vez la clase Monitor es muy simple, este atributo bloquea el método hasta que devuelve un valor, que en mi caso es lo que necesitaba, además que Monitor nos condiciona a usar además lock para el bloqueo de una variable para saber si el método esta libre o no y como bien podéis deducir, no es una buena practica.

Bien, ahora solo nos queda crear el método que mostrara el mensaje al usuario:

public void ProcessFinish(IAsyncResult ar)

{

//Mostramos alerta al usuario

}

Como veis, este proceso recibe como parámetro IAsyncResult que nos indica el estado de la operación asíncrona.

Por ahora, nos centraremos en como llamar de forma asíncrona estos métodos des del Main de la aplicación:

static void Main(string[] args)

{

ClassAsyncCallback Mvar = new ClassAsyncCallback();

deleg call = new deleg(Mvar.ProcessCritial);

AsyncCallback cb = new AsyncCallback(Mvar.ProcessFinish);

IAsyncResult ar = call.BeginInvoke(cb, null);

}

Bien, llegados hasta aquí ya tenemos la forma de ejecutar el proceso asíncrono preparado para la concurrencia de usuarios. Como veis, deberemos crear una nueva instancia del delegado declarado anteriormente y pasarle el nombre del método. Con la clase AsyncCallback y pasándole el nombre del método, ya tendremos el objeto que realizara la llamada.

Mediante IAsyncResult y con BeginInvoke, ejecutaremos el proceso asíncrono. Como primer parámetro le pasaremos el método que se debe llamar al finalizar y con el objeto delegado llamaremos el método que debe ser llamado asincrónicamente.

Tal y como hemos dicho, ProcessFinsih es el encargado de mostrar la alerta al usuario según el resultado del método ProcessCrtical. Para recoger el valor devuelto por este dentro de ProcessFinsih, debemos modificar el método de la siguiente forma:

public void ProcessFinish(IAsyncResult ar)

{

deleg resultado = (deleg)((AsyncResult)ar).AsyncDelegate;

if (resultado.EndInvoke(ar))

//Mostramos alerta al usuario

}

Con AsyncDelegate lo que hacemos es recoger el objeto delegado que se ha invocado en la llamada asíncrona y se debe convertir al tipo de delegado declarado por nosotros para poder obtener el resultado de ProcessCrtical; si es true le mostraremos la alerta al usuario.

No es muy complicado ni nada dificultoso, hay que decir que este tipo de problemas es muy típico en bastantes aplicaciones, sobretodo si hay procesos que requieran una gran cantidad de tiempo. Además de solventar un posible problema de concurrencia de usuarios, evitamos que nuestro cliente tenga que esperar x tiempo a que termine este proceso para seguir trabajando con la aplicación por lo que mejoramos el rendimiento de la misma.

Pues nada, a disfrutarlo y ya sabéis… si hay dudas, preguntar.

¡¡Enjoy!!