Francesc Jaumot

¡Domino propio!

2011-08-15T10:34:00Z

¡Muy buenas!

Es lo que tiene el verano y llevaba tiempo con eso en mente, así pues, este año que estoy a tope con las comunidades y con ganas de aprender y crecer más me he creado mi propio dominio www.francescjaumot.net. Estoy en plena migración y reorganización de toda la información que tenía en la red, blogs antiguos, post obsoletos... así que, ¡estoy con todo ello!

Esto no quiere decir que mi blog de geeks quede atrás pero centraré toda mi atención en mi dominio ya que pretendo que sea el principal tanto en actualizaciones como mejoras.Espero que os guste y me deis todo el feedback posible. Cualquier sugerencia siempre es bien recibida

¡Saludos!

[ie9] Jump Lists en la web

2010-09-18T17:45:00Z

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

2010-09-15T16:22:00Z

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

2009-10-25T23:55:00Z

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

2009-09-15T19:31:00Z

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!

[p&p] Smart Client en nuestros desarrollos II

2009-08-04T11:03:00Z

Una vez tengamos el hotfix explicado en la primera entrega, seguimos con el objetivo de ver SCSF y crear una pequeña agenda de contactos, para comenzar deberemos crear un nuevo proyecto:

En VS2008, vamos al menú Archivo y dentro de él Nuevo y por último Proyecto..
En Nuevo proyecto, debemos situarnos en Tipos de Proyecto de Guidance Package y dentro Custom Smart Client Facotry Guidance Package - April 2008 [fixed for SP1]
Seleccionamos Smart Client Application (C#) y aceptamos
Nos aparece un wizard, por defecto debemos des seleccionar Create a separate module to define the layout for the shell y seleccionamos Show Documentation after recipe completes y hacemos click en finalizar.

Nos debería quedar la solución de la siguiente forma:

Comenzaremos explicando cada uno de los proyectos, que son y que sirven. Vemos que tenemos 4 proyectos dentro de la solución: Infrastructure.Interface, Infrastructure.Library, Infrastructure.Module y Shell.

En Infrastructure.Interface, contiene los elementos que deben estar expuestos a otros módulos de la aplicación. En Infraestrucutre.Module, es un componente de interfaz de usuario del módulo que actúa como contenedor para la aplicación de los elementos que se comparten en todos los proyectos de la aplicación cliente. En Infrastructure.Library tenemos la aplicación de componentes comunes utilizados por un conjunto de aplicaciones clientes inteligentes, como por ejemplo, un servicio para recuperar el perfil de un catálogo de servicios Web. Y por último, tenemos el Shell que es el elemento principal de la aplicación que se encarga de la UI y de cargar y ejecutar la aplicación.

Antes de empezar con nada, os voy a explicar la distribución de la user interface y cómo está pensada. Si nos fijamos en el proyecto del Shell, veremos que contiene un ShellForm.cs que no es nada más que la ventana principal de la aplicación. Esta contiene, de arriba hacia abajo, mainMenuStrip que será el menú principal de la aplicación, mainToolStrip que será la barra de herramientas de la aplicación, leftWorkspace que se usa para ubicar el acceso a todos los apartados de la aplicación, rightWorkspace que muestra la información solicitada des de cualquier acción de los elementos citados anteriormente y por último, mainStatusStrip para ubicar los estados de carga de ventanas, una barra de progreso... Aunque parezca sencillo, es básico saber ubicar cada elemento en su sitio para que nos quede una user interface más amigable y usable para facilitar el trabajo al usuario final.

Cómo la idea de SCSF es crear la aplicación por módulos, básicamente para que equipos grandes de desarrollo puedan trabajar de forma simultánea sobre el mismo proyecto, lo primero que haremos será añadir un módulo de negocio a nuestro proyecto, para ello añadimos una nueva carpeta dentro de source que se llame Modulos, esto es opcional y es solamente para una mejor organización de nuestro proyecto, y haremos click con el botón derecho en la nueva carpeta y en el submenu de Smart Client Factory añadiremos "Add Business Module C#" con el nombre ModuleContactos desmarcando la opción de "Create an interface library for this module" quedando así la estructura del proyecto:

Es importante leer las definiciones explicadas en la primera parte para entender los diferentes conceptos que voy a explicar. Cuándo hemos creado el modulo, además de una serie de carpetas que trataremos más adelante, podremos ver que nos ha creado dos clases.

La primera de ellas es el Module que hereda siempre de ModuleInit y será el encargado de gestionar el modulo. En el método Load podemos ver cómo crea un WorkItem que será el encargado de guiar a todo nuestro módulo y siempre tendremos uno de diferente para cada modulo creado. Y la segunda de ellas, el ModuleController que contiene los métodos necesarios para personalizar el comportamiento de nuestro modulo durante la ejecución, como por ejemplo, los menús.

Antes de seguir con nuestro modulo, hay un archivo muy importante dentro del proyecto Shell a tener en cuenta, este es el ProfileCatalog.xml que si lo editáis podréis ver que ha añadido una sección en Modules con un archivo con el nombre de nuestro modulo, así <ModuleInfo AssemblyFile="SmartClientDevelopmentSolution.ModuleContactos.dll" />. En SCSF cuándo se ejecuta nuestra solución, este va a consultar a este fichero para saber que módulos se deben inicializar que son los que van a ser usados en nuestra aplicación.

Seguimos con el modulo. La mayoría de aplicaciones basadas en Windows hacen uso de elementos de la interfaz de usuario común a través de una aplicación. Aunque shell es la que realmente contiene los menús, WorkSpace, se pueden crear instancias y acceder a estas propiedades des de nuestros módulos para adaptar la interfaz tal y como necesitemos.

Vamos a poner un menú para nuestro modulo. Nos situamos en ModuleController.cs en el método, ExtendMenu() y en él, con la clase ToolStripMenuItem crearemos el elemento principal de nuestro menú y los elementos hijos. Para ello, usaremos el constructor de la clase indicando el nombre del menú y opcionalmente el icono que se visualizará. CAB (Composite UI Application Block) tiene una gestión propia para los eventos de nuestros menús. Antes de poder gestionar estos eventos, si nos ubicamos en el directorio Constants de ModuleContactos en UIExtensionSiteNames.cs y vemos la definición (Ir a definición...) de la clase que hereda, veremos que este contiene varios ficheros con constantes que únicamente son textos,

public const string MainMenu = "MainMenu";
public const string MainToolbar = "MainToolbar";
public const string MainStatus = "MainStatus";

Esto es porqué CAB usa esas constantes para saber en qué barra de menú estamos usando o queremos usar. Hay varios archivos de constantes, UIExtensionSiteNames.cs contiene los elementos de la pantalla principal para que puedan ser extendidos, CommandNames.cs contiene los nombres de los eventos que vamos a necesitar en nuestro módulo, WorkspaceNames.cs contiene los espacios dónde vamos a ubicar nuestras vistas y EventTopicNames.cs que contiene los eventos comunes que suceden en la pantalla principal, como por ejemplo, actualizar la barra de estado. Si volvemos a nuestro método, ExtendMenu(), añadiremos un menú principal para el módulo y dos ítems más, nuestro código va a quedar así:

ToolStripMenuItem rootMenuItem;
ToolStripMenuItem itemGestContactos;
ToolStripMenuItem itemBuscContactos;

//Item principal
rootMenuItem = new ToolStripMenuItem("Contactos", (Bitmap)recursos.ResourceManager.GetObject("book_open"));
//Items hijos
itemGestContactos = new ToolStripMenuItem("Gestión contactos",(Bitmap)recursos.ResourceManager.GetObject("group"));
rootMenuItem.DropDownItems.Add(itemGestContactos);
itemBuscContactos = new ToolStripMenuItem("Buscar", (Bitmap)recursos.ResourceManager.GetObject("folder_find"));
rootMenuItem.DropDownItems.Add(itemBuscContactos);

Una vez tenemos el menú principal y también sus elementos hijos, debemos indicar a CAB dónde se va a ubicar dicho menú. Tal y cómo he dicho anteriormente, siempre nos maneja un WorkItem el cual nos proporciona el objeto necesario del Shell para modificar su presentación.

WorkItem.UIExtensionSites[UIExtensionSiteNames.MainMenu].Add(rootMenuItem);

A través del WorkItem principal del módulo accedemos a la propiedad UIExtensionSites dónde le indicaremos (fijaos que lo hacemos con la constante) el menú del Shell dónde se añadirá el nuevo elemento. En este caso le pasamos el rootMenuItem con dos items hijos para que nos quede un menú cómo este:

Cómo tendremos eventos propios, lo que haremos es ubicarnos en el directorio Constants en CommandNames.cs y añadiremos dos nuevas constantes, una para gestionar el click de "Gestión contactos" y otra para gestionar el "Buscar":

public const string gestContactos = "GestionContactos";
public const string buscContactos = "BuscarContactos";

¿Y ahora cómo hacemos la relación con el item del menú y evento? Muy fácil. Seguimos dentro del método ExtendMenu() y añadiremos estas dos líneas de código. Fijaos que ahora hemos accedido a la propiedad Commands y con las constantes creadas anteriormente, le hemos indicado que hemos añadido a esos elementos un evento. Saber que "Click" o el nombre del evento que sea es case sensitive, o sea, que "click" no sirve y da lugar a error. Os recomiendo que os creéis una clase en el directorio Constants de Interface para la gestión correcta de los eventos ya que los usareis en toda la aplicación.

WorkItem.Commands[CommandNames.gestContactos].AddInvoker(itemGestContactos, "Click");
WorkItem.Commands[CommandNames.buscContactos].AddInvoker(itemBuscContactos, "Click");

Ahora, solo nos queda un paso. Indicar a CAB la acción que debe realizar cuándo el itemGestContactos invoque el evento click. Nada complejo, nos debemos crear un método público que devuelva vacío y en la firma del método indicar que es un manejador, por ejemplo, para la constante gestContactos:

[CommandHandler(CommandNames.gestContactos)]
public void gestContactos(object sender, EventArgs e)
{
//Código de las acciones
}

Por defecto y al estar indicado en el ProfileCatalog, al cargarse nuestro módulo, en el método Run() se llama al método ExtendMenu() para que inicialice la Shell adaptada para cada uno de nuestros desarrollos. Hará lo mismo para la ToolStrip que usará ToolStripButton para añadir botones en la barra de herramientas.

En la entrega III seguiremos con la gestión de los menus y introduciremos ya las vistas.
Enjoy ;)

[.net] Concurrencia y procesos asíncronos

2009-05-26T18:48:00Z

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!!

[p&p] Smart Client en nuestros desarrollos

2009-04-21T07:34:00Z

¡Buenos días!

Como muchos ya sabéis, Microsoft dentro de su MSDN tiene un departamento de arquitectura, Microsoft Patterns and Practices (p&p), que ofrecen a los desarrolladores (nosotros) buenas prácticas para obtener una solución de la forma más eficiente para nuestro día a día y además aplicando de una forma práctica patrones para una solución común de nuestros problemas del día a día. En p&p existen proyectos como Enterprise Library, Web Client Software Factory... y la que voy a tratar ahora, Smart Client Software Factory (SCSF).

SCSF, nos propone una alternativa a la forma de trabajo de winforms. De forma diaria, cuando se desarrolla un aplicación para él desktop creamos nuestra solución con un proyecto para la interface de usuario (UI), para nuestra lógica de negocio (BL) y para el acceso a datos (DAL). En nuestro proyecto de UI tendremos el winforms con "n" elementos en el formulario (MeForm.cs) y cada uno tendrá su code behind dónde implementaremos, por ejemplo, el evento button_Click de nuestro botón del formulario que llamará a BL y esta a DAL.

Con SCSF, además de aplicar buenas prácticas de una forma fácil en nuestros clientes complejos desktop basado en Composite UI Application Block (CAB), obtenemos una arquitectura de nuestra aplicación más usable, más universal y con más facilidad de mantener; podemos decir que nos ayuda en el ciclo de vida de nuestra aplicación. SCSF, usa y se basa principalmente en Composite UI Application Block y para ello debemos introducir una série de definiciones algo complejas.

WorkItem: es un contenedor para el manejo de de objetos, que son necesarios para el cumplimiento de una tarea determinada. Tales objetos son objetos de estado, vista y sus presentadores, o comandos para lanzar una acción. En resumen, es una clase que resume la lógica de un caso de uso que conoce todos los diferentes aspectos.
Service: Un servicio encapsula la funcionalidad que es común para toda la aplicación cliente, por un módulo específico, o simplemente WorkItems.
Module: Múltiples WorkItems pueden resumirse en una sola unidad de despliegue. CAB trabaja básicamente a nivel de módulos por lo tanto encontrar la forma de encapsular los WorkItems en los módulos es fundamental.
ProfileCatalog: es sólo la configuración que especifica que los módulos y los servicios tienen que ser cargados en la solicitud. Es un archivo XML que reside en el directorio de aplicación.
ModuleLoader: Se trata un servicio general CAB, que es responsable de cargar todos los módulos descritos en un catálogo de peril.
ModuleInt: Cada módulo tiene una clase ModuleInt que se encarga de cargar todos los servicios y WorkItems de un módulo. Además también es responsable de la interfaz de usuario.
Command: es una clase de CAB que aplica el patrón Command, de forma resumida, CAB encapsula este patrón [CommandHandler] como atributo de módulo que permite llamar a una operación de un objeto sin saber cúal el contenido de la operación ni el receptor de la misma.
Shell Application: La aplicación de Shell es la principal que se encarga de inicializar la aplicación. Es la responsable de la carga dinámica de módulos y de la puesta en marcha de los servicios para la aplicación cliente inteligente, además de iniciar el formulario principal, el Shell.
Shell: Proporciona la interfaz de usuario que es común a todos los módulos de carga dinámica. La Shell sioempre contiene el WorkItem principal, servicios, módulos y el registro de los mismos.
Workspace: es un control que es el principal responsable para mostrar elmentos de la interfaz de usuario creados por los WorkItems. El WorkItem se añade al Shell y actúa como contenedor de la interfaz de usuario proporcionada por WorkItems. Si queremos que un control de usuario sea un workspace, solo debemos implementar la interfaz IWorkspace.
UIExtensionSite: son marcadores de posición especiales para la amplicación de partes fijas del Shell, tales como los menús, barras de herramientas... Se diferencián de los workspace por que estos están destinados a ser utilizados por todas las partes de la interfaz de usuario que no deben ser anuladas por los WorkItems, si no que deben ser ampliadas. Por ejemplo, podemos hacer un override del método principal de creación de menús y a parte de los base podemos añadir otra opción necesaria para ese WorkItem.
EventBrokers: Hay dos, EventPublication y EventSubscription. El primero de ellos se lleva a cabo a través de .NET Framework marcando los eventos con el atributo [EventPublication] y el segundo, para cualquier clase que quiera suscribirse a un evento tiene que aplicar un manejador de evento que conicida con el la firma del método del evento publicado y debe marcar este evento con [EventSubscription].
View: Es un control de usuario que se encarga de presentar una parte o todo el modelo para el usuario y permite al usuario modificar su contenido a través de una interfaz de usuario. La vista sólo implementa la interfaz de usuario lógica y las relaciones con la lógica de negocio recaén en el presenter.
SmartPart: es un control de usuario con el atributo [SmartPart] aplicado dejando de forma opcional la implementación de ISmartPartInfoProvider que proporciona información adicional acerca de sí misma, como un título o una descripción.
Presenter: Es una clase que implementa la lógica de modificación de un modelo. Cada módulo, tiene su presenter y una presenter puede usarse des de varias vistas.
ObjectBuilder: Componente fundamental de CAB, que actúa como una fábrica para crear objetos específicos que requieren un constrictor o que necesitan funciones específicas, como la instanciación automática y que depende de la inicialización de objetos al crear instancias.
DependencyInjection: Es un patrón que permite a una fábrica crear automáticamente o inicializar las propiedades o los miembros de objetos con objetos de su cargo. ObjectBuilder le proporciona esta funcionalidad y sus dependencias vendrán descritas en un fichero de configuración.
Bussiness Module: Módulos de negocio, esencialmente proyectos DLL que contienen una unidad del negocio junto con sus vistas. Cada módulo de negocio, contiene un WorkItemController principal.
Foundation Module: No contiene ni vistas ni WorkItems. Se utilizan para contener servicios globales que se usan en todos los módulos como por ejemplo Acceso a Datos, Logging, Seguridad...
Ambos, Bussiness y Foundation Module, contienen una clase Module que hereda de ModuleInit con un método Load para que CAB los pueda cargar.

Principalmente, SCSF, utiliza el patrón Modelo - Vista - Presentador (MVP) entre otros. Una vista (View), gestiona los controles en el formulario y cede la responsabilidad de la lógica de la UI al presentador a través de los eventos del cliente. El presentador (presenter), contiene la lógica capaz de responder estos eventos y gestiona el estado de la vista a través del modelo (Module) que tiene las entidades empresariales (datos). El presentador, no hace una referencia directa de la vista, si no que hace referencia a una interfaz para la vista (IView) que se encarga de los cambios de estado.

¿Y porqué trabajar de este modo? Como tenemos separado la UI de la lógica de la pantalla, podemos portar la aplicación a diferentes tipos de presentación sea WebClient, WPF Client, Silverlight Client... y además este modelo nos permite probar todo el funcionamiento de la pantalla sin tener UI, solo haciendo pruebas sobre el presentador.

Veremos poco a poco nuevos conceptos que iremos aprendiendo a lo largo de las diferentes entregas. Para empezar debereís instalar el smart client software factory dónde en el enlaze viene muy bien explicado. Ahora se debe actualizar, esto se debe a que para que os compile, se debía modificar el proyecto... Lo teneís aquí, y aunque no es oficial, funciona perfectamente aplicando los cambios recomendados por Microsoft.

Hasta aquí la teoría. Ahora, nos toca la parte más divertida, pero, será en la segunda entrega dónde usemos lo anterior en un proyecto real.
Espero vuestras dudas o comentarios ;)

Mi comienzo en Geeks·ms

2009-04-20T11:35:00Z

Con este post doy comienzo a mi andadura por esta gran família de Geeks·ms. Me siento muy contento de poder contar con un blog aquí y espero poder estar a la altura porqué con el nivel de los bloggers que hay aquí será todo un reto! Gracias a Rodrigo Corral por darme la oportunidad!