VEMN Team Blog

Introducción: tipos de entidades en Entity Framework

Desde la salida de Entity Framework, al generar modelos de entidades, las clases generadas derivan de EntityObject.
Con la salida de la versión 4 de Entity Framework, se incorpora soporte para seleccionar el tipo de entidad de la cual van a derivar nuestras entidades de negocio: a los clásicos EntityObject se agregan como novedad POCO, POCO Proxies y Self-Tracking entities.
Antes de desarrollar las entidades de tipo Self-Tracking (el objetivo de este artículo), es conveniente dar un panorama de estos diferentes tipos de entidades, para poder decidir cual utilizar, dependiendo de la arquitectura de la aplicación a realizar:

• EntityObject

Por defecto, las herramientas de ADO.NET Entity Data Model generan tipos de entidades que derivan de EntityObject. En este caso, el ObjectContext administra las relaciones entre los objetos, mantiene el historial de los cambios que ocurren (Change-Tracking) y soporta Lazy Loading.

Sin embargo, este tipo de entidades dependen fuertemente del Entity Framework. Si se desea trabajar con arquitecturas que no conocen la forma de persistencia (por ejemplo: TDD, Test-Driven Development), lo más deseable es utilizar entidades de tipo POCO o POCO Proxy.

• POCO

Entity Framework permite utilizar objetos del dominio existentes junto con el modelo de datos, sin hacer cambios a las clases de datos. Estas clases POCO ("Plain-Old" CLR Objects), son conocidas como objetos que ignoran la persistencia y soportan las mismas funcionalidades de Query, Insert, Update y Delete que los objetos EntityObject.

Al trabajar con entidades POCO, los cambios que se realicen al grafo de objetos no son mantenidos automáticamente por Entity Framework a medida que ocurren, sino que se utiliza un mecanismo de snapshots para detectarlos: se debe llamar a DetectChanges para sincronizar el ObjectContext con el grafo actualizado (por defecto, el ObjectContext llama a este método antes de grabar los datos).

Este mecanismo utiliza mas memoria que el anterior y puede afectar la performance, especialmente si la aplicación requiere la detección de cambios frecuentemente. Para poder tener una notificación instantánea de los cambios, se debe activar la creación de objetos Change-Tracking Proxy, y para activar Lazy Loading se debe activar la creación de Proxies de Lazy Loading.

• POCO Proxy

Se debe utilizar en los casos en los que se requiera detección de cambios instantánea y Lazy Loading. Al utilizarlo, se tiene la misma funcionalidad que con entidades tipo EntityObject, pero con las clases del dominio separadas del Entity Framework. Los proxies se crean en tiempo de ejecución, lo que implica que las entidades generadas difieren del tipo POCO, introduciendo algunas complicaciones con la serialización. Por otra parte, la creación de proxies consume mas recursos que los objetos POCO.

• Self-Tracking Entities

Los tres tipos definidos anteriormente funcionan correctamente en aplicaciones donde los objetos pueden ser agregados (Attach) al ObjectContext que maneja el historial de cambios. Sin embargo, cuando se desea transferir un grafo de entidades a una capa donde el ObjectContext no está disponible, se debe decidir como mantener el historial de cambios y reportar esos cambios de vuelta al ObjectContext (por ejemplo: arquitectura en capas, ambientes desconectados, arquitecturas SOA, etc.).

A partir de la versión 4 de Entity Framework, las entidades del tipo Self-Tracking pueden grabar cambios a las propiedades escalares, complejas o de navegación. Este tipo de entidades no dependen del Entity Framework, y son generadas con el template de ADO.NET Self-Tracking Entity Generator.

Self-Tracking Entities

En arquitecturas en capas, el ObjectContext puede no estar disponible en la capa que modifica las entidades. A partir de Visual Studio 2010 (con Entity Framework 4), está disponible el template ADO.NET Self-Tracking Entity Generator. Este template genera dos archivos .tt (text template):

El archivo <nombreModelo>.tt genera los tipos de entidades y una clase helper que contiene la lógica de mantenimiento de cambios, mas los métodos de extensión que permiten establecer el estado de las entidades.

El archivo <nombreModelo>.Context.tt genera un ObjectContext tipado y una clase de extensión que contiene los métodos ApplyChanges para las clases ObjectContext y ObjectSet. Estos métodos examinan la información del historial de cambios para inferir las operaciones a realizar para grabar los cambios en la base de datos.

Para acceder al template se debe hacer click derecho sobre la superficie del diseñador de entidades, y seleccionar “Add Code Generation Item”:

En la ventana que aparece, seleccionar “ADO.NET Self-Tracking Entity Generator”:

Al presionar “Add”, se ejecutarán los templates que crearán las clases necesarias, las cuales contendrán los métodos de extensión necesarios para trabajar con Self-Tracking:

Métodos de extensión de Self-Tracking Entities

• StartTracking

Este método se utiliza para comenzar el Change-Tracking (rastrear cualquier cambio que ocurra en la entidad). Esto incluye propiedades escalares, colecciones y referencias a otras entidades. Las entidades de tipo Self-Tracking inician el Change-Tracking automáticamente cuando son deserializadas en un cliente a través de WCF. También se activa para nuevas entidades creadas en los siguientes escenarios:

1. Una relación es creada entre la nueva entidad y una entidad que actualmente tiene Change-Tracking activado.
2. Se llama al método MarkAs o AcceptChanges en una entidad.

• StopTracking

Este método finaliza el Change-Tracking en una entidad.

• MarkAs

Todos los métodos que comienzan con “MarkAs” activan el Change-Tracking. Estos métodos permiten cambiar el estado de una entidad a Added, Modified, Deleted, o Unchanged, y además retornan la misma entidad a la cual son aplicados, con el estado modificado:

MarkAsAdded cambia el estado de una entidad a Added. Las nuevas entidades Self-Tracking son creadas en este estado y con Change-Tracking desactivado.

MarkAsDeleted cambia el estado de una entidad a Deleted.

MarkAsModified cambia el estado de una entidad a Modified. Este estado también se obtiene al cambiar el valor de una propiedad en una entidad con Change-Tracking activado.

MarkAsUnchanged cambia el estado de una entidad a Unchanged. También se obtiene este estado al llamar al método AcceptChanges.

• AcceptChanges

Este método elimina la información de Change-Tracking para una entidad y coloca el estado en Unchanged (es decir, la entidad acepta los cambios que se le realizaron).

Métodos de extensión de ObjectContext

• ApplyChanges

Examina la información del historial de cambios contenida en el grafo de entidades e infiere el conjunto de operaciones que deben realizarse para reflejar los cambios en la base de datos. Hay dos métodos ApplyChanges, uno para el ObjectContext y otro para el ObjectSet.

Consideraciones para trabajar con entidades Self-Tracking

Finalmente, para cerrar, les dejo algunas consideraciones a tener muy en cuenta antes de utilizar este tipo de entidades:

• Al enviar un grafo modificado a un servicio, y luego intentar continuar trabajando con el el grafo modificado en el cliente, se debe iterar manualmente por el grafo en el cliente y llamar a AcceptChanges en cada objeto para resetear el Change-Tracking.

• Las entidades Self-Tracking no permiten realizar Lazy Loading.

• La serialización Binaria y la serialización a objetos de administración de estados ASP.NET no es soportada por el código generado por los templates de ADO.NET Self-Tracking Entity Generator, para soportala se debe agregar el código necesario al template.

Fuentes:

• http://msdn.microsoft.com/en-us/library/bb738470.aspx
• http://msdn.microsoft.com/en-us/library/ff407090.aspx
• http://msdn.microsoft.com/en-us/library/ee789839.aspx

ADO.NET, Entity Framework, Visual Studio ado.net, ef

Si deseamos que nuestro software siga beneficiándose de las capacidades futuras de hoy y mañana de los procesadores debemos empezar a cambiar nuestra manera de desarrollar. La razón de esto es que las aplicaciones de negocio van tener que ejecutarse en máquinas multi-core o con varios procesadores. Hasta hace pocos años una máquina con varios procesadores estaba prácticamente reservada a la supercomputación, pero hoy en día ya son comunes en cualquier PC de escritorio.

La programación concurrente y el paralelismo no son una materia trivial, la sincronización entre procesos no lo es y dividir el trabajo, asignarlo a varios procesadores, recoger los resultados y mezclarlos para reconstruir la solución final tampoco.

En el pasado, la paralelización requería manipulación de bajo nivel de los subprocesos y bloqueos. Hoy en día, los desarrolladores no tendrían que luchar contra esta complejidad, porque sería dar un paso atrás en productividad. Su tarea es seguir dedicando sus esfuerzos a lo que mejor saben hacer que es desarrollar aplicaciones de alto nivel que resuelven problemas de negocio sin controlar la ejecución concurrente de sus procesos.

Para ello, debemos acostumbrarnos a usar el término task en lugar del thread como seguramente la mayoría de nosotros veníamos haciendo y aprovechar las nuevas capacidades que ofrece las APIs de .NET Framework 4, así como también las del Visual Studio 2010.

.NET Framework 4, proporciona un nuevo runtime, nuevos tipos de biblioteca de clases y nuevas herramientas de diagnóstico para la programación paralela y concurrente. Es aquí donde hace su aparición Parallel Extensions, simplificando el desarrollo en paralelo, de modo de poder escribir código paralelo eficaz, específico y escalable de forma natural sin tener que trabajar directamente con subprocesos. Sin embargo, no todo código se presta para la paralelización por ejemplo, si un bucle realiza solo una cantidad reducida de trabajo en cada iteración o no se ejecuta para un gran número de iteraciones, la sobrecarga de la paralelización puede dar lugar a una ejecución más lenta del código. Además, al igual que cualquier código multiproceso, la paralelización hace que la ejecución del programa sea más compleja.

Parallel Extensions se compone de dos partes: Parallel Linq (PLINQ) y Task Parallel Library (TPL). También consta de un conjunto de estructuras de datos de coordinación (CDS) utilizada para sincronizar y coordinar la ejecución de tareas concurrentes. La siguiente ilustración proporciona información general de alto nivel de la arquitectura de programación paralela en .NET Framework 4.

A continuación explicaré cada uno de sus componentes. PLINQ implementa el conjunto completo de operadores de consulta estándar de LINQ  e incluye otros adicionales para las operaciones paralelas. Combina la simplicidad y legibilidad de la sintaxis de LINQ con la eficacia de la programación paralela. En muchos escenarios, PLINQ puede aumentar significativamente la velocidad de las consultas LINQ  to Objects utilizando todos los núcleos disponibles en el equipo host de una forma más eficaz. Para hacer esto divide el origen de datos en segmentos y, a continuación, ejecuta la consulta en cada segmento en subprocesos de trabajo independientes en paralelo en varios procesadores. La clase System.Linq.ParallelEnumerable expone casi toda la funcionalidad de PLINQ.  Les mostraré un ejemplo en el que invoco el método de extensión ParallelEnumerableAsParallel() para indicarle que la query debe ejecutarse en forma paralela.

for (var i = 0; i < data.Length; i++)

{

    data[i] = i;

}

data[1000] = -1;

data[14000] = -2;

data[15000] = -3;

data[676000] = -4;

data[8024540] = -5;

data[9908000] = -6;

var negativos = from valor in data.AsParallel()

                where valor < 0

                select valor;

Al ejecutarse la query en paralelo los resultados de cada subproceso de trabajo deben volver a combinarse en el subproceso principal por ejemplo para la inserción en una lista. El tipo de combinación que  PLINQ realiza depende de los operadores que se encuentran en la consulta. Con el método WithParallelMergeOptions(), puede indicarse a PLINQ una sugerencia de que tipo de combinación se va a realizar.

La biblioteca TPL es un conjunto de API que tiene como propósito lograr que los desarrolladores aumenten la productividad simplificando el proceso de agregar paralelismo y simultaneidad a las aplicaciones, utilizando eficazmente todos los procesadores que están disponibles. Además, se encarga de la división del trabajo, la programación de los subprocesos y otros detalles de bajo nivel.

El concepto principal de Parallel Extensions es una tarea, que es una pequeña unidad de código, de forma independiente. Se encarga de dividir el trabajo y lanzar un número óptimo de threads basándose en el número de CPUs o cores que tenemos.

Yendo aun mas allá, sin llegar al nivel de granularidad de una task, podemos trabajar a más alto nivel aún con la clase estática Parallel y escribir código como el siguiente:

static void Main()

{

    Parallel.For(from, to, i=> )

    {

    });

}

Mediante un ciclo como el anterior, dejamos que el runtime de Parallel Extensions se encargue de paralelizar el trabajo creando las tasks y encargándose de  todo el proceso. A continuación les mostraré las mejoras de rendimiento al paralelizar un programa muy sencillo. El método SumaRaicesNesimaDeX devuelve la suma de las raíces n-énesima de todos los enteros entre 1 y un 10 millones donde n es una variable recibida como parámetro. La forma de resolución de la raíz contiene pasos de procesamiento adicionales que aumentan el tiempo de ejecución total de la consulta. Además, en el main utilizo la clase Stopwatch para determinar cuantos milisegundos tarda el programa en ejecutarse.

static void Main()

{

    var tiempo = Stopwatch.StartNew();

    for (var i = 2; i < 20; i++)

    {

        var resultado = SumaRaicesNesimaDeX(i);

        Console.WriteLine("Raiz {0} = {1} ", i, resultado);

    }

    Console.WriteLine(tiempo.ElapsedMilliseconds);

    Console.ReadLine();

}

public static double SumaRaicesNesimaDeX(int n)

{

    double resultado = 0;

    for (var x = 1; x < 10000000; x++)

    {

        //Raíz n-ésima de x

        resultado += Math.Exp(Math.Log(x) / n);

    }

    return resultado;

}

El programa lo ejecute en AMD Phenom II X4 810 de 64 bits con 4 GB de memoria RAM y tardó aproximadamente 16 segundos.

Ahora si remplazo el ciclo:

for (var i = 2; i < 20; i++)

{

    var resultado = SumaRaicesNesimaDeX(i);

    Console.WriteLine("Raiz {0} = {1} ", i, resultado);

}

por el siguiente código añadiéndole paralelismo:

Parallel.For(2, 20, (i) =>

{

    var resultado = SumaRaicesNesimaDeX(i);

    Console.WriteLine("Raiz {0} = {1} ", i, resultado);

});

Mediante pequeñas modificaciones del código como son un índice de inicio y de fin y la llamada a través de un delegate, la ejecución del programa solo tarda aproximadamente 4 segundos y medio.

Visual Studio 2010 incluye nuevas herramientas de profiling y debugging para la ejecución concurrente. Un ejemplo de esto es el visualizador de concurrencia. Esta herramienta ayuda  a analizar nuestras aplicaciones secuenciales para descubrir las oportunidades de paralelismo. El visualizador de concurrencia incluye visualización y herramientas de reporte. Hay tres puntos de vista principales: utilización de CPU, subprocesos y núcleos.

El eje X muestra el tiempo transcurrido desde el inicio de la traza hasta el final de la actividad de la aplicación. El eje Y muestra el número de núcleos de procesadores lógicos en el sistema. La zona verde representa el número medio de cores lógicos que se analiza en la aplicación en un momento dado en la ejecución del profiling. El resto de los núcleos por otros procesos que se ejecutan en el sistema (que se muestra en amarillo).

Si queremos paralelizar nuestra aplicación, debemos buscar áreas de ejecución que presentan largas regiones verdes a nivel de un solo núcleo en el eje Y o regiones donde no hay mucha utilización de la CPU, donde el verde no demuestra ni es considerablemente menos de 1 en promedio. Ambas circunstancias podrían indicar una oportunidad para la paralelización. En segundo lugar, si estamos tratando de afinar la aplicación paralela, esta vista le permite confirmar el grado de paralelismo que existe cuando la aplicación se ejecuta.

Este cambio de paradigma nos exige una nueva manera de pensar. Los threads son una abstracción demasiado débil. Debemos empezar a pensar en tareas no en threads y en relaciones entre esas tareas y su concurrencia en lugar de sincronización de threads. Seremos los desarrolladores quienes de un modo u otro tendremos que empezar a pensar en paralelización.

.NET, Entity Framework, Visual Studio

Hola a todos, quiero recordarles que este 21 de Abril será el evento virtual de lanzamiento de 11 importantes productos y donde muchos MVPs estaran como speakers y como expertos para resolver tus dudas.

Regístrate ya!

.NET, ASP.NET, Entity Framework, General, Sharepoint, Visual Studio

Siempre es motivo de preguntas el tema de que trae cada versión de Visual Studio y cuanto cuesta cada una de ellas. Aqui les dejo un link donde ver una matriz con las comparaciones de cada versión de Visual Studio 2010.

Visual Studio visual studio

Una de las cosas mas intersantes que tiene el diseñador del EF en Visual Studio 2010 es la posiblidad de extender las funcionalidades mediante el agregado de nuevas propiedades a una entidad, o la posibilidad de poder interceptar el momento de grabar un archivo edmx, u otras opciones mas.

Esto es muy útil para cuando hay equipos de desarrollo extendidos, o varios proveedores diferentes trabajando en una empresa  y se quiere mantener una uniformidad al momento de escribir código.

Asi que mediante un ejemplo sencillo explicaremos los pasos necesarios para poder implementar una propiedad en las entidades que nos permita definir si una entidad es auditada o no.

Mostraremos como agregar esa propiedad y como utilizarla posteriomente en nuestro código.

Aclaración: todo lo mostrado en este artículo, está realizado sobre la RC de VS2010.

Como paso siguiente, manos a la obra!!

El equipo de ADO.NET publicó en CodePlex el ADO.NET Entity Data Model Designer Extension Starter Kit que nos permite hacer mucho mas fácil la tarea, y ya tiene varias opciones configuradas por default.

Podemos por ejemplo: 

• • • Que el ADO.NET Entity Data Model Wizard agregue anotaciones personalizadas en cada tipo de entidad. El fundamento del tema lo encontramos en un ar tículo del blog de ADO.NET referido a diseño en http://blogs.msdn.com/efdesign/archive/2008/08/12/structural-annotations-one-pager.aspx (en inglés)
    • Que el ADO.NET Entity Data Model Wizard agregue anotaciones personalizadas durante las actualizaciones en cada entidad que se agregue al modelo conceptual.
    • Que el ADO.NET Entity Data Model Wizard agregue anotaciones personalizadas cuando las entidades son seleccionadas en el Designer o en el Model Browser.
    • También se puede extender el modo en se que cargan y graban los archivos .admx.
    • O permitir que el Diseñador grabe o carge archivos en un formato personalizado.

Paso 1: Instalar la extensión que se baja desde CodePlex

Paso 2: Crear el proyecto.

Paso 3: Una vez que tenemos el proyecto creado, podemos hacer las modificaciones que nos interesan. En este caso vamos a crear una propiedad para cada Entidad que nos permita habilitar o deshabilitar la auditoría. Creamos entonces una clase AuditarProperty:

using System;

using System.Linq;

using System.Xml.Linq;

using System.ComponentModel;

using Microsoft.Data.Entity.Design.Extensibility;

namespace EFEjemploExtension

{

    /// <summary>

    /// </summary>

    class AuditarProperty

    {

        internal static readonly string _namespace = "http://schemas.vemn.com/EFExtensions";

        internal static XName _xnMyNamespace = XName.Get("AuditarProperty", _namespace);

        internal const string _category = "Extensiones";

        private XElement _parent;

        private PropertyExtensionContext _context;

        public AuditarProperty(XElement parent, PropertyExtensionContext context)

        {

            _context = context;

            _parent = parent;

        }

        // Esta propiedad This property is saved in the conceptual content of an .edmx document in the following format:

        // <EntityType>

        //  <!-- other entity properties -->

        //  <MyNewProperty xmlns="http://schemas.vemn.com/MyNewProperty">True</MyNewProperty>

        // </EntityType>

        [DisplayName("Auditar Entidad")]

        [Description("Configura si la entidad es Auditable")]

        [Category(AuditarProperty._category)]

        [DefaultValue(false)]

        public bool AuditarEntidad

        {

            get

            {

                bool propertyValue = false;

                if (_parent.HasElements)

                {

                    XElement lastChild = _parent.Elements().Where<XElement>(element => element != null && element.Name == AuditarProperty._xnMyNamespace).LastOrDefault();

                    if (lastChild != null)

                    {

                        bool boolValue = false;

                        if (Boolean.TryParse(lastChild.Value.Trim(), out boolValue))

                        {

                            propertyValue = boolValue;

                        }

                    }

                }

                return propertyValue;

            }

            set

            {

                bool propertyValue = value;

                using (EntityDesignerChangeScope scope = _context.CreateChangeScope("Set AuditarEntidad"))

                {

                    if (_parent.HasElements)

                    {

                        XElement lastChild = _parent.Elements().Where<XElement>(element => element != null && element.Name == AuditarProperty._xnMyNamespace).LastOrDefault();

                        if (lastChild != null)

                        {

                            lastChild.SetValue(propertyValue.ToString());

                        }

                        else

                        {

                            _parent.Elements().Last().AddAfterSelf(new XElement(_xnMyNamespace, propertyValue.ToString()));

                        }

                    }

                    else

                    {

                        _parent.Add(new XElement(_xnMyNamespace, propertyValue.ToString()));

                    }

  scope.Complete();

                }

            }

        }

    }

}

Paso 4: Creamos el Factory.

using System.Xml.Linq;

using System.ComponentModel.Composition;

using Microsoft.Data.Entity.Design.Extensibility;

namespace EFEjemploExtension

{

    [PartCreationPolicy(CreationPolicy.Shared)]

    [Export(typeof(IEntityDesignerExtendedProperty))]

    [EntityDesignerExtendedProperty(EntityDesignerSelection.ConceptualModelEntityType)]

    class AuditarPropertyFactory : IEntityDesignerExtendedProperty

    {

        /// <summary>

        /// </summary>

        /// <param name="element"></param>

        /// <param name="context"></param>

        /// <returns></returns>

        public object CreateProperty(XElement element, PropertyExtensionContext context)

        {

            return new AuditarProperty(element, context);

        }

    }

}

Paso 5: Una vez que hemos terminado, se compila y queda el arc hivo .vsix para ser in stalado en Visual Studio. En el Extension Manager veremos algo asi:

>

Paso 6: Ya tenemos diponible la propiedad en el Diseñador de EF. Cuando agreguemos nuevas tablas o cuando se haga una actualización, las entidades tendrán ahora una nueva propiedad. Si seleccionamos una entidad veremos algo como:

 Paso 7: Por último, unos extension methods para poder consultar la Metadata del modelo que  nos permita obtener el valor de la propiedad:

public static class EFExtension

{

    /// <summary>

    /// Retorna el valor de una propiedad generada en la extensión del Diseñador del Entity Framework

    /// </summary>

    /// <typeparam name="T">Entidad para obtener la propiedad</typeparam>

    /// <param name="workspace"></param>

    /// <param name="propertyName">Ejemplo: http://schemas.vemn.com/EFExtensions:AuditarProperty</param>

    /// <returns></returns>

    public static bool GetExtentionPropertyAsBoolean<T>(this MetadataWorkspace workspace, string propertyName)

    {

        return (GetExtentionPropertyInternal<T>(workspace,propertyName).ToString().ToLower() == "true") ;   

    }

    /// <summary>

    /// Retorna el valor de una propiedad generada en la extensión del Diseñador del Entity Framework

    /// </summary>

    /// <typeparam name="T">Entidad para obtener la propiedad</typeparam>

    /// <param name="workspace"></param>

    /// <param name="propertyName">Ejemplo: http://schemas.vemn.com/EFExtensions:AuditarProperty</param>

    /// <returns></returns>

    public static string GetExtentionPropertyAsString<T>(this MetadataWorkspace workspace, string propertyName)

    {

        return GetExtentionPropertyInternal<T>(workspace, propertyName).ToString();

    }

    /// <summary>

    /// Retorna el valor de una propiedad generada en la extensión del Diseñador del Entity Framework

    /// </summary>

    /// <typeparam name="T">Entidad para obtener la propiedad</typeparam>

    /// <param name="workspace"></param>

    /// <param name="propertyName">Ejemplo: http://schemas.vemn.com/EFExtensions:AuditarProperty</param>

    /// <returns></returns>

    public static int  GetExtentionPropertyAsInt<T>(this MetadataWorkspace workspace, string propertyName)

    {

        return Convert.ToInt32(GetExtentionPropertyInternal<T>(workspace, propertyName));

    }

    /// <summary>

    /// Retorna el valor de una propiedad generada en la extensión del Diseñador del Entity Framework

    /// </summary>

    /// <typeparam name="T">Entidad para obtener la propiedad</typeparam>

    /// <param name="workspace"></param>

    /// <param name="propertyName">Ejemplo: http://schemas.vemn.com/EFExtensions:AuditarProperty</param>

    /// <returns></returns>

    public static object GetExtentionPropertyAsObject<T>(this MetadataWorkspace workspace, string propertyName)

    {

        return GetExtentionPropertyInternal<T>(workspace, propertyName);

    }

    /// <summary>

    /// Retorna el valor de una propiedad generada en la extensión del Diseñador del Entity Framework

    /// </summary>

    /// <typeparam name="T"></typeparam>

    /// <param name="workspace"></param>

    /// <param name="propertyName">Ejemplo: http://schemas.vemn.com/EFExtensions:AuditarProperty</param>

    /// <returns></returns>

    private static object GetExtentionPropertyInternal<T>(MetadataWorkspace workspace, string propertyName)

    {

        StructuralType objectSpaceType;

        workspace.LoadFromAssembly(typeof(T).Assembly);

        if (!workspace.TryGetItem<StructuralType>(typeof(T).FullName, DataSpace.OSpace, out objectSpaceType))

        {

            throw new InvalidOperationException(String.Format(CultureInfo.CurrentCulture, "No se puede encontrar este tipo de datos en la Metadata", typeof(T)));

        }

        StructuralType edmType = workspace.GetEdmSpaceType(objectSpaceType);

        MetadataProperty mp = edmType.MetadataProperties.Where(x => x.Name == propertyName).Single();

        XElement xc = (XElement)mp.Value;

        return xc.Value;

    }

}

La forma de utilizar esta propiedad en nuestro codigo es:

NorthwindEntities ctx = new NorthwindEntities();

bool audita = ctx.MetadataWorkspace.GetExtentionPropertyAsBoolean<Customers>("http://schemas.vemn.com/EFExtensions:AuditarProperty");

//Hago algo con la auditoria

De esta forma, hemos visto como de manera relativamente sencilla se puede extender el Entity Designer y de que manera nos puede ayudar al momento de estandarizar configuraciones en las entidades.

Por supuesto que la cantidad de escenarios e ideas posibles con esta funcionalidad son muchas como pueden ser:

• Revisión o Comenarios sobre los datos.
• Seguridad en los Datos.
• Agregado de Atributos del CLR
• Validaciones de Anotaciones.
• etc.
• etc.

Aqui pueden bajar el código de ejemplo utilizado en el artículo.

ADO.NET, Entity Framework, ORM, Visual Studio ado.net, ef, visual studio

Ya se viene la liberación de la versión final de Visual Studio 2010 y .NET 4.0 y uno siempre quiere tener una vista rápida de los cambios, agregados, etc.

En http://msdn.microsoft.com/en-us/library/bb386063(VS.100).aspx pueden encontrar un listado de todos los temas nuevos de esta plataforma.

.NET, ADO.NET, ASP.NET, Entity Framework, Visual Studio, WCF, WinForms visual studio, .net, asp.net, ef, wcf

Rob Caron ha publicado la fecha de lanzamiento para el 12 de Abril de este año. Mas info en http://blogs.msdn.com/robcaron/archive/2010/01/13/9948172.aspx

Visual Studio visual studio

Sharepoint, Visual Studio sharepoint, visual studio

Muchas veces creamos controles personalizados para utilizar en los formularios.
A veces estos controles se colocan en un Assembly para ser reutilizado y en otras dentro
de la propia capa de presentación de nuestra aplicación.
Por defecto el IDE asigna un engranaje azul como icono en la ToolBox.
Cuando tenemos muchos controles a veces puede costar encontrar el que queremos.
Y otras veces solamente por un tema estético podríamos querer asignar un ícono determinado, p.e.
cuando hacemos un componente de controles para un cliente.

Podemos fácilmente asignar imágenes a nuestros controles para visualizarlos más rapido desde la
ToolBox. Para asignar una imagen a un control debemos realizar los siguientes pasos:

Ejemplos:

Visual Studio

Cuando desarrollamos paquetes de extensibilidad para Visual Studio necesitamos obtener una clave conocida como PLK o Package Load Key. En el ambiente de desarrollo podemos probar los componentes de extensibilidad ya que tenemos instalado el kit de desarrollo o SDK de Visual Studio. Pero el usuario final no tiene por qué tener instalado dicho componente.

Microsoft requiere que cada paquete de extensibilidad para Visual Studio tenga una clave generada y registrada por Microsoft. El PLK permite que Microsoft realice un seguimiento de todos los paquetes lanzados por terceras partes a través de su firma. Dado que la clave se genera a partir de los datos registrados esta información debe ser exactamente igual a la declarada en el paquete de extensibilidad de lo contrario no funcionará.

La clave puede obtenerse gratis desde el sitio Visual Studio Industry Partner (VSIP):

• http://www.vsipmembers.com/Anonymous/Default.aspx

El PLK es una clave que se forma a partir de los datos específicos del paquete de extensibilidad:

Una vez obtenido el PLK desde el sitio mencionado anteriormente, el mismo debe almacenarse en un archivo de recursos del paquete de extensibilidad por ejemplo: “VSPackage.resx”. En este archivo se guarda el string de la clave y se le asigna un ID, como se muestra a continuación.

 Luego se debe editar la clase del proyecto que herede de “Package” o “PackageBase” y agregarle los atributos “Guid” y “ProvideLoadKey”. Por ejemplo:

   1:  [ProvideLoadKey("Standard","1.0.0.0",”AzManDSLTool”, “MaxiMegaCorporation”, 105)]

   2:  [Guid(“STRING DEL GUID”)]

   3:  internal sealed partial class AzManDslToolPackage : AzManDslToolPackageBase

   4:  {

   5:  }

El ejemplo anterior muestra la registración de un PLK en un proyecto DSL pero esto aplica también para los paquetes de extensibilidad en general.
 
Los parámetros del atributo “ProvideLoadKey” son:

La combinación de los primeros cuatro parámetros de “ProvideLoadKey” están codificados dentro del PLK y por lo tanto deben ser iguales a los declarados al obtener la clave.

Antes de distribuir los archivos de instalación o siquiera intentar instalarlo en nuestras máquinas, cuestión que puede llevarnos varios valiosos minutos de nuestro tiempo, tenemos el beneficio de poder comprobar la correcta carga de la clave por parte del IDE. Solo hace falta ingresar en la sección de “Debug” dentro de las propiedades del proyecto e ingresar lo siguiente en Comand line arguments: “/rootsuffix Exp /noVSIP”. Por supuesto también deben configurar que al ejecutar el paquete se abra otra instancia de Visual Studio como se muestra en la siguiente imagen.

Luego si se ejecuta el proyecto se abrirá otra  instancia del IDE donde podemos probar nuestro paquete de extensibilidad. En caso de falla en la carga del PLK veremos un mensaje de error. Una vez efectuadas estas tareas y hecho el build del correspondiente proyecto de instalación pueden distribuir los archivos.

Mantenimiento 

Un tema muy importante que debemos tener en cuenta es que cuando hacemos algún mantenimiento al paquete de extensibilidad, ya sea que se corrijan funcionalidades o se agreguen nuevas y siempre y cuando cambiemos la versión (p.e. 1.0.0.0 a 1.0.0.1), seguramente vamos a tener que generar un nuevo instalador para desplegar la nueva versión. Atención! si se cambia la versión del producto se deberá actualizar la clave del paquete de extensibilidad (PLK) en el archivo de recursos correspondiente.

 Fuentes:

• VSPackage Load Keys : http://msdn2.microsoft.com/en-us/library/bb165795(VS.80).aspx
• How to Install a PLK (C#): http://msdn2.microsoft.com/en-us/library/bb165968(VS.80).aspx

Visual Studio visual studio