O bruxo mobile

EF 6: Operaciones de migraciones personalizadas

2013-05-15T17:57:12Z

Hace ya un tiempo, el buen amigo @iceoverflow ,hizo un pequeño pero muy interesante pull request que nos habilita la posibilidad de crear y enchufar nuevas operaciones de migración que no tengamos por defecto en Entity Framework. Aunque el proceso es un poco mecánico, abre un montón de posibilidades para hacer nuevas contribuciones, incluso aunque no sea directamente en el código de EF y si en alguna contribución ( tengo una pequeña sorpresa con esto pero ya os la contaré cuando esté más avanzada ). A continuación me gustaría enseñaros un pequeño ejemplo de lo que podemos hacer y, por supuesto, todo aquello que os gustaría tener me encantaría escucharlo e incluso hacerlo…

Bien, empezamos, trataremos de hacer una operación de migración para crear una vista, lo primero por lo tanto es definir la operación, para ello, solamente tenemos que heredar de MigrationOperation, como por ejemplo vemos a continuación:

namespace System.Data.Entity.Migrations.Model
{
    using System.Data.Entity.Utilities;

    /// <summary>
    /// Represent a create view in database
    /// </summary>
    public class CreateViewOperation
        :MigrationOperation
    {
        /// <summary>
        /// The view name
        /// </summary>
        public string ViewName { get; private set; }

        /// <summary>
        /// The view body sql
        /// </summary>
        public string BodySql { get; private set; }


        /// <summary>
        /// Create a new instance
        /// </summary>
        /// <param name="viewName">the view name to create</param>
        /// <param name="bodySql">the view body sql </param>
        public CreateViewOperation(string viewName, string bodySql)
            :base(null)
        {
            Check.NotEmpty(viewName,"viewName");
            Check.NotEmpty(bodySql,"bodySql");

            this.ViewName = viewName;
            this.BodySql = bodySql;
        }

        /// <inheritdoc/>
        public override bool IsDestructiveChange
        {
            get { return false; }
        }

        /// <inheritdoc/>
        public override MigrationOperation Inverse
        {
            get
            {
                return new DropViewOperation(ViewName);
            }
        }
    }
}

Bien, ahora que ya tenemos definida nuestra operación, ya la podemos incluir dentro de nuestras migraciones, para que quede de una forma consistente con las operaciones actuales, podríamos crear un método extensor de de DbMigration como el siguiente:

        /// <summary>
        /// Create a new view
        /// </summary>
        /// <param name="migration">The DBMigration</param>
        /// <param name="viewName">The name of view to create</param>
        /// <param name="bodySql">The sql body of view to create</param>
        public static void CreateView(this DbMigration migration, string viewName, string bodySql)
        {
            ((IDbMigration)migration)
              .AddOperation(new CreateViewOperation(viewName, bodySql));
        }

Una vez hecho este trabajo, cuando una operación se ejecute, esta operación se enviará al generador sql que tengamos configurado,recuerde que puede establecerlo ahora con nuestro punto central de configuración DbConfiguration. Por lo tanto, este generador debe de estar preparado para procesar estas operaciones, por lo tanto, lo normal será partir de un generador dado como por ejemplo SqlServerMigrationSqlGenerator para extenderlo con esta nueva operación. Para nuestro ejemplo podríamos hacer algo como lo siguiente:

    /// <summary>
    /// Extented Sql Server Migrations Sql Generator with more
    /// operations.
    /// <remarks>
    /// For set  this migrations sql generator you need register it in
    /// your DbMigrationsConfiguration{TContext} using the method 
    /// SetSqlGenerator
    /// <example>
    /// SetSqlGenerator("System.Data.SqlClient", new AdvancedSqlServerMigrationSqlGenerator());
    /// </example>
    /// </remarks>
    /// </summary>
    public class ExtendedSqlServerMigrationSqlGenerator
        : SqlServerMigrationSqlGenerator
    {
        /// <inheritdoc/>
        protected override void Generate(MigrationOperation migrationOperation)
        {
            
        }
     }

Ahora, en nuestro Generate deberíamos ver como procesar cada una de las posibles operaciones personalizadas que podamos querer incluir, para facilitar la tarea y no ver demasiada conversión o switch un truquito rápido sería este:

        /// <inheritdoc/>
        protected override void Generate(MigrationOperation migrationOperation)
        {
            this.Generate((dynamic)migrationOperation);
        }

        /// <summary>
        /// Generate a SQL to create a new view in database
        /// </summary>
        /// <param name="createViewOperation">The operation to produce sql for.</param>
        public virtual void Generate(CreateViewOperation createViewOperation)
        {
            using (var writer = Writer())
            {
                writer.Write("IF object_id(N'{0}', 'V') IS NOT NULL ",createViewOperation.ViewName);
                writer.WriteLine("DROP VIEW {0} ",createViewOperation.ViewName);
                writer.WriteLine("GO ");
                writer.WriteLine("CREATE VIEW {0} AS {1}",createViewOperation.ViewName,createViewOperation.BodySql);

                this.Statement(writer);
            }
        }

Al ponerlo como dynamic podemos crear un método para cada una de las operaciones personalizadas y por lo tanto simplificar tanto la lectura como el mantenimiento del código.

Espero que os haya gustado esta posibilidad, por supuesto, para los que os habéis fijado en el código esto forma parte de un proyecto que ya contiene muchas más posibles operaciones de migración que pronto compartiré con todos vosotros, de ahí que os preguntará que os gustaría tener!!, animaros…

Saludos

unai

Commands y Windows Azure ServiceBus

2013-05-13T17:32:26Z

Bueno, un post pequeñito pequeñito, más que nada y para ser sincero, para cambiar un poco de tercio, pero que espero que os resulte interesante. Hace ya bastante tiempo, los pocos que leéis mi aburrido blog, escribí acerca de eventos de dominio y agregados. En esta ocasión me gustaría hablar de comandos y de alguna pequeña ayuda que el nuevo SDK de Azure nos trae para implementaciones de nuestros manejadores. Si bien, comandos y eventos, en realidad son cuestiones semánticas y poco más, uno en pasado, otro acción, receptores y poco más la verdad es que su implementación se parece muchísimo, puesto que en ambos tenemos un consumidor ( o N en realidad ) capaz de despachar acciones, la información del evento producido o el comando ejecutado. La implementación de estos despachadores ~~( que feo.. )~~ suele ser más o menos sencilla cuando estamos modelando nuestro sistema pero en realidad, a la hora de ir a un sistema real el tema se complica y muchas veces se acaba por utilizar algunas buenas piezas ya construidas como puede ser NServiceBus de Udi Dahan.

Nota: Para los que os interese NServiceBus y todo lo relacionado con este bloque de código os recomiendo el blog de MarÇel Serrate.

Pues bien, la nueva versión del SDK de Azure, SDK 2.0, incluye una pequeñita mejora en el procesado de mensajes de una cola, habitual para la implementación de un dispatcher de comandos y eventos, de tal forma que el patrón de recepción y vuelta a escuchar de los mensajes en nuestra cola se simplifique muchísimo introduciendo un patrón de eventos. Concrétamente veremos que el API cliente para manejar nuestras colas dispone de un nuevo método OnMessage con el que podremos especificar donde haremos el procesado de los mensajes y el establecimiento de diferentes opciones como el auto completado de los mensajes, el número máximo de llamadas concurrentes y/o el método a utilizar para manejar excepciones que se produzcan en la recepción de los mensajes. Un ejemplo trivial de esto podría ser:

            var eventDrivenMessagingOptions = new OnMessageOptions();

            eventDrivenMessagingOptions.AutoComplete = false;
            eventDrivenMessagingOptions.ExceptionReceived += OnExceptionReceived;
            eventDrivenMessagingOptions.MaxConcurrentCalls = 5;
        
            // Subscribe for messages.
            var queueClient = QueueClient.Create("commands");
            queueClient.OnMessage(OnMessageArrived, eventDrivenMessagingOptions);

Ahora, solamente necesitaríamos nuestro método de manejo, OnMessageArrived, dónde pondríamos la lógica de tratamiento de estos comandos/eventos para asignárselos a sus correspondientes manejadores.

        void OnMessageArrived(BrokeredMessage message)
        {
        }

Sencillo, ¿verdad?… Bueno, ya os dije que sería una entrada cortita…

Unai

EF 6: Command rewriters - I

2013-05-10T11:03:19Z

En las dos últimas dos entradas he hablado sobre el nuevo bloque introducido en Entity Framework 6 para la realización de intercepciones. Aunque en principio solamente hemos hablado de lo básico, como por ejemplo los diferentes tracers, más aún con la nueva propiedad Database.Log, en realidad este bloque nos permite hacer cosas mucho más interesantes como por ejemplo el re-write de consultas. Si nos fijamos un poco en nuestra nueva clase DbInterceptor esta nos expone dos interfaces fundamentales IDbCommandInterceptor y IDbCommandTreeInterceptor de las que realmente podremos partir si queremos algo mucho más “a bajo nivel” dentro de la infraestructura de Entity Framework. Con el fin de ver algo diferente a los procesos de instrumentalización de las consultas vamos a intentar crear algún ejemplo de intercepción con reescritura de consulta utilizando estas dos interfaces.

IDbCommandInterceptor, reescritura de tu SQL

Como ya hemos comentado, esta interfaz nos ofrece los procesos de pre y post para las tareas habituales con la base de datos como por ejemplo son la ejecución de consultas y comandos. La idea para nuestra reescritura es poder introducir algún mecanismo que nos permita identificar un comando y proceder a su cambio, para verlo construiremos la siguiente clase CommandRewriter, la cual esta hecha a modo de ejemplo, intentaré poner pronto a vuestra disposición una implementación más apropiada de un sistema de reescritura de consultas.

    public abstract class CommandRewriter
        :IDbCommandInterceptor
    {

        int IDbCommandInterceptor.NonQueryExecuted(DbCommand command, int result, DbCommandInterceptionContext interceptionContext)
        {
            return result;
        }

        DbDataReader IDbCommandInterceptor.ReaderExecuted(DbCommand command, DbDataReader result, DbCommandInterceptionContext interceptionContext)
        {
            return result;
        }

        object IDbCommandInterceptor.ScalarExecuted(DbCommand command, object result, DbCommandInterceptionContext interceptionContext)
        {
            return result;
        }

        void IDbCommandInterceptor.NonQueryExecuting(DbCommand command, DbCommandInterceptionContext interceptionContext)
        {
            if (IsCandidate(command))
            {
                Rewrite(command);
            }
        }

        void IDbCommandInterceptor.ScalarExecuting(DbCommand command, DbCommandInterceptionContext interceptionContext) 
        {
            if (IsCandidate(command))
            {
                Rewrite(command);
            }
        }

        void IDbCommandInterceptor.ReaderExecuting(DbCommand command, DbCommandInterceptionContext interceptionContext)
        {
            if (IsCandidate(command))
            {
                Rewrite(command);
            }
        }

        public abstract bool IsCandidate(DbCommand command);

        public abstract void Rewrite(DbCommand command);
    }

Si nos fijamos, en realidad, no hemos hecho absolutamente nada, simplemente hemos puesto una pequeña comprobación antes de la ejecución de los comandos que nos permita identificar si ese comando es candidato a ser reescrito. En caso afirmativo procedemos a la tarea. Un ejemplo evidente de esta reescritura se produce cuando queremos cambiar una consulta exacta por otra, por ejemplo para poder utilizar algún hint, cambiar un parámetro etc. para esto, podríamos hacer algo trivial como sigue:

    public abstract class MatchCommandRewriter
        :CommandRewriter
    {
        public abstract string MatchedQuery { get; }

        public abstract string NewQuery { get; }

        public override bool IsCandidate(System.Data.Common.DbCommand command)
        {
            return String.Equals(command.CommandText, MatchedQuery, StringComparison.InvariantCultureIgnoreCase);
        }

        public override void Rewrite(System.Data.Common.DbCommand command)
        {
            command.CommandText = NewQuery;
        }
    }

Ahora, que hemos creado estas simples bases, podríamos introducir una reescritura por ejemplo como la siguiente, que es solamente con fin ilustrativo, , en la que introducimos un hint NOLOCK en la consulta:

   public class CustomerNoLockQueryRewrite
        :MatchCommandRewriter
    {

        public override string MatchedQuery
        {
            get
            {
                return "SELECT \r\n[Extent1].[Id] AS [Id], \r\n[Extent1].[FirstName] AS [FirstName]\r\nFROM [dbo].[Customers] AS [Extent1]";
            }
        }

        public override string NewQuery
        {
            get
            {
                return "SELECT [Extent1].[Id] AS [Id], [Extent1].[FirstName] AS [FirstName] FROM [dbo].[Customers] AS [Extent1] WITH (NOLOCK) ";
            }
        }
    }

Una vez creado nuestro rewriter solamente nos queda asignarlo, para lo cual, como ya sabemos de otras entradas tenemos nuestra clase Interception.

Interception.AddInterceptor(new CustomerNoLockQueryRewrite());

A lo largo de esta entrada hemos podido ver como los interceptores sirven para mucho mas que para las trazas de nuestras consultas y podemos tener una ganancia importante con su uso dentro de nuestras aplicaciones. En esta primera edición hemos visto la intercepción de nuestras consultas SQL, para la siguiente intentaremos ver como modificar nuestros arboles de consulta antes de generar el SQL.

Saludos

Unai

EF 6: Interceptors, segunda iteración

2013-05-08T16:10:00Z

Es lo malo de escribir posts con todo en desarrollo, que se quedan desactualizados de un día para otro, de hecho, no tengo mucha idea de cuanto os pueden aportar, a vosotros amigos lectores, estas entradas que hago sobre EF 6 y quizás seguramente estoy perdiendo el tiempo, pero me cuesta, aún así, resistirme a hacerlo.

En la anterior entrada hemos visto los primeros pasos con interception y como podíamos configurar esta, después del último commit de Arthur algunas cosas han cambiado y en mi opinión creo que han quedado mejor, mas consistentes con el diseño actual.

El primer cambio es la creación de un DbCommandLogger y un DbCommandLoggerFactory, que nos permitirán disponer de una clase para el log de los diferentes comandos con una implementación por defecto que hace la escritura en un TextWriter que podemos establecer en su constructor.

public delegate DbCommandLogger DbCommandLoggerFactory(DbContext context, TextWriter writer);

Para establecer este DbCommandLogger tenemos una nueva propiedad en nuestro objeto Database que nos permite establecer un TextWriter a utilizar, en realidad aunque lo que hacemos en esta propiedad es establecer el TextWriter internamente se establecer un command logger con ese text writer. Fíjese en nuestro siguiente código como podemos establecer la consola de salida como logger de los diferentes comandos ejecutados por Entity Framework.

    public class CRMContext
        :DbContext
    {
        public DbSet<Customer> Customers { get; set; }

        public CRMContext()
        {
            Database.Log = Console.Out;
        }
    }

Por supuesto, si queremos cambiar nuestro DbCommandLogger por defecto podremos hacerlo, para ello, como siempre podemos acudir a nuestro DbConfiguration y establecer un Dependency Resolver o bien setearlo con el nuevo método SetCommandLogger.

   public class Configuration
        :DbConfiguration
    {
        public Configuration()
        {
            SetCommandLogger((context, writer) => new DbCommandLogger(context, writer));
        }
    }

Bueno, lo dicho, no se si estas pinceladas son interesantes para vosotros amigos lectores, pero espero que si y sobre todo que dejéis feedback de lo que necesitáis en el producto.

Saludos

Unai

EF 6: Sorpresa, interceptors

2013-05-03T08:49:40Z

Pues si, digo bien con sorpresa, porque hasta ahora yo no era consciente de que esta fuera a ser una de las nuevas características de EF 6, de hecho si miramos el roadmap veremos que no estaba contemplada. Pero por lo que sea ya tenemos aquí los primeros commits relacionados con la posibilidad de implementar mecanismos de intercepción en la nueva versión de Entity Framework. Aunque seguramente cambiarán ciertas cosas hasta la versión final, no me puedo resistir a enseñaros alguna pincelada.

Interception

La clase estática Interception representa por ahora el punto dónde podemos agregar y quitar nuestros interceptores. En realidad, esto me ha chocado un poco porque creía que era un patrón obsoleto como el uso de Database en anteriores versiones, y creo que va a cambiar, aunque en el tablero de preguntas del proyecto hay una pregunta abierta que espero que respondan. Esta clase es tan simple como vemos a continuación.

    public static class Interception
    {
        /// <summary>
        ///     Registers a new <see cref="IDbInterceptor" /> to receive notifications. Note that the interceptor
        ///     must implement some interface that extends from <see cref="IDbInterceptor" /> to be useful.
        /// </summary>
        /// <param name="interceptor">The interceptor to add.</param>
        public static void AddInterceptor(IDbInterceptor interceptor)
        {          
        }

        /// <summary>
        ///     Removes a registered <see cref="IDbInterceptor" /> so that it will no longer receive notifications.
        ///     If the given interceptor is not registered, then this is a no-op.
        /// </summary>
        /// <param name="interceptor">The interceptor to remove.</param>
        public static void RemoveInterceptor(IDbInterceptor interceptor)
        { 
        }

        /// <summary>
        ///     This is the entry point for dispatching to interceptors. This is usually only used internally by
        ///     Entity Framework but it is provided publicly so that other code can make sure that registered
        ///     interceptors are called when operations are performed on behalf of EF. For example, EF providers
        ///     a may make use of this when executing commands.
        /// </summary>
        public static Dispatchers Dispatch
        {
        }
    }

Como se puede ver, en realidad, lo que nos ofrece es un mecanismo para agregar y quitar interceptores, pensado en enchufar los mismos solamente en ciertas partes del trabajo o momentos determinados. De hecho la nueva característica de scaffolding de los procedimientos almacenados se basa en esta infraestructura. A mayores de esto, vemos como un interceptor no es más que cualquier clase que implemente IDbInterceptor, por suerte, a nosotros ya nos ofrecen una clase base de la que partir llamada DbInterceptor, que será la que usemos por norma general.

    public class DbInterceptor : IDbCommandInterceptor, IDbCommandTreeInterceptor
    {
        /// <inheritdoc />
        public virtual DbCommandTree TreeCreated(DbCommandTree commandTree, DbInterceptionContext interceptionContext)
        {
            return commandTree;
        }

        /// <inheritdoc />
        public virtual void NonQueryExecuting(DbCommand command, DbInterceptionContext interceptionContext)
        {
        }

        /// <inheritdoc />
        public virtual int NonQueryExecuted(DbCommand command, int result, DbInterceptionContext interceptionContext)
        {
            return result;
        }

        /// <inheritdoc />
        public virtual void ReaderExecuting(DbCommand command, CommandBehavior behavior, DbInterceptionContext interceptionContext)
        {
        }

        /// <inheritdoc />
        public virtual DbDataReader ReaderExecuted(
            DbCommand command, CommandBehavior behavior, DbDataReader result, DbInterceptionContext interceptionContext)
        {
            return result;
        }

        /// <inheritdoc />
        public virtual void ScalarExecuting(DbCommand command, DbInterceptionContext interceptionContext)
        {
        }

        /// <inheritdoc />
        public virtual object ScalarExecuted(DbCommand command, object result, DbInterceptionContext interceptionContext)
        {
            return result;
        }

        /// <inheritdoc />
        public virtual void AsyncNonQueryExecuting(DbCommand command, DbInterceptionContext interceptionContext)
        {
        }

        /// <inheritdoc />
        public virtual Task<int> AsyncNonQueryExecuted(DbCommand command, Task<int> result, DbInterceptionContext interceptionContext)
        {
            return result;
        }

        /// <inheritdoc />
        public virtual void AsyncReaderExecuting(DbCommand command, CommandBehavior behavior, DbInterceptionContext interceptionContext)
        {
        }

        /// <inheritdoc />
        public virtual Task<DbDataReader> AsyncReaderExecuted(
            DbCommand command, CommandBehavior behavior, Task<DbDataReader> result, DbInterceptionContext interceptionContext)
        {
            return result;
        }

        /// <inheritdoc />
        public virtual void AsyncScalarExecuting(DbCommand command, DbInterceptionContext interceptionContext)
        {
        }

        /// <inheritdoc />
        public virtual Task<object> AsyncScalarExecuted(DbCommand command, Task<object> result, DbInterceptionContext interceptionContext)
        {
            return result;
        }
    }

Como podéis ver, hay muchos métodos en los que nos podemos enganchar, tanto para llamadas síncronas como asíncronas, así como a ciertores pre-post procesos, como por ejemplo en la ejecución de comandos. Un hola mundo, podría ser el siguiente, donde sacamos por la consola las consultas de lectura ejecutadas por EF:

    public class TracerInterceptor
        :DbInterceptor
    {
        public override DbDataReader ReaderExecuted(DbCommand command, System.Data.CommandBehavior behavior, DbDataReader result, DbInterceptionContext interceptionContext)
        {
            Console.WriteLine("CommandText:{0}",command.CommandText);

            return result;
        }
    }

Feedback

Estoy seguro que todo el equipo va a necesitar feedback de esta nueva característica, que os gusta, que no, que necesitáis que no tengáis etc. por eso me gustaría pediros a todos que os animéis a pasar por el portal del producto y dejar vuestras necesidades / recomendaciones etc…

Saludos

Unai

EF 6:Nuevas pequeñas grandes cosas..

2013-04-25T20:24:46Z

Creo que son ya unas cuantas entradas las que llevo con EF 6 en este blog, y eso que aún no tenemos ni la primera CTP, pero a cada nueva build que hacen podemos ver nuevas e interesantes cosas que me gusta adelantarme a escribir.

De entre estas nuevas cosillas me gustaría destacar estos tres nuevos métodos que he podido contribuir en sus correspondientes pull request ( addrange, removerange, haschanges )

AddRange

Como seguramente os imaginaréis, este pequeño método nos permite agregar dentro de nuestros DbSet<T> y DbSet un conjunto de elementos de una única pasada, evitando así tener que hacer las n repetitivas llamadas al método Add. Aunque esto parezca trivial, y en realidad, fuera fácil de construir con un método extensor, la verdad es que tiene un pelín más de miga, puesto que algo que podíamos hacer era aprovechar este nuevo método para evitar la detección de cambios para cada uno de los elementos de la colección a incluir.

Nota:

Como seguramente sabréis, EF realiza un proceso de detección de cambios de forma automática ( si no hemos configurado lo contrario ) en ciertos procesos, como por ejemplo en el de agregar elementos al DbSet, por lo tanto, esto podría suponer una sobrecarga en ciertos escenarios con muchas entradas en el ObjectStateManager. Si quieres saber más sobre la detección de cambios en EF, entonces nada mejor que leer del mejor, en concreto, esta serie de Arthur Vickers.

Al final, una vez valorado esto y agregado este nuevo método en la superficie publica de DbSet<T> y DbSet, el código queda tan liviano como vemos a continuación en el método AddRange de nuestro InternalSet.

        public virtual void AddRange(IEnumerable entities)
        {
            DebugCheck.NotNull(entities);

            InternalContext.DetectChanges();

            ActOnSet(
                entity => InternalContext.ObjectContext.AddObject(EntitySetName, entity), EntityState.Added, entities, "Add");
        }

RemoveRange

Bien, después de explicado lo anterior, este es de cajón, en realidad aplican los mimos argumentos con respecto a relajar la detección de cambios, por lo tanto, la implementación en nuestro InternalSet es similar a lo siguiente:

        public virtual void RemoveRange(IEnumerable entities)
        {
            DebugCheck.NotNull(entities);

            // prevent "enumerator was changed" exception
            // if entities is syncronized with other elements
            // (e.g: local view from DbSet.Local.)
            var copyOfEntities = entities
                .Cast<object>().ToList();

            InternalContext.DetectChanges();

            ActOnSet(
                entity => InternalContext.ObjectContext.DeleteObject(entity), EntityState.Deleted, copyOfEntities, "Delete");
        }

HasChanges

Este método es una pequeña ayuda para comprobar si nuestra unidad de trabajo tiene cambios pendientes, elementos agregados, borrados o modificados en la misma y no llevados aún a la base de datos. El mismo está situado en la clase DbChangeTracker y como podemos ver en el siguiente tests funcional lo tendremos accesible mediante la propiedad ChangeTracker de nuestros DbContext.

        [Fact]
        public void HasChanges_return_true_if_context_have_entities_in_deleted_state()
        {
            using (var context = new SomeContext())
            {
                var foo = new Foo() { Bar = "the foo" };

                context.Foos.Attach(foo);
                context.Entry(foo).State = EntityState.Deleted;

                Assert.True(context.ChangeTracker.HasChanges());
            }
        }

La implementación es realmente sencilla puesto que internamente ya se dispone de un método para comprobar el número de entradas en el ObjectStateManager.

        /// <summary>
        ///     Check if the <see cref="DbContext" /> contain changes, added, modified or deleted entities and relationships of POCO entities. 
        ///     This method call first to detect changes on the underlying <see cref="DbContext" />.
        /// </summary>
        /// <returns>True if underlying <see cref="DbContext" /> have changes, else false.</returns>
        public bool HasChanges()
        {
            _internalContext.DetectChanges();

            var objectStateManager = _internalContext
               .ObjectContext.ObjectStateManager;

            DebugCheck.NotNull(objectStateManager);

            var entriesAffected =
              objectStateManager.GetObjectStateEntriesCount(EntityState.Added | EntityState.Deleted | EntityState.Modified);


            return entriesAffected > 0;
        }

Para terminar esta pequeña entrada me gustaría hablar de otra “gran” novedad que tenemos en las últimas builds de EF, novedad introducida por el propio equipo, en concreto por Andrew Peters (@anpete), que consiste en la posibilidad de hacer el scaffolding de las entidades mapeadas con procedimientos almacenados de forma automática. Lo mejor para explicarlo es ver un pequeño ejemplo, para ello partiremos del siguiente modelo y su correspondiente configuración:

    public class Blog
    {
        public int Id { get; set; }
        public string FirstName { get; set; }
        public string LastName { get; set; }
    }

    public class BlogContext
        :DbContext
    {
        public DbSet<Blog> Blogs { get; set; }

        protected override void OnModelCreating(DbModelBuilder modelBuilder)
        {
            modelBuilder.Configurations.AddFromAssembly(typeof(BlogContext).Assembly);
        }
    }

    internal class BlogConfiguration
        :EntityTypeConfiguration<Blog>
    {
        private BlogConfiguration()
        {
            this.MapToStoredProcedures();
        }
    }

Nada nuevo, o por lo menos de lo que no hayamos hablado ya, una entidad mapeada con procedimientos almacenados por medió del método MapToStoreProcedures, aplicando convenciones al no estar “configurado”. Lo nuevo en las últimas builds, le recomiendo usar los paquetes de NuGet del feed de ASP.NET Stack nightly builds, está en que las migraciones son capaces de hacer el scaffolding de estos procedimientos almacenados, por lo tanto, si ejecutaramos la creación de una migración, tal cual sigue:

PM> enable-migrations
Checking if the context targets an existing database...
Code First Migrations enabled for project MapToStoreProcedures.

PM> Add-Migration InitialScaffolding
Scaffolding migration 'InitialScaffolding'.
The Designer Code for this migration file includes a snapshot of your current Code First model. This snapshot is used to calculate the changes to your model when you scaffold the next migration. If you make additional changes to your model that you want to include in this migration, then you can re-scaffold it by running 'Add-Migration InitialScaffolding' again.

Veríamos un resultado similar a lo siguiente:

namespace MapToStoreProcedures.Migrations
{
    using System;
    using System.Data.Entity.Migrations;
    
    public partial class InitialScaffolding : DbMigration
    {
        public override void Up()
        {
            CreateTable(
                "dbo.Blogs",
                c => new
                    {
                        Id = c.Int(nullable: false, identity: true),
                        FirstName = c.String(),
                        LastName = c.String(),
                    })
                .PrimaryKey(t => t.Id);
            
            CreateStoredProcedure(
                "Blog_Insert",
                p => new
                    {
                        FirstName = p.String(),
                        LastName = p.String(),
                    },
                body:
                    @"INSERT [dbo].[Blogs]([FirstName], [LastName])
                      VALUES (@FirstName, @LastName)
                      
                      DECLARE @Id int
                      SELECT @Id = [Id]
                      FROM [dbo].[Blogs]
                      WHERE @@ROWCOUNT > 0 and [Id] = scope_identity()
                      
                      SELECT t0.[Id]
                      FROM [dbo].[Blogs] as t0
                      WHERE @@ROWCOUNT > 0 and t0.[Id] = @Id"
            );
            
            CreateStoredProcedure(
                "Blog_Update",
                p => new
                    {
                        Id = p.Int(),
                        FirstName = p.String(),
                        LastName = p.String(),
                    },
                body:
                    @"UPDATE [dbo].[Blogs]
                      SET [FirstName] = @FirstName, [LastName] = @LastName
                      WHERE ([Id] = @Id)"
            );
            
            CreateStoredProcedure(
                "Blog_Delete",
                p => new
                    {
                        Id = p.Int(),
                    },
                body:
                    @"DELETE [dbo].[Blogs]
                      WHERE ([Id] = @Id)"
            );
            
        }
        
        public override void Down()
        {
            DropStoredProcedure("Blog_Delete");
            DropStoredProcedure("Blog_Update");
            DropStoredProcedure("Blog_Insert");
            DropTable("dbo.Blogs");
        }
    }
}

¿Qué os parece?

Saludos

Unai

EF 6: Connection resiliency y azure

2013-03-13T22:45:55Z

Seguro que de muchos es sabido que cuando trabajamos con Sql Database es posible que alguna de nuestras operaciones pueda fallar, independientemente de si usamos EF, NH o directamente con nuestro SqlClient, debido a inestabilidades de la red o problemas de back-end [si desea explorar el porque de la realidad de estos problemas le recomiendo este enlace]. Aunque en la realidad esto no es algo ni mucho menos habitual, puede pasar, y, por lo general, sino somos conscientes de ello suele dar bastantes dolores de cabeza, por lo aleatorio de los fallos. Por supuesto, hay muchos workaround para este problema, y como no, también para los que usamos actualmente EF, en cualquier de sus versiones como por ejemplo este que comenta mi buen amigo Cesar de La Torre. en un post de hace una eternidad. Con el fin de hacer esto más sencillo para nosotros y en realidad para resolver otros posibles problema similares para este u otros motores relacionales el equipo de EF ya tiene en la rama de EF 6 nuevas funcionalidades.

Estas nuevas características se pueden concretar en los siguientes elementos:

IExecutionStrategy

Esta interfaz define el contrato para la pieza que tendrá como responsabilidad la ejecución de operaciones que potencialmente necesiten reintentarse, por ejemplo las operaciones sobre Sql Database. El contrato de esta interfaz no es nada complicado como podemos ver a continuación:

namespace System.Data.Entity.Infrastructure
{
    using System.Diagnostics.CodeAnalysis;
    using System.Threading;
    using System.Threading.Tasks;

    public interface IExecutionStrategy
    {
        /// <summary>
        ///     Indicates whether this <see cref="IExecutionStrategy"/> might retry the execution after a failure.
        /// </summary>
        bool RetriesOnFailure { get; }

        /// <summary>
        ///     Executes the specified action.
        /// </summary>
        /// <param name="action">A delegate representing an executable action that doesn't return any results.</param>
        void Execute(Action action);

        /// <summary>
        ///     Executes the specified function and returns the result.
        /// </summary>
        /// <typeparam name="TResult">The return type of <paramref name="func"/>.</typeparam>
        /// <param name="func">A delegate representing an executable action that returns the result of type <typeparamref name="TResult"/>.</param>
        /// <returns>The result from the action.</returns>
        TResult Execute<TResult>(Func<TResult> func);
        
#if !NET40

        /// <summary>
        ///     Executes the specified asynchronous action.
        /// </summary>
        /// <param name="taskAction">A function that returns a started task.</param>
        /// <returns>
        ///     A task that will run to completion if the original task completes successfully (either the
        ///     first time or after retrying transient failures). If the task fails with a non-transient error or
        ///     the retry limit is reached, the returned task will become faulted and the exception must be observed.
        /// </returns>
        Task ExecuteAsync(Func<Task> taskFunc);

        /// <summary>
        ///     Executes the specified asynchronous action.
        /// </summary>
        /// <param name="taskAction">A function that returns a started task.</param>
        /// <param name="cancellationToken">
        ///     A cancellation token used to cancel the retry operation, but not operations that are already in flight
        ///     or that already completed successfully.
        /// </param>
        /// <returns>
        ///     A task that will run to completion if the original task completes successfully (either the
        ///     first time or after retrying transient failures). If the task fails with a non-transient error or
        ///     the retry limit is reached, the returned task will become faulted and the exception must be observed.
        /// </returns>
        Task ExecuteAsync(Func<Task> taskFunc, CancellationToken cancellationToken);

        /// <summary>
        ///     Executes the specified asynchronous function and returns the result.
        /// </summary>
        /// <typeparam name="TResult">
        ///     The type parameter of the <see cref="Task{T}"/> returned by <paramref name="taskFunc"/>.
        /// </typeparam>
        /// <param name="taskFunc">A function that returns a started task of type <typeparamref name="TResult"/>.</param>
        /// <returns>
        ///     A task that will run to completion if the original task completes successfully (either the
        ///     first time or after retrying transient failures). If the task fails with a non-transient error or
        ///     the retry limit is reached, the returned task will become faulted and the exception must be observed.
        /// </returns>
        [SuppressMessage("Microsoft.Design", "CA1006:DoNotNestGenericTypesInMemberSignatures")]
        Task<TResult> ExecuteAsync<TResult>(Func<Task<TResult>> taskFunc);

        /// <summary>
        ///     Executes the specified asynchronous function and returns the result.
        /// </summary>
        /// <typeparam name="TResult">
        ///     The type parameter of the <see cref="Task{T}"/> returned by <paramref name="taskFunc"/>.
        /// </typeparam>
        /// <param name="taskFunc">A function that returns a started task of type <typeparamref name="TResult"/>.</param>
        /// <param name="cancellationToken">
        ///     A cancellation token used to cancel the retry operation, but not operations that are already in flight
        ///     or that already completed successfully.
        /// </param>
        /// <returns>
        ///     A task that will run to completion if the original task completes successfully (either the
        ///     first time or after retrying transient failures). If the task fails with a non-transient error or
        ///     the retry limit is reached, the returned task will become faulted and the exception must be observed.
        /// </returns>
        [SuppressMessage("Microsoft.Design", "CA1006:DoNotNestGenericTypesInMemberSignatures")]
        Task<TResult> ExecuteAsync<TResult>(Func<Task<TResult>> taskFunc, CancellationToken cancellationToken);

#endif

    }
}

La idea básica que hay detrás de esta interfaz es poder envolver una acción en un determinado ámbito capaz de decidir si las excepciones que se produzcan son o no candidatas para reintentarse, por ejemplo porque entendemos que es un fallo de Sql Database y no relacionado con el mapeo, consulta etc…, cada cierto tiempo. Por supuesto, decidir si una excepción de una operación implica que la operación debe repetirse es algo configurable y no fijo, cuya implementación esta marcada por una nueva interfaz, que vemos a continuación.

IRetriableExceptionDetector

Mediante este contrato tendremos la posibilidad de especificar que excepciones son candidatas a “resolver” por medio de reintentos, el siguiente código representa este contrato

// Copyright (c) Microsoft Open Technologies, Inc. All rights reserved. See License.txt in the project root for license information.

namespace System.Data.Entity.Infrastructure
{
    public interface IRetriableExceptionDetector
    {
        /// <summary>
        ///     Determines whether the specified exception represents a transient failure that can be compensated by a retry.
        /// </summary>
        /// <param name="ex">The exception object to be verified.</param>
        /// <returns><c>true</c> if the specified exception is considered as transient, otherwise <c>false</c>.</returns>
        bool ShouldRetryOn(Exception ex);
    }
}

IRetryDelayStrategy

Este es el último elemento que necesitamos, y probablemente el más sencillo puesto que tiene como única finalidad marcar el tiempo entre reintentos de operaciones fallidas.

// Copyright (c) Microsoft Open Technologies, Inc. All rights reserved. See License.txt in the project root for license information.

namespace System.Data.Entity.Infrastructure
{
    public interface IRetryDelayStrategy
    {
        /// <summary>
        ///     Determines whether the action should be retried and the delay before the next attempt.
        /// </summary>
        /// <param name="lastException">The exception thrown during the last execution attempt.</param>
        /// <returns>
        ///     Returns the delay indicating how long to wait for before the next execution attempt if the action should be retried;
        ///     <c>null</c> otherwise
        /// </returns>
        TimeSpan? GetNextDelay(Exception lastException);
    }
}

Bien, ahora que ya conocemos las piezas, ya podemos entender que tenemos para Sql Database, y esto, no es más que implementaciones concretas para estos contratos que podemos “inyectar” dentro de EF .

La implementación para el trabajo de Azure, Sql Database, se basa principalmente en la clase SqlAzureExecutionStrategy, que tendremos por defecto en el proveedor de Sql Server por defecto.

// Copyright (c) Microsoft Open Technologies, Inc. All rights reserved. See License.txt in the project root for license information.

namespace System.Data.Entity.SqlServer
{
    using System.Data.Entity.Infrastructure;

    /// <summary>
    ///     An <see cref="ExecutionStrategy"/> that uses the <see cref="ExponentialRetryDelayStrategy"/> and
    ///     <see cref="SqlAzureRetriableExceptionDetector"/>.
    /// </summary>
    [DbProviderName("System.Data.SqlClient")]
    public class SqlAzureExecutionStrategy : ExecutionStrategy
    {
        public SqlAzureExecutionStrategy()
            : base(new ExponentialRetryDelayStrategy(), new SqlAzureRetriableExceptionDetector())
        {
        }
    }
}

Como observará, en realidad esto no tiene nada más que el marcador de tiempos, ExponentialRetryDelayStrategy, que cuyo nombre indica hace un incremento exponencial basado en la siguiente fórmula:min (minDelay + coefficient * random(1, maxRandomFactor) * (exponentialBase ^ retryCount - 1), maxDelay), y un detector de excepciones personalizado que permitirá reintentar las siguientes excepciones.

SqlException con diferentes numberos de error, revisar el código siguiente para ver los casos concretos.
Un TimeoutException.

Como se establece la estrategia que queremos usar? por ejemplo esta para Sql Database?, pues bien, tan simple como hacemos otras inyecciones, por medio de nuestro DbConfiguration y el método AddExecutionStrategy.

        /// <summary>
        ///     Call this method from the constructor of a class derived from <see cref="DbConfiguration" /> to add an
        ///     <see cref="IExecutionStrategy"/> for use with the associated provider.
        /// </summary>
        /// <remarks>
        ///     The <typeparamref name="T"/> type should have a <see cref="DbProviderNameAttribute"/> applied to it.
        ///     This method is provided as a convenient and discoverable way to add configuration to the Entity Framework.
        ///     Internally it works in the same way as using AddDependencyResolver to add an appropriate resolver for
        ///     <see cref="IExecutionStrategy" />. This means that, if desired, the same functionality can be achieved using
        ///     a custom resolver or a resolver backed by an Inversion-of-Control container.
        /// </remarks>
        /// <typeparam name="T"> The type that implements <see cref="IExecutionStrategy"/>. </typeparam>
        /// <param name="getExecutionStrategy"> A function that returns a new instance of an execution strategy. </param>
        protected internal void AddExecutionStrategy<T>(Func<T> getExecutionStrategy)
            where T : IExecutionStrategy
        {
            Check.NotNull(getExecutionStrategy, "getExecutionStrategy");

            _internalConfiguration.CheckNotLocked("AddExecutionStrategy");

            foreach (var providerInvariantNameAttribute in DbProviderNameAttribute.GetFromType(typeof(T)))
            {
                _internalConfiguration.AddDependencyResolver(
                    new ExecutionStrategyResolver<T>(providerInvariantNameAttribute.Name, /*serverName:*/ null, getExecutionStrategy));
            }
        }

Si nos fijamos un poco veremos como lo primero que hace este método es recuperar el proveedor para el que aplica esta estrategia, buscando un atributo, DbProviderName. Una vez localizado este atributo se establece el dependency resolver con la estrategia indicada. A partir de ese momento, ya tendremos disponible nuestra estrategia de reintentos..

Bueno, esto ha sido todo, espero que os sigan gustando las novedades de EF 6 y que sigáis viendo todo lo nuevo que poco a poco vamos teniendo…

Unai

EF 6: Snack Preview de MapToStoreProcedures en EF 6

2013-02-27T17:33:07Z

Por diversas razones, que no son objetivo de este post, el mapeo a procedimientos almacenados ha sido una de los issues más votados dentro del proyecto de EF 6, y por eso, tal como estaba en el roadmap inicial, el equipo ya ha empezado a trabajar en esta característica, de la cual ya tenemos algo hecho con lo que podemos jugar. Aunque aún tengo unas cuantas preguntas sin responder del equipo, con las fuentes actuales vemos como se ha incluído un nuevo método MapToStoreProcedures dentro de nuestra bien conocida clase EntityTypeConfiguration<T>.

        [SuppressMessage("Microsoft.Design", "CA1006:DoNotNestGenericTypesInMemberSignatures")]
        public EntityTypeConfiguration<TEntityType> MapToStoredProcedures(
            Action<ModificationFunctionsConfiguration<TEntityType>> modificationFunctionMappingConfigurationAction)
        {
            Check.NotNull(modificationFunctionMappingConfigurationAction, "modificationFunctionMappingConfigurationAction");

            var modificationFunctionMappingConfiguration
                = new ModificationFunctionsConfiguration<TEntityType>();

            modificationFunctionMappingConfigurationAction(modificationFunctionMappingConfiguration);

            _entityTypeConfiguration.MapToStoredProcedures(modificationFunctionMappingConfiguration.Configuration);

            return this;
        }

Como se puede ver en este pequeño fragmento, gracias a este nuevo método, tendremos la posibilidad de configurar el mapeo contra los procedimientos de inserción, borrado y actualización utilizando esta configuración. Como siempre se aprende mejor de los ejemplo, a continuación ponemos el ejemplo trivial de mapeo, que nos va a permitir ver algunas cosas interesantes.

        protected override void OnModelCreating(DbModelBuilder modelBuilder)
        {
            modelBuilder.Entity<Customer>()
                .MapToStoredProcedures((mfc) =>
                {
                    mfc.Update(umfc => umfc.HasName("uspCustomer")
                                            .Parameter(c => c.FirstName, "fname"));

                    mfc.Insert(imfc => imfc.HasName("ispCustomer")
                                        .Parameter(c => c.FirstName, "fname")
                                        .Parameter(c => c.LastName, "lname")
                                        .Result(c=>c.Id,"Id"));

                    mfc.Delete(dmfc => dmfc.HasName("dspCustomer")
                                        .Parameter(c => c.Id, "id"));
                });
        }

Como observará, con el método anterior podremos especificar los mapeos de los diferentes procedimientos, pudiendo personalizar desde el nombre de los mismos hasta el nombre de los parámetros, tanto de entrada como de salida. Bueno, hasta aquí esta pequeñita entrega, como rezaba el título era solamente un sneak… espero que los que conozcáis EF os animéis a hacer más clones y si encontráis mejoras no dudéis en contribuir…

Update 1: Parece que me he adelantado un pelin y la gente de ADO.NET ha liberado una especificación de esta característica mucho más completa, que complementa lo comentado aquí con tras de las estupendas características de esta nueva novedad como son:

Convenciones por defecto para los nombres de los SP. Es decir, si como anteriormente no especificamos alguna de las funciones, por defecto se buscarán los siguientes nombres de SP, type_Insert,type_Update y type_Delete. En nuestro caso Customer_Update, Customer_Insert y Customer_Delete.

Para las relaciones Many To Many hay soporte con SP para el trabajo de inserciones y borrados, revisar la especificación para más información.

Saludos

Unai

Cloud Tour

2013-01-29T08:17:07Z

Ya estamos otra vez de gira, en esta ocasión hablando sobre la plataforma de cloud computing de Microsoft, Windows Azure. Aunque, desde un punto de vista especial y fuera de los convencionalismos típicos de esta plataforma. La idea es ver si Windows Azure también es una estupenda plataforma para aquellos que no trabajan en entornos Microsoft. La agenda y los detalles de las sesiones los podéis ver a continuación:

En mi caso, yo me encargaré de la plataforma de acceso a datos, dónde veremos las posibilidades que Windows Azure nos da. Espero que os guste, para los que no estéis registrados, aquí tenéis fechas y más información…. nos vemos..

AGENDA

9:30 – 10:30 Introducción a la plataforma
10:30 – 11:30 IaaS – Linux, máquinas y redes virtuales
11:30 Café
11:45 – 12:30 PaaS – Trabajando con Java y Eclipse
12:30 – 13:30 PHP y Azure Web Sites
13:30 Comida
14:30 – 15:30 Almacenamiento en la nube: SQL, NoSQL
15:30 – 16:30 Big Data y Apache Hadoop
16:30 – 17:30 Desarrollo de backends para dispositivos móviles

Organización: Plain Concepts

Introducción a la plataforma

El objetivo de esta primera sesión será describir los principales servicios de la plataforma; Por qué puede interesar para mi empresa usar Cloud Computing, qué nivel de servicio, que opciones tengo si no trabajo con tecnologías Microsoft etc… Durante la sesión se hará especial hincapié en las diferentes opciones de interoperabilidad que existen y cómo es posible trabajar con otros lenguajes de programación como Java, Node.js o PHP e incluso desde otros sistema operativos, Linux y MAC.

IaaS - Linux, Máquinas y Redes Virtuales

La plataforma Windows Azure dispone de un servicio de infraestructura que permite de forma rápida y sencilla crear máquinas virtuales Windows y Linux. Durante esta sesión se mostrará las principales características de la misma y cómo es posible trabajar desde un ecosistema Linux, tanto a nivel de cliente como de servidor.

Cómo desplegar una máquina virtual Linux.
Cómo montar tu propia red virtual.
Cómo trabajar desde un ecosistema completamente Linux, tanto en desktop como en servidor.

PaaS, trabajando con Java y Eclipse

El servicio de “Plataforma como Servicio” es otro de los pilaras básicos de Windows Azure, el cual permite abstraernos de gran parte del trabajo de infraestructura y centrarnos únicamente en la aplicación que queremos desarrollar, posibilitando escenario de escalabilidad y disponibilidad difíciles de conseguir en otro tipo de soluciones. Durante esta sesión veremos de forma práctica cómo podemos desplegar aplicaciones Java con Eclipse en Windows Azure.

PHP y Azure Web Sites

Durante esta sesión se mostrará de forma prácticas las opciones disponibles para desplegar aplicaciones PHP en Windows Azure.

Durante esta sesión se empleará Windows Azure Web Sites para desplegar este tipo de aplicaciones, sirviendo a su vez para explicar con más detalle cómo es posible disponer de un escenario de integración continua con PHP, Azure Web Sites y GitHub.

Así mismo se verá cómo es posible trabajar de forma rápida y sencilla con WordPress, Drupal o Joomla.

Almacenamiento en la nube – SQL, NoSQL

Durante esta sesión se describirán las diferentes opciones de almacenamiento que están disponible en la nube, tanto base de datos relaciones, SQL Database y MySQL, como base de datos NOSQL como Windows Azure Table Storage, MongoDB o Cassandra.

De forma práctica podrá verse un ejemplo de cómo es posible trabajar con MongoDB, desplegado en una máquina virtual o haciendo uso de MongoDB como servicio.

Big Data y Hadoop

No se puede negar que Big Data y Hadoop son términos de moda en el mundo de IT, pero ¿sabes lo que realmente pueden aportar a tu organización? Y, aún más importante, ¿cómo podrías implementarlo dentro de tu ecosistema?

Durante esta sesión realizará una introducción a Big Data y Hadoop y de cómo es posible sacarle el máximo rendimiento a estas dos tecnologías dentro de nuestra organización.

Desarrollo de backends para el desarrollo de aplicaciones móviles

Aplicaciones para Android, Windows Phone, iPhone, iPad, Windows 8… casi todas tienen en común que generalmente necesitan de servicios de backend para ciertas funcionalidades; almacenamiento, notificaciones push, envíos de SMS, seguridad con diferentes proveedores de identidad etc… Durante esta sesión hablaremos de Mobile Services, una tecnología que permite disponer de forma rápida y sencilla de servicios de backend que pueden ser utilizados desde cualquiera de los dispositivos mencionando anteriormente, ya que además de ofrecer un API REST de uso dispone de SDKs propios de cada plataforma que simplifica su utilización.

Saludos

Unai

EF 6: Pluralization Service ahora es un servicio público

2013-01-08T00:00:16Z

Esta ‘pequeña feature’ era algo que tenía en mente hacer desde hace tiempo, después de otros pull request con features y pequeños arreglos, he podido sacar un rato y realizar la implementación del mismo como podéis ver en este change set. La idea es básicamente poder tunear el servicio que se encarga de realizar la singularización y pluralización de nuestras entidades, por ejemplo para decidir por convención el nombre de una tabla. En realidad, este servicio es utilizado principalmente por PluralizingTableNameConvention y PluralizingEntitySetNameConvention para realizar su trabajo. Hasta ahora, es clase no era pública y su uso estaba fijado por las convenciones anteriores, no teniendo ninguna forma de cambiar la implementación del mismo. A lo largo de las siguientes líneas os contaré los cambios realizados y lo que podremos hacer en la siguiente versión de EF.

Haciendo el servicio público

Lo primero es crear el contrato para este servicio, que como podéis ver a continuación es tan sencillo como lo siguiente:

    public interface IPluralizationService
    {
        /// <summary>
        ///     Check if a word is plural.
        /// </summary>
        /// <param name="word">The word to check.</param>
        /// <returns>True if word is plural; false otherwise..</returns>
        bool IsPlural(string word);

        /// <summary>
        ///     Check if a word is singular.
        /// </summary>
        /// <param name="word">The word to check.</param>
        /// <returns>True if word is singular; false otherwise.</returns>
        bool IsSingular(string word);

        /// <summary>
        ///     Pluralize a word using the service.
        /// </summary>
        /// <param name="word">The word to pluralize.</param>
        /// <returns>The pluralized word </returns>
        string Pluralize(string word);

        /// <summary>
        ///     Singularize a word using the service.
        /// </summary>
        /// <param name="word">The word to singularize.</param>
        /// <returns>The singularized word.</returns>
        string Singularize(string word);
    }

Este servicio, por defecto, tendrá una implementación basada en lengua inglesa, llamado EnglishPluralizationService, que no es más que la adaptación a este contrato del servicio anterior, por compatibilidad. Para registrar la implementación que queramos usar se ha incluido un nuevo método en DbConfiguration llamado SetPluralizationService, gracias al cuál podremos establecer esta implementación, si es que queremos cambiar la existente. A continuación podemos ver un ejemplo de esto:

    public class OrderContextDbConfiguration
        : DbConfiguration
    {
        public OrderContextDbConfiguration()
        {
            SetPluralizationService(new SpanishPluralizationService());
        }
    }

Un pequeño añadido aprovechando la coyuntura..

Ya metidos en faena, hay una pequeña cosa que podíamos hacer para no obligar a nadie a crear un servicio de pluralización si alguna de las reglas del existente no le convenía o quisiera ‘customizar’ este trabajo. La idea es básicamente permitir al usuario incluir en el servicio de pluralización la definición de una entrada de diccionario, con los correspondientes Singular y Plural, como podemos ver en el siguiente fragmento.

    public class CustomPluralizationEntry
    {
        /// <summary>
        ///     Get the singular.
        /// </summary>
        public string Singular { get; private set; }

        /// <summary>
        ///     Get the plural.
        /// </summary>
        public string Plural { get; private set; }

        /// <summary>
        ///     Create a new instance
        /// </summary>
        /// <param name="singular">A non null or empty string representing the singular.</param>
        /// <param name="plural">A non null or empty string representing the plural.</param>
        public CustomPluralizationEntry(string singular, string plural)
        {
            Check.NotEmpty(singular, "singular");
            Check.NotEmpty(plural, "plural");

            Singular = singular;
            Plural = plural;
        }
    }

Estas entradas de diccionario se pueden establecer en el constructor del servicio de pluralización antes de registrarlo, por ejemplo, ahora utilizando un IDbDependencyResolver, como vemos:

    public class UnityDependencyResolver
        : IDbDependencyResolver
    {
        IUnityContainer _container;

        public UnityDependencyResolver()
        {
            _container = new UnityContainer();

            _container.RegisterType<IPluralizationService>(new InjectionFactory((c) =>
            {
                var pluralizationService = new EnglishPluralizationService(new CustomPluralizationEntry[]
                {
                    new CustomPluralizationEntry("Producto","Productos")
                });

                return pluralizationService;
            }));
        }

        public object GetService(Type type, object key)
        {
            if (_container.IsRegistered(type))
                return _container.Resolve(type, (string)key);

            return null;
        }
    }

Bonus

Bien, una vez hecho público el servicio lo mejor era dar un ejemplo de implementación, por eso, otra de las cosas que he estado haciendo estas vacaciones ha sido la creación de este servicio de pluralización en castellano, aunque por ahora no lo he hecho público puesto que estoy mirando la mejor manera de hacerlo…en cuanto esté os comentaré como podréis utilizarlo….

Espero que os gustara la entrada y, como no, os invito a pasaros por el la página del proyecto en CodePlex y a contribuir de las muchas formas en las que se puede…

Saludos

Unai

EF 6: Buffering versus Streaming

2012-12-19T19:12:14Z

Hace poco se incorporó un change set con un nuevo ‘breaking change’ dentro de la rama principal de Entity Framework. Este ‘breaking change’ se produce por el cambio en el modo de ejecución de las lecturas por parte de nuestras unidades de trabajo, pasando del modo habitual de lectura en streaming con un DbDataReader a un modo buffering, es decir, a la lectura temprana de los datos y al almacenamiento de los resultados en un buffer. A lo largo de esta entrada intentaremos ver desde que supone para nosotros este cambio como desarrolladores, hasta las justificaciones para realizarlo, pasando como no, por algunas piezas de código que nos permitan entender mejor como lo han implementado.

El cambio

Cuando trabajamos con EF generalmente, solemos tener cosas como la siguiente:

            using (var unitOfWork = new UnitOfWork())
            {
                var someenumerable = unitOfWork.Entities;
            }

Y todos tenemos claro que ese enumerador es una consulta diferida, técnicamente por un shaper, la diferencia de este trabajo en EF 6 con respecto a las anteriores estriba en como se hace la materialización de este enumerable. En la versión actual de EF tendremos un data reader que será usado en cada llamada al MoveNext del iterador. Aunque todos sabemos que internamente DataReader funciona con bloques para conjuntos de datos grandes estos se van incorporando a medida que se necesitan, es decir, hay un proceso de streaming de los datos del servidor a cliente. Para ver esto solamente tendríamos que realizar una lectura de un cojunto grande y ver como el BatchStarting y el BatchCompleted sucenden al comienzo de la lectura y cuando hemos iterado por todos los resultado, es decir, para la siguiente consulta, podríamos ver los siguientes valores en nuestro profiler

             var enumerable = unitOfWork.Entities;

             foreach (var item in enumerable)
             {
                  //TODO: Some work here!
             }

             Console.ReadLine();

Comienzo de la lectura

final del bucle

Lógico según lo se sabemos sobre el comportamiento de nuestros data readers ¿ verdad ?. Bien, pues ahora intentamos hacer esto mismo con EF 6 y veremos lo siguiente nada más ejecutar el paso por el primero de los elementos…

La razón es la que comentamos más arriba, en la nueva versión de EF que tendremos el mecanismo de consultas reemplazará el DbDataReader por un BufferedDataReader (System.Data.Entity.Core.Objects.Internal.BufferedDataReader) el cual en realidad no es más que un envoltorio de un DataReader que hace todo la lectura de sus elementos en su inicialización y los almacena en una estructura interna BufferedDataRecord, de ahí el nombre de Buffered, que será usada por el materializador ( shaper ) para crear las distintas entidades.

Aunque esto pueda parecer un mero cambio interno a EF, en realidad no es tan sencillo y supone un breaking change porque tiene un impacto sobre las aplicaciones actuales. De entrada es lógico ver que hay una mayor presión de memoria, aunque sea memoria de generación 0, puesto que estamos duplicando los datos en el proceso de materialización. El segundo motivo es que por ejemplo si se rompe el bucle anterior por cualquier condición en la versión anterior no tendríamos porque haber traído todos los bloques del reader mientras que en EF 6 si habríamos traído todos los bloques del reader. Otro impacto posible lo podemos observar en la llamada a nuestro GetEnumerator, puesto que ahora necesitará más tiempo para completar el trabajo.

Los motivos

Las razones para movernos de un modo Streamed a Buffered se deben principalmente y tal como el equipo ha explicado en el siguiente design meeting a las siguientes razones:

Sql Azure connection resilience: Como todos sabéis, el trabajo con Sql Azure tiene una problemática especial que nos obliga a necesitar en ciertos escenarios de reintentos en nuestro trabajo con EF, Cesar de la Torre escribió hace ya mucho tiempo sobre esto. Dentro de la iniciativa del equipo por hacer más robusto el uso de EF con Sql Azure este cambio es necesario ya que no retarda el uso de una conexión más allá de lo necesario.
El tiempo de uso de una conexión se reduce potencialmente
Ya no es necesario MARS ( obligatorio con lazy loading en la versión actual )

Y si quiero mi antiguo comportamiento

Bien sea por compatibilidad o porque el escenario así lo requiera, en EF tendremos un mecanismo para seguir usando streaming en nuestras consultas, para ello, solamente tendremos que utilizar el método AsStreaming, gracias al cual EF volverá a usar un DbDataReader en lugar del ya mencionado BufferedDataReader. A continuación podemos ver un ejemplo de ello:

                var enumerable = unitOfWork.Entities
                                           .Where(a=>a.Id>0)
                                           .AsStreaming();

Bueno, hasta aquí hemos llegado, espero que todos tengamos en cuenta este cambio si decidimos migrar aplicaciones de EF 5 a EF 6 puesto que tal y como hemos dicho puede tener impacto y producirse situaciones no deseadas sino nos fijamos…

Saludos

Unai

EF 6: Estableciendo las configuraciones de forma automática

2012-12-07T10:07:31Z

La verdad es que no hace muchos días que publiqué un post con este trabajo para todos aquellos, que como yo, consideraran interesante el hecho de disponer de una forma automática de agregar las configuración de nuestro modelo, con el fin de facilitar el trabajo y prevenir ese código repetitivo que solemos ver muy a menudo. Para que no tengamos que recurrir a lo mismo en EF 6, me decidí por hacer un pequeño pull request que pudiera contener esta funcionalidad, ahora, que como ya sabréis todos, Entity Framework es Open Source y, por lo tanto, abierto a que la comunidad pueda contribuir. Los que hayáis pasado alguna vez por el portal del proyecto en Codeplex sabréis que hay multitud de información sobre las diferentes vías de contribución, que no tienen porque ser solamente código, y como hacer estas contribuciones de una forma ordenada y consensuada. La palabra consensuada es importante aquí puesto que por mucho que a nosotros nos parezca importante y válida una contribución esta no tiene por que tener la misma validez para el equipo, por ejemplo, porque la pieza o piezas en las que vayamos a tocar se vayan a rediseñar o, a otra multitud de factores que se nos puedan escapar. El principio Don’t Push Your Pull Request es la norma a seguir dentro del equipo de desarrollo y por lo tanto el primer trabajo que tenemos que hacer es discutir con ellos lo que queremos hacer y por supuesto como lo vamos a hacer, en este caso, la sugerencia de pull request y su discusión la podéis ver aquí.

Bueno, después de ver el feedback y de las guías sobre como les gustaría la aportación, el resultado que ha quedado es este Change Set con la característica comentada anteriormente y, que pasaremos a desgranar ahora mismo.

Carga automática de configuraciones

Bien, esto es lo más básico y a la vez lo más natural de esta característica, puesto que como ya comentamos su primer trabajo es hacer la carga de configuraciones de forma automática, eliminando las típicas líneas repetitivas de carga de configuraciones, que en un proyecto real serán muchas y por lo tanto con un impacto en legibilidad y mantenibilidad. Es decir, lo que nos permitiría es cambiar cosas como esta:

        protected override void OnModelCreating(DbModelBuilder modelBuilder)
        {
            //.. more configurations entries

            modelBuilder.Configurations.Add(new OrderEntityTypeConfiguration());
            modelBuilder.Configurations.Add(new CustomerEntityTypeConfiguration());

            //.. more configurations entries
        }

Por lo siguiente:

        protected override void OnModelCreating(DbModelBuilder modelBuilder)
        {
            modelBuilder.Configurations.AddFromAssembly(Assembly.GetExecutingAssembly());
        }

Visibilidad de tipos y constructores

Para realizar esta carga automática de configuraciones no estamos restringidos a ninguna visibilidad de nuestras clases, ni de sus constructores. De hecho, esto es lo ideal, puesto que estas clases solamente tienen fines de configuración y no están pensadas para ser usadas más que por la infraestructura, parece lógico que pudiéramos escribirlas como por ejemplo en la siguiente de forma no pública y con un constructor privado.

   class OrderEntityTypeConfiguration
        :EntityTypeConfiguration<Order>
    {
        private OrderEntityTypeConfiguration()
        {
            this.Property(o => o.Total).HasPrecision(12, 2);
        }
    }

Configuraciones en jerarquía

La última de las características de este trabajo, es el soporte a jerarquías de configuraciones, es decir, que nuestros tipos de configuración no implementen de forma directa EntityTypeConfiguration<>. Un ejemplo de este tipo de escenarios podría ser algo como lo siguiente:

    abstract class CommonEntityTypeConfiguration<TEntity>
        :EntityTypeConfiguration<TEntity> where TEntity:class
    {
        public CommonEntityTypeConfiguration()
        {
            string tableName = PrefixTableName(typeof(TEntity).Name);

            this.ToTable(tableName);

        }

        string PrefixTableName(string name)
        {
            return "tbl" + name;
        }
    }

Si observa, lo que hemos hecho, con meros fines de ejemplo, es hacer una pequeña base para nuestras configuraciones que nos agrega un prefijo tbl a los nombres de nuestras tablas. Esta configuración base la podríamos utilizar en todas aquellas entidades que nos interesaran que ya tuvieran OOB esta característica.

    class OrderEntityTypeConfiguration
        : CommonEntityTypeConfiguration<Order>
    {
        private OrderEntityTypeConfiguration()
        {
            this.Property(o => o.Total).HasPrecision(12, 2);
        }
    }

Pues bien, como hemos dicho, aún en estas situaciones nuestro AddFromAssembly seguirá funcionando perfectamente y cargando nuestras configuraciones de la forma correcta, excluyendo tipos abstractos y definiciones de tipos genéricos…

Bueno, espero que os resulte interesante esta novedad que tendremos en EF 6 y espero, que esta contribución os sea de la mayor utilidad posible, con ese fin está hecha…

saludos

Unai

Recursos, mensajes de excepción y otras cadenas…..

2012-11-26T23:41:15Z

Bueno, imagino que después de leer el título le quedará bastante claro de lo que vamos a hablar en este pequeño post. A lo largo de este tiempo he visto muchas y diversas formas de manejar los típicos mensajes de excepción y otros elementos localizables de nuestro código ( sin hablar nada de UI en este caso ), unas mejores y otras peores. Con la llegada de .NET y los recursos incrustados, muchos de los inconvenientes tradicionales que teníamos se vieron resueltos. Elementos como el fallback en la resolución de la cultura, los conceptos de culturas específicas y neutras, sin duda, facilitaron enormemente nuestro trabajo. El consumo de estos recursos incrustados de .NET, por regla general, se realiza utilizando las propiedades de la clase que se nos genera automáticamente por cada uno los archivos de recursos [ recuerde que por defecto estos ficheros tienen asociada una custom tool, ResXFileCodeGenerator, para la generación de esta clase ]. Elementos habituales podrían ser, algunos como los siguientes:

   1:          throw new InvalidOperationException(Resource.AnyExceptionMessageForOperation);

   1:          static bool AnyTryMethod(out string error)

   2:          {

   3:              //....

4:

   5:              error = Resource.AnyMessageToUser;

6:

   7:              //....

   8:          }

Alguno de los problemas con esta forma de trabajo surge por ejemplo cuando queremos hacer estos mensajes parametrizados, puesto que tendríamos que recurrir a cosas como la siguiente:

   1:          var localizedMessage = string.Format(Resource.AnyMessageToUser, "p0", "p1");

Cuando se utiliza esta entrada de recursos, no hay más remedio que acudir a nuestro mensaje para descubrir si este toma parámetros o no y establecerlos en caso necesario, por no hablar de que la legibilidad podría verse afectada, sin duda. Mecanismos para intentar solventar estos problemas hay muchos y variados pero uno que últimamente me ha gustado y que he seguido ha sido el utilizado por el equipo de EF para hacer la gestión de esta problemática. Mecanismo que se basa en una sencilla plantilla .tt junto a un fichero de recursos que nos permite generar 2 clases fundamentales Strings y Error preparadas para ser utilizadas en el código de una forma más simple y legible que mediante el código por defecto de ResXFileCodeGenerator. De entre algunas de las características que incorpora esta plantilla podemos ver que expone en forma de parámetros los parámetros de las entradas del archivo de recursos, de tal forma que si, por ejemplo, tenemos una entrada con valor “any message for {0} and {1}” esta plantilla nos expondrá en nuestra clase Strings un método similar a lo siguiente:

   1:          public static string AnyMessageToUser(object p0, object p1);

Con lo cual, el uso anterior de esta clave de recurso podría realizarse como, por ejemplo de la siguiente manera:

   1:          var localizedMessage = Strings.AnyMessageToUser("p0", "p1");

La parte de Error, es quizás, más interesante todavía, puesto que nos permite generar a partir de los claves de nuestros ficheros de recurso métodos que devuelvan las excepciónes que necesitemos, cuyos tipos se extraen además del mismo archivo de recursos gracias a un pequeño trick con el campo comentarios, puesto que interpretan comentarios como ## ExceptionType=InvalidOperationException como la necesidad de generar un método que devuelva una excepción InvalidOperationException con el mensaje de la misma entrada del recurso. A continuación podemos ver un ejemplo de uno de los mensajes de Error que tenemos en el código de EF

   1:          internal static Exception AutomaticDataLoss()

   2:          {

   3:              return new Migrations.Infrastructure.AutomaticDataLossException(Strings.AutomaticDataLoss);

   4:          }

Bueno, amigo lector, le invito desde aquí a revisar como otros resuelven problemas habituales en nuestro trabajo. En este caso, esta plantilla de la que acabamos de ver es un ejemplo bastante simple de tratar el problema. Aunque hay que tocar un par de cosas para que la misma se pueda utilizar en cualquier proyecto la verdad es que es terriblemente sencilla, por lo que le invito a probarla…

Saludos

Unai

EF Agregando configuraciones de forma automática

2012-11-15T08:48:00Z

Hay ciertas situaciones en las que las convenciones de EF para nuestros mapeos de entidades no nos sirven o bien no nos sirven completamente, un ejemplo de esto es cuando trabajamos con una base de datos existente, dónde, seguramente, la convención del nombre de las tablas ( pluralización en inglés de los nombres de las entidades ) no nos sirva, y así con otras muchas convenciones. En estas situaciones, es más que seguro que tengamos que hacer uso de las configuraciones personalizadas, instancias de EntityTypeConfiguration<> y ComplexTypeConfiguration<>. En estos casos, cuando el modelo es grande, el aspecto que tendrá nuestro OnModelCreating será un poco esperpéntico, algo similar a lo siguiente:

protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
          modelBuilder.Configuration.Add(new Entiti1Configuration());
          modelBuilder.Configuration.Add(new Entiti2Configuration());
          modelBuilder.Configuration.Add(new Entiti3Configuration());
          modelBuilder.Configuration.Add(new Entiti4Configuration());
          ...
          ...
          ...
          modelBuilder.Configuration.Add(new Entiti20Configuration());
          modelBuilder.Configuration.Add(new Entiti21Configuration());
          modelBuilder.Configuration.Add(new Entiti22Configuration());
          modelBuilder.Configuration.Add(new Entiti23Configuration());
}

El problema de este tipo de códigos, amén del matenimiento, es la poca legibilidad del mismo, donde por ejemplo, nos costaría encontrar si una entidad está o no mapeada. Solventar este problema y hacer un código más legible y facilitar la vida al desarrollador no es difícil, ya que en realidad lo único que estamos haciendo ahí es configurar todas las clases de un determinado tipo, algo por lo tanto muy fácil de automatizar. En el siguiente repositorio de GitHub he implementado una posible solución para estos problemas, que nos permite cambiar este código anterior por algo como lo siguiente:

protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
        modelBuilder.Configurations.Add(ConfigurationSolver.FromThisAssembly());
}

o, si tenemos los mapas de configuración en otro ensamblado, podríamos hacer:

protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
        modelBuilder.Configurations.Add(ConfigurationSolver.FromNamedAssembly("The_Assembly_With_Configs"));
}

Espero que os guste y, sobre todo, que os sea de utilidad…

Saludos

Unai

EF 6 Alpha: Custom Conventions

2012-11-03T11:57:00Z

El tema de las convenciones personalizadas para el modelo de Code First sin duda ha sido una de las cosas que más echamos de menos en EF, de hecho, durante alguna de las betas estas posibilidades estaban incluidas como en su día vimos en algún post. De entre las distintas novedades de esta versión preliminar de EF 6 podemos destacar la vuelta al ruedo de estas features, aunque ahora con una implementación, en mi opinión, mucho más acertada. A lo largo de la siguiente entrada intentaremos darle un vistazo a estas nuevas posibilidades, si lo desea, también puede leer el walkthough que el equipo de ADO.NET tiene sobre este tema.

Introducción

Todas las convenciones de EF, están basadas en la siguiente interface, IConfigurationConvention:

    [ContractClass(typeof(IConfigurationConventionContracts<,>))]
    public interface IConfigurationConvention<TMemberInfo, TConfiguration> : IConvention
        where TMemberInfo : MemberInfo
        where TConfiguration : ConfigurationBase
    {
        void Apply(TMemberInfo memberInfo, Func<TConfiguration> configuration);
    }

Esta interface, como observará tiene dos parámetros genéricos TMemberInfo y TConfiguration, que nos permite establecer, por un lado con TMemberInfo si la configuración es para un tipo o para una propiedad y en ultimo lugar a que elemento en concreto se aplica, para el caso de las propiedades ConfigurationBase tiene un jerarquía similar a esta:

ConfigurationBase

-> Property Configuration

->NavigationPropertyConfiguration

->PrimitivePropertyConfiguraiton

    -> BinaryPropertyConfiguraiton

    -> DateTimePropertyConfiguration

     -> ….

Dicho esto, para crear por ejemplo una convención que afecte a propiedades de tipo DateTime tendríamos que implementar una clase como la siguiente:

     public class DateTimeIsMappedToSqlServerDateTime2
        :IConfigurationConvention<PropertyInfo,DateTimePropertyConfiguration>
    {
        public void Apply(PropertyInfo memberInfo, Func<DateTimePropertyConfiguration> configuration)
        {
           
        }
    }

Por supuesto, dentro del método Apply tendríamos que establecer que queremos en la convención, si se fija, el delegado configuration nos permite obtener la configuración actual de esa propiedad, con lo cual, podríamos ver/modificar la misma. En este caso optaremos por hacer lo mismo que el el walkthoug, puesto que me parece muy ‘real’ el hecho de adaptar el tipo de datos en Sql Server a datetime2 para estas propiedades.

    public class DateTimeIsMappedToSqlServerDateTime2
        :IConfigurationConvention<PropertyInfo,DateTimePropertyConfiguration>
    {
        public void Apply(PropertyInfo memberInfo, Func<DateTimePropertyConfiguration> configuration)
        {
            //get the current datetimepropertyconfiguration
            var dateTimeConfiguration = configuration();

            if (dateTimeConfiguration.ColumnType == null)
                dateTimeConfiguration.ColumnType = "datetime2";
        }
    }

Por supuesto, usted puede revisar el miembro memberInfo para decidir a que propiedades se aplica, por ejemplo, le podría interesar solo aplicar esta convención a las propiedades cuyo nombre por ejemplo acaben con un postfijo determinado, aunque esto, en mi humilde opinión no es algo que me guste para nada. Las convenciones a nivel de entidad, son prácticamente iguales, con la salvedad de que lógicamente configuran aspectos de la entidad y no de las propiedades, por ejemplo, la convención de que la propiedad Id sea la clave primaria de una entidad podría haberse escrito así.

    public class IdPropertyIsPrimaryKeyConvention
       : IConfigurationConvention<Type, EntityTypeConfiguration>
    {

        public void Apply(Type memberInfo, Func<EntityTypeConfiguration> configuration)
        {
            var entityTypeConfiguration = configuration();

            var idProperty = memberInfo.GetProperty("Id", BindingFlags.Public | BindingFlags.Instance);

            if (idProperty != null)
                entityTypeConfiguration.Key(idProperty);
        }
    }

Bien, una vez que tenemos definidas nuestras convenciones, para agregarla usaremos la propiedad Conventions, que ya es conocida de nuestros DbContext, con la diferencia que ahora dispone de métodos para incluir convenciones y no solamente para eliminarlas. De hecho, incluso me permite establecer el orden de ejecución de las mismas.

      modelBuilder.Conventions.Add<IdPropertyIsPrimaryKeyConvention>();

Con el fin de simplificarnos la vida, el equipo de ADO.NET nos ha creado una pequeña clase LightweigtConvention con la cual podremos establecer convenciones sin necesidad de escribir una nueva clase para las mismas. Esta clase no es más que una implementación de IConventionConfiguration para tipos y propiedades que hace uso de una clase, EntityConventionConfiguration para agregar convenciones mediante un API fluent.

    public class EntityConventionConfiguration
    {
        private readonly List<Func<Type, bool>> _predicates = new List<Func<Type, bool>>();
        private Action<LightweightEntityConfiguration> _configurationAction;
        private PropertyConventionConfiguration _propertyConfiguration;

        internal EntityConventionConfiguration()
        {
        }

        internal Action<LightweightEntityConfiguration> ConfigurationAction
        {
            get { return _configurationAction; }
        }

        internal List<Func<Type, bool>> Predicates
        {
            get { return _predicates; }
        }

        internal PropertyConventionConfiguration PropertyConfiguration
        {
            get { return _propertyConfiguration; }
        }

        /// <summary>
        /// Filters the entity types that this convention applies to based on a
        /// predicate.
        /// </summary>
        /// <param name="predicate">A function to test each entity type for a condition.</param>
        /// <returns>
        /// The same EntityConventionConfiguration instance so that multiple calls can
        /// be chained.
        /// </returns>
        public EntityConventionConfiguration Where(Func<Type, bool> predicate)
        {
            Contract.Requires(predicate != null);

            _predicates.Add(predicate);

            return this;
        }

        /// <summary>
        /// Allows configuration of the entity types that this convention applies to.
        /// </summary>
        /// <param name="entityConfigurationAction">
        /// An action that performs configuration against a <see cref="LightweightEntityConfiguration" />.
        /// </param>
        public void Configure(Action<LightweightEntityConfiguration> entityConfigurationAction)
        {
            Contract.Requires(entityConfigurationAction != null);

            _configurationAction = entityConfigurationAction;
        }

        /// <summary>
        /// Allows further configuration of the convention based on the properties of
        /// the entity types that this convention applies to.
        /// </summary>
        /// <returns>
        /// A configuration object that can be used to configure this convention based
        /// on properties.
        /// </returns>
        public PropertyConventionConfiguration Properties()
        {
            var propertyConfiguration = new PropertyConventionConfiguration();
            _propertyConfiguration = propertyConfiguration;

            return propertyConfiguration;
        }
    }

Utilizando esta clase, por lo tanto, podríamos crear una convención tal y como sigue:

   public class BlogUnitOfWork
        :DbContext
    {
        public IDbSet<Blog> Blogs { get; set; }

        protected override void OnModelCreating(DbModelBuilder modelBuilder)
        {
            modelBuilder.Conventions.Add(entityConventionConfiguration =>
            {
                entityConventionConfiguration.Properties()
                                            .Where(p => p.Name == "Id")
                                            .Configure(lpc => lpc.IsKey());
            });
        }
    }

Puede observar como el trabajo a realizar depende de si configura propiedad o entidad y este está representado por las clases LightweighPropertyConfiguration o LightweighEntityConfiguration.

Bien, pero ¿y si quiero hacer las convenciones con atributos? Pues sencillo, en vez de implementar IConfigurationConvention trabajaremos con AttributeConfigurationConvention, el cual, nos permite indicar que atributo es el que será el atributo marcador, es decir aquel atributo que EF revisará para saber que tiene que aplicar una convención. Para verlo, utilizaremos también el del walkthoug, puesto que al igual que con el DateTime es también bastante habitual. En este ejemplo el objetivo es poder disponer de un atributo, por ejemplo NonUnicodeAttribute que nos permita decorar a las propiedades como no unicode. Pues bien, este atributo será un atributo marcador, es decir, no necesita código de trabajo con EF, por ejemplo igual que así:

    [AttributeUsage(AttributeTargets.Property, AllowMultiple = false)]
    public class NonUnicodeAttribute : Attribute
    {

    }

Bien, ahora que tenemos creado el atributo marcador, solamente tenemos que aplicarle la convención ,tal cual podríamos hacer antes con nuestras PrimitivePropertyConfiguration…

    class NonUnicodeAttributeConvention :
        AttributeConfigurationConvention<PropertyInfo, StringPropertyConfiguration, NonUnicodeAttribute>
    {

        public override void Apply(

            PropertyInfo propertyInfo,

            StringPropertyConfiguration configuration,

            NonUnicodeAttribute attribute)
        {

            if (configuration.IsUnicode == null)
            {
                configuration.IsUnicode = false;
            }
        }
    }

Sencillo ¿verdad?…Bueno, espero poder publicar alguna entrada más sobre EF 6, de hecho hay un par de novedades que me parecen super interesantes.. y me gustaría también sacar algo de tiempo para colaborar un poco con el código, a ver si lo logro…

Saludos

Unai

Azure: AAL + Web API, una mezcla ‘casi’ perfecta

2012-10-31T11:36:40Z

En el post anterior empezamos a ver un poco sobre AAL, y como empezar a trabajar con este simple paquete. En esta ocasión, continuaremos hablando de AAL y de como juntarlo con ASP.NET Web API. Cuando uno diseña sus servicios utilizando Web API uno de los elementos que siempre entran en juego es la autorización en los mismos, de hecho, dándonos un pequeño paseo por la propia Web de ASP.NET Web API podemos ver diferente documentación acerca de este tema. A mayores, por supuesto, buceando en la web podemos obtener diferente información acerca de como realizar los procesos de authenticación, desde API Keys hasta OAuth . Todos estos procesos técnicamente se hacen de una forma o en otra, pero, tienen en común que ninguno externaliza el proceso de autenticación teniendo que incorporar nosotros este dentro de nuestras aplicaciones y por lo tanto, cuando necesitamos diferentes proveedores de identidad la cosa se complica. A lo largo de esta entrada intentaremos ver como construir un servicio de Web API que soporte a usuarios autenticados con diferentes proveedores de identidad como por ejemplo Azure AD, Office 365,ADFS 2, Windows Live, Google, nuestro propio STS etc, de una manera sencilla y sin apenas desarrollo.

Diseño

Una vez marcado el objetivo vamos a ver como realizamos esta tarea. En primer lugar necesitaremos que nuestro servicio disponga de un mecanismo para obtener y validar los tokens en las diferentes peticiones que al mismo se le realicen. Al igual que para el resto de ejemplos que hemos puesto en los enlaces anteriores, el mejor mecanismo para esto parece la creación de un DelegatingHandler. Tal y como podemos ver en la documentación mediante estas piezas podremos agregar procesamiento al pipeline de ejecución de ASP.NET Web API. Por lo tanto, nuestro objetivo es crear un manejador capaz de interceptar nuestro token y validarlo. Por supuesto una vez validado crearemos los correspondientes ClaimsPrincipal en el hilo de ejecución y el contexto Http para que puedan ser usados / revisados por el resto de elementos que componen la petición. Para seguir la norma, utilizaremos la cabecera Authorization como contenedor del token a validar. Una vez dicho esto el esqueleto de nuestra pieza podría ser algo como lo siguiente:

    public class AALMessageHandler
        : DelegatingHandler
    {
        protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
        {
            var authorization = request.Headers.Authorization;

            if (authorization != null && authorization.IsAuthorizationSchema())
            {
                var token = authorization.Parameter;

                if (IsValidToken(token))
                {
                    //set thread principal and http context user
                }

            }

            return base.SendAsync(request, cancellationToken);
        }

        bool IsValidToken(string token)
        {
            //validate the token
        }
    }

Con respecto a la parte de cliente no tenemos que hacer mucho más que en la anterior entrada, si acaso, lo único es ver como convertir nuestro Assertion Credential en un bearer token, pero esto con AAL es tan sencillo como podemos ver a continuación, gracias al método CreateAuthorizationHeader.

            string tenant = ConfigurationManager.AppSettings["tenant"];
            string realm = ConfigurationManager.AppSettings["realm"];

            using(AuthenticationContext context = new AuthenticationContext(tenant))
            {
                var credential = context.AcquireUserCredentialUsingUI(realm);
                
                return credential != null ? credential.CreateAuthorizationHeader() : null;
            }

El resultado de las líneas anteriores es que una vez un usuario es autenticado usado cualquiera de los proveedores de identidad configurados en nuestro Azure Access Control obtenemos un bearer token, representado en una cadena de texto. Un bearer token no es más que un token con la propiedad de que cualquier portador puede usar el token en los otros lugares, es decir, se elimina la necesidad de disponer de material criptográfico ( proof-of-possesion).

La implementacion

Bien, ahora que ya tenemos más o menos claro como haremos nuestro trabajo llega la hora de la implementación. Empezaremos por la parte más sencilla que es la parte de cliente, en la que además de las líneas anteriores pare obtener un token con AAL simplemente haremos una petición a un servicio de Web API cualquier, por ejemplo GET /API/Some.

            //get the bearer token using AAL
            var token = CreateToken();

            if (token != null)
            {
                //create http client
                var httpClient = HttpClientFactory.Create();
                httpClient.BaseAddress = new Uri("the base address of your web api project");

                //add default media type 
                httpClient.DefaultRequestHeaders.Accept.Add(
                    new MediaTypeWithQualityHeaderValue("application/json"));

                //add the token
                httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Authorization", token);

                //perform the request
                var request = new HttpRequestMessage(HttpMethod.Get, "api/some");

                httpClient.SendAsync(request)
                        .ContinueWith((t) =>
                        {
                            if (t.Result.IsSuccessStatusCode)
                            {
                                var content = t.Result.Content.ReadAsAsync<IEnumerable<string>>().Result;

                                //display the secret content...
                            }
                        }, TaskContinuationOptions.OnlyOnRanToCompletion);
            }

Del código anterior, la nota a destacar es el uso de la cabecera con el token recuperado de la autenticación del usuario. Cabecera que viajará en todas las peticiones realizadas con nuestro HttpClient. En el caso del servidor, del esqueleto anterior tenemos que hacer dos trabajos fundamentales. La validación del token y el establecimiento de las credenciales recuperadas. Empezemos por la primera de las tareas. Gracias a AAL, la validación de un token es casi tan sencilla como la obtención del mismo, puesto que solamente tendremos que realizar lo siguiente:

         //if token is bearer remove text 'Bearer '

          if ( token.StartsWith("Bearer ") )
                token =token.Substring(7);

      var tenant = ConfigurationManager.AppSettings["tenant"];

            var authenticationContext = new AuthenticationContext(tenant);
            authenticationContext.Options = options;

            principal = authenticationContext.AcceptToken(token);

Antes de nada, disculpad por el pequeño toque con el texto Bearer del token, pero creí que era más entendible ponerlo así que tratarlo como sería en un código normal por medio de algún método de sanitización. Por supuesto, al método anterior tendremos que indicarle cuales son las opciones de autenticación, mediante nuestro objeto options, el cual podría ser algo similar a lo siguiente:

            var certString = ConfigurationManager.AppSettings["CertificateForAAL"];
            var certificate = new X509Certificate2(Convert.FromBase64String(certString));
            var options = new AuthenticationOptions();
            options.Audiences.Add(audience);
            options.Issuer = tenant;
            options.SigningCredential = new X509CertificateCredential(audience, certificate);

Por supuesto, el certificado seleccionado, está dado de alta en el portal de ACS en la sección Certificates and Keys, como se ven en la siguiente imagen.

El casi

Umm. el casi. Bueno, el primer motivo por el que esto no está perfecto es porque AAL solamente está compilada para WIF 3.5 y por lo tanto tendremos esta dependencia. Esto es una pena si trabajamos en VS 2012 y .NET 4.5 puesto que los elementos de Microsoft.IdentityModel ya los tendremos incluídos como hemos dicho ya muchas veces. A mayores, me queda por jugar un poco con el api de cliente para otras plataformas para ver como está y de verdad darle una nota sobresaliente… amén de que estamos en beta aún :-(.

Bueno, como siempre, espero que os sea de utilidad…

saludos

Unai

Home Realm Discovery en MVC 4 y Identity and Access Tool

2012-10-25T18:45:46Z

En una anterior entrada, no muy lejana la verdad, vimos como configurar nuestro sitio construído en MVC 4 contra un ACS de Windows Azure para lograr la externalización de la autenticación y tener un modelo basado en claims de una forma terriblemente sencilla. Leyendo el blog de V Bertocci veo que la liberación de la RTM de la herramienta Identity and Access Tool incluye la posibilidad de que el proceso de Home Realm Discovey se pueda realizar nuestro propio sitio web en vez de tener la página por defecto para ese namespace en Windows Azure, y así, lograr una experiencia más agradable al usuario y un mismo diseño para nuestra web y esta vista. El proceso para realizar esto es realmente sencillo, no voy a volver a realizar los paso comunes a la anterior entrada, la dejor para su lectura. Lo único que haremos es fijarnos como ahora, en esta nueva versión de la herramienta disponemos de una opción para crear un controlador y una vista para tener el HRD en nuestro sitio, como acabamos de comentar.

Esta opción, que podemos ver en la imagen de la derecha nos permitirá seleccionar tanto el nombre del controlador como de la acción que queremos que hagan el trabajo. Una vez seleccionada, al aceptar el paso veremos como una serie de elementos son agregados a nuestro sitio MVC 4, concrétamente los siguientes:

Un nuevo controlador, por defecto llamado HrdAuthenticationController
Una nueva accion al controlador anterior llamado Login
Una vista para la acción Login
Un script de javascript llamado HrdAuthentication.js

A continuación, haremos un breve repaso de que contiene cada uno de estos elementos. En primer lugar el controlador como veremos es realmente sencillo, puesto que su código únicamente contiene lo siguiente.

    public class HrdAuthenticationController : Controller
    {
        [AllowAnonymous]
        public ActionResult Login()
        {
            ViewBag.MetaDataScript = "https://geeksms.accesscontrol.windows.net/v2/metadata/identityProviders.js?protocol=wsfederation&realm=http://localhost:13021/&version=1.0&callback=ShowSigninPage";
            return View("~/Views/HrdAuthentication/Login.cshtml");
        }
    }

Como puede observar, no hay nada en especial, solamente la entrada de nuestro ViewBag MetaDataScript el cual contiene la Url de un script js alojado en nuestro ACS en la que hay una callback ( jsonp ) a un función llamada ShowSigninPage. Si buscamos en el javascript HrdAuthentication.js veremos que el contenido del mismo trae precisamente esta función.

// 
// Code generated by Identity and Access VS Package
// 

function ShowSigninPage(IPs) {
    $.each(IPs, function (i, ip) {
        $("#IPDiv").append('<a href="' + ip.LoginUrl + '">' + ip.Name + '</a><br/>');
    });
};

Fíjese como es en esta función dónde se definen como se construyen los enlaces a los diferentes Identity Providers y por lo tanto, podría ser un punto de toque al querer estilizar nuestra visa. Para terminar, el código de la vista también es terriblemente sencillo, puesto que solamente incorporar los dos js mencionados anteriormente, amén del div IPDiv usado.

@*
Code generated by Identity and Access VS Package
*@

<hgroup class="title">
    <h1>Log in</h1>
    <h2> using one of the identity providers below</h2>
</hgroup>

<div id="IPDiv"/>

@section Scripts {
    @Scripts.Render("~/scripts/HrdAuthentication.js");

    <script src="@ViewBag.MetaDataScript" type="text/javascript"></script>
}

Sencillo verdad? y todo sigue funcionando perfectamente.

Ha sido una entrada pequeña, pero creo que muy interesante este pequeño descubrimiento…

Saludos

Unai

Azure: Windows Azure Authentication Library

2012-10-22T16:23:42Z

Como seguro que todos los que leéis mi blog sabréis, el manejo de la identidad es un tema que me apasiona y sobre el que ya he escrito mucho. De hecho, ahora mismo me encuentro en fase de preparación sobre un libro acerca del manejo de la identidad, que espero en poco tiempo esté a vuestra disposición de forma gratuita. Pues bien, desde hace un tiempo para aquí sobre este tema se ha avanzado mucho en plataforma Microsoft, tanto que a veces no damos ni seguido ciertos elementos, como por ejemplo era mi caso con AAL ( Azure Authentication Library), por eso, para intentar remediar este inconveniente, empezaré una serie de post acerca de este temática que nos permitan ver todo el trabajo que el equipo de Windows Azure está haciendo sobre esto, centrándonos especialmente en los siguientes puntos

Azure Authentication Library

AAL, es básicamente un paquete de NuGet que nos habilita un serie de ensamblados para realizar alguna de las siguientes tareas:

Gestión de tokens, generalmente server to server

Autenticación con Azure AD, Azure ACS y ADFS 2.0 y otros proveedores

Validación de tokens

Como en casi todo lo que tenga que ver con la identidad y su gestión, una de las principales fuentes ( a mayores de lo que yo mismo pueda ir masticando y contando en este blog ) es el blog de Vittorio Bertoci, el cual recomiendo encarecidamente puesto que, tal y como acabo de decir, es siempre una de mis fuentes principales de información y aprendizaje.

Windows Azure Active Directory

El segundo de los temas que trataremos es Azure Active Directory junto con dos elementos fundamtales como Graph API y Web Single Sign-ON.

Con el fin de que esta entrada no se quede en una mera entrada informativa, no me parece muy adecuado, empezaremos por sentar las bases de AAL y desgranar algunos conceptos.

AAL

¿Que es AAL y para que sirve? Aunque, ya lo explicamos un poco en las líneas anterior hay una frase de Vittorio que creo que da una buena explicación de que es y para que no sirve esta nueva librería.”AAL viene a dar solución a algunas de las tareas que los desarrolladores necesitan para manejar la autenticación;asumiendo para ello que no tenemos un profundo conocimiento del protocolo en juego”. Para utilizar AAL solamente tenemos que instalar el paquete Windows Azure Authentication Library BETA gracias al cual incorporaremos a nuestro proyecto la librería Microsoft.WindowsAzure.ActiveDirectory.Authentication.dll cuyo contenido puede verse de forma resumida en la siguiente imagen.

Con el fin de empezar con un pequeño detalle que nos muestre alguna de sus características haremos un pequeño ejemplo en una aplicación de Windows Forms terriblemente sencilla, tanto que lo único que tendremos es un boton con el siguiente manejador.

           using (var context = new AuthenticationContext("https://identity45.accesscontrol.windows.net"))
           {
                var credentials = context.AcquireUserCredentialUsingUI("urn:geeksmsaalsample");
           }

Dónde “https://identity45.accesscontrol.windows.net” representa el namespace de nuestro servicio de Azure Access Control Service y “urn:geeksmsaalsample” es el realm de nuestra aplicación. Si simplemente con eso ejecutamos nuestra aplicación veremos como se nos mostrará una pequeña ventana que contendrá el siguiente mensaje de error:

Este mensaje de error se debe a la inexistencia en la configuración de nuestro namespace de access control service de un RP con este REALM. Para arreglarlo nos vamos a nuestra configuración de Azure y creamos un nuevo Relay Party, en nuestro ejemplo tan simple como se ve a continuación.

Una vez creado, ahora si se nos presentarán los diferentes proveedores de identidad configurados en Azure ACS para esta nueva RP y nos podremos autenticar de esta forma tan sencilla utilizando distintos proveedores tal y como se ven en las siguientes imagenes. Aunque no lo hemos comentado, en el paso anterior hay que especificar las reglas de este RP, en nuestro ejemplo hemos puesto un passthrough de los proveedores de identidad configurados.

Tal y como observá, el proceso que hemos hecho es idéntico al proceso de dar de alta Access Control Service para un proyecto web ahora en un cliente rico de una manera insultantemente sencilla. Es más, si observa en el tipo de resultado AssertionCredential este nos permite generar un token para ser utilizado en servicios OAuth o para enviar este token a nuestros servicios, por ejemplo web api,que después, podrán validar también utilizando este mismo paquete.

            using (var context = new AuthenticationContext("https://identity45.accesscontrol.windows.net"))
            {
                //authenticate and return credentials
                var credentials = context.AcquireUserCredentialUsingUI("urn:geeksmsaalsample");

                if (credentials != null) //the user is logged!
                {
                    //get token to use in com to server
                    var token = credentials.CreateAuthorizationHeader();
                }
            }

Bueno, aquí lo dejamos, si le ha gustado, no se preocupe porque pronto volveremos al ataque con más y esperemos que mejor…

Saludos

unai

Windows Azure Storage Account Monitoring and Logging

2012-10-16T21:45:00Z

Aunque era algo que ya teníamos en el antiguo portal de Windows Azure, sin duda, una de las cosas más interesantes que nos ofrece la nueva versión es la facilidad para manejar la monitorización de los distintos elementos disponibles, entre ellos las cuantas de Storage. Como puede observar en la siguiente imagen, la interfaz nos permite de una forma sencilla habilitar la monitorización para los diferentes elementos de un storage ( blob, queues y tables ). En ocasiones, disponer de el portal de azure como herramienta de trabajo principal no es posible, imagine que usted esta usando la infraestructura de azure para terceros y que desea en sus propias herramientas habilitar y ver toda esta información de monitorización. En estos casos, necesitamos de un mecanismo para poder habilitar de forma programática la configuración de monitorización, y, por supuesto, también necesitaremos un mecanismos para ver los diferentes valores de las métricas de esta configuración.

Por suerte, todo lo que tenemos disponible en el portal lo tenemos disponible nosotros, puesto que en teoría este portal está construido con el mismo API que nosotros tenemos a nuestra disposición. Por lo tanto vamos a intentar realizar dos pasos, configuración de la monitorización y revisión de las métricas sin necesidad de utilizar el portal de azure. por supuesto el código es meramente demostrativo, como casi siempre en los posts, y tendrá muchas posibilidades de mejora, pero ya le queda a usted estimado lector para ganarse su trabajo;

Configuración de la monitorización

Para realizar la configuración de la monitorización utilizaremos uno de esos N API Rest que Azure nos pone a nuestra disposición, en concreto el API rest referido a los servicios de Blob, Queues y/o Tables, dependiendo de que monitorización querramos habilitar. En el siguiente enlace puede ver el caso concreto del servicio de blob Set Blob Service Properties gracias al cual podremos hacer este trabajo. En realidad el API para los diferentes elementos solamente presenta cambios en la url ( los segmentos blob,queues o tables dependiendo del servicio ) y el modo de autenticación.

Según el método mencionado anteriormente, para habilitar la configuración solamente tendremos que realizar una petición PUT a laa url .blob.core.windows.net/?restype=service&comp=properties">.blob.core.windows.net/?restype=service&comp=properties">.blob.core.windows.net/?restype=service&comp=properties">.blob.core.windows.net/?restype=service&comp=properties">http://<account-name>.blob.core.windows.net/?restype=service&comp=properties

utilizando un cuerpo de mensaje similar al siguiente fragmento (extraído del enlace anterior )

<?xml version="1.0" encoding="utf-8"?>
<StorageServiceProperties>
    <Logging>
        <Version>version-number</Version>
        <Delete>true|false</Delete>
        <Read>true|false</Read>
        <Write>true|false</Write>
        <RetentionPolicy>
            <Enabled>true|false</Enabled>
            <Days>number-of-days</Days>
        </RetentionPolicy>
    </Logging>
    <Metrics>
        <Version>version-number</Version>
        <Enabled>true|false</Enabled>
        <IncludeAPIs>true|false</IncludeAPIs>
        <RetentionPolicy>
            <Enabled>true|false</Enabled>
            <Days>number-of-days</Days>
        </RetentionPolicy>
    </Metrics>
    <!-- The DefaultServiceVersion element can only be set for the Blob service and the request must be made using the 2011-08-18 version -->
    <DefaultServiceVersion>default-service-version-string</DefaultServiceVersion>
</StorageServiceProperties>

Pues bien, vamos a intentarlo:

Para generar el XML anterior utilizaremos una serialización XML de las clases siguientes, las cuales, representan como verá este sencillo fragmento. Por supuesto, usted puede crear cualquier otro mecanismo, para conseguir tener este fragmento de XML. [Si utiliza XmlSerializer no se olvide de utilizar XmlSerializerNamespace para eliminar los namespaces que este serializador incluye por defecto]

    public class StorageServiceProperties
    {
        public Logging Logging { get; set; }
        public Metrics Metrics { get; set; }
    }
    public class Metrics
    {
        public string Version { get; set; }
        public bool Enabled { get; set; }
        public bool IncludeAPIs { get; set; }
        public RetentionPolicy RetentionPolicy { get; set; }
    }
    public class Logging
    {
        public string Version { get; set; }
        public bool Delete { get; set; }
        public bool Read { get; set; }
        public bool Write { get; set; }
        public RetentionPolicy RetentionPolicy { get; set; }
    }
    public class RetentionPolicy
    {
        public bool Enabled { get; set; }
        public int Days { get; set; }
    }

Para la petición utilizaremos HttpWebRequest o cualquier API de cliente como HttpClient o RestSharp. En nuestro caso, para no molestar al lector con otras API diferente a las habituales optaremos por el uso de la primera opción, aunque habitualmente haga uso de RestSharp para este tipo de tareas. A lo largo de las siguientes lineas, veremos como realizar la petición solicitada por el API mencionado anteriormente.

            //create the http request and set default headers
            string baseUri = string.Format("http://{0}.blob.core.windows.net/?restype=service&comp=properties", accountName);

            var request = (HttpWebRequest)HttpWebRequest.Create(baseUri);
            request.Headers.Add("x-ms-version", "2009-09-19");
            request.Method = "PUT";

            //set the content length from settings
            var bytes = UTF8Encoding.UTF8.GetBytes(settings);
            request.ContentLength = bytes.Length;

En estas lineas, él único trabajo que hemos realizado es la creación de un request a la dirección dada y seteados los valores de cabeceras como “x-ms-version” obligatorias según la información que el API nos ofrece. El siguiente paso, es establecer la cabecera de authorización, proceso que no es simple como podemos ver en los esquemas de autenticación de Windows Azure pero que resolveremos de una forma terriblemente simple gracias a la clase StorageCredentialsAccountAndKey y a su método SignRequest.

            var storageCredentials = new StorageCredentialsAccountAndKey(accountName,mystorageaccountprimarykey);
            storageCredentials.SignRequest(request);

Bien, ya solamente tenemos que escribir el cuerpo de la petición y obtener la respuesta, y esto, es idéntico a cualquier petición que ya hubiéramos hecho con HttpWebRequest. anteiormente.

            request.GetRequestStream().Write(bytes, 0, bytes.Length);
            

            var response = request.GetResponse();

Consulta de las métricas

A lo largo de las líneas anteriores hemos visto como habilitar la monitorización de una cuenta de storage de una forma simple. Pero, aún nos queda el elemento importante, que no es otro que la recuperación de los valores de las diferentes métricas que hemos habilitado. Como se ha podido imaginar de las líneas anteriores, la activación/configuración se realiza a nivel de servicio ( para blob, queue, tables ) no para la cuenta de storage. Las métricas de estos diferentes servicios las posemos categorizar en los siguientes puntos:

Métricas de transacciones - Expuesta, tal y como se puede ver aquí, en tres tablas fundamentales:

- $MetricsTransactionBlob
- $MetricsTransactionsTable
- $MetricsTransactionsQueue

Métricas de capacidad – Expuestas, tal y como se puede ver aqui, en la siguiente tabla:

- $MetricsCapacityBlob

Para consultar los esquemas de las diferentes tablas de métricas podemos acudir a la MSDN dónde obtendremos la información necesaria. En realidad, no tiene demasiada historia, por lo menos no mucho más que trabajar con cualquier Table Service de Azure. En nuestro caso, por ver un ejemplo, haremos lo siguiente, el mapeo de una entidad para trabajar con $MetricsTransactionsBlob, tal cual nos dice la documentación, y una consulta de todos los contadores usando un TableServiceContext.

            var entitySetName = "$MetricsTransactionsBlob";

            var client = storageAccount.CreateCloudTableClient();

            if (client.DoesTableExist(entitySetName))
            {
                var context = client.GetDataServiceContext();
                var data = context.CreateQuery<StorageMetrics>(entitySetName)
                                .ToList();
            }

      public class StorageMetrics : TableServiceEntity
      {
          public string TotalRequests { get; set; }
          public StorageMetrics() { }
      }

Espero que os haya resultado de interés..

Saludos

unai

Azure Service Bus : Topic Brokered Message

2012-10-09T20:26:00Z

En las entradas anteriores ( I,II y III ) vimos una pequeña introducción a las colas de Service Bus y ya empezamos a hablar, ligeramente de los Topics. A lo largo de esta entrada ( en esta ocasión el tema no da para una serie) veremos más detenido el concepto de Topic.

Multiples lectores/subscriptores

Este título es el concepto que define un Topic de la mejor forma. En muchas ocasiones, necesitamos que un mismo mensaje de una cola pudiera ser procesado por múltiples clientes, por ejemplo para que cada uno de ellos le pudiera dar un tratamiento diferente. Por poner un ejemplo, imagínese que está construyendo un sistema de procesado de datos en tiempo real y que cada dato tiene que ser procesado para diferentes tareas, compresión y almacenado, agregación e historización. Si tenemos una cola para realizar todas las tareas será dificil separar las responsabilidades del receptor, en aquellas que hemos definido en nuestra premisa. Sin embargo, si pudiéramos tener diferentes lectores para cada uno de los mensajes podríamos tener un Subscriptor para leer mensajes e historiarlos, otro Subscriptor para leer mensajes y agregarlos y otro Subscriptor más para comprimirlos y almacenarlos así conseguiríamos dividir las responsabilidades en partes simples y por lo tanto más mantenibles. Los topics en poco se diferencian de las colas, de hecho, su API es prácticamente idéntico y disponen casi de las mismas características, tamaños de cola, formateadores, detección de duplicados. A continuación veremos el código necesario para la creación y envió de un mensaje a un Topic.

            // The connection string for namespace manager is stored
            // in Microsoft.ServiceBus.ConnectionString app settings key
            var namespaceManager = NamespaceManager.Create();

            //create topic
            var topicDescription = namespaceManager.CreateTopic("topic");

            //add subscriptions
            var historizationSubscription = namespaceManager.CreateSubscription("topic", "Historization");
            var storeSubscription = namespaceManager.CreateSubscription("topic", "Store");
            var aggregateSubscription = namespaceManager.CreateSubscription("topic", "Aggregate");

Si se para y recuerda el trabajo con las colas observará como es prácticamente idéntico a lo que ya conocíamos de entradas anteriores, con la salvedad de que además de la creación del topic también se ha procedido a la creación de las diferentes subscripciones de las que hablábamos anteriormente. Con respecto al envío de mensajes en este caso no hay nada particular ni diferente respecto al uso de colas.

            var messagingFactory = MessagingFactory.Create();
            var topic = messagingFactory.CreateTopicClient("topic");

            topic.Send(new BrokeredMessage("the content"));

El código para la recepción de mensajes en cada subscripción podría ser algo como lo siguiente:

            var messagingFactory = MessagingFactory.Create();
            var subcriptor = messagingFactory.CreateSubscriptionClient("topic", "Historization");

            var content = subcriptor.Receive().GetBody<string>();

Filtros

En los pasos anteriores hemos visto los elementos fundamentales del trabajo con los topics. Sin embargo no hemos hablado de una característica fundamental para los subscriptores que es la capacidad de filtrar los mensajes que quieren recibir. Por ejemplo, podríamos decidir que el subscriptor de agregación solamente recibiera aquellos mensajes con valores de señales que pudieran agregarse ( SUM,AVG, MAX … ) . Estos filtros, representados por la clase Filter, y más concretamente por SqlFilter, nos permiten “filtrar” en función de las propiedades de los mensajes y usuario. El nombre de SqlFilter viene dado por la posibilidad de utilizar SQL92 como norma para los filtros.

<predicate ::=
{ NOT <predicate> }
| <predicate> AND <predicate>
| <predicate> OR <predicate>
| <expression> { = | <> | != | > | >= | < | <= } <expression>
| <property> IS [NOT] NULL
| <expression> [NOT] IN ( <expression> [, ...n] )
| <expression> [NOT] LIKE <pattern> [ESCAPE <escape_char>]
| EXISTS ( <property> )
| ( <predicate> )
 
<expression> ::=
<constant> 
| <property>
| <expression> { + | - | * | / } <expression>
| { + | - } <expression>
| ( <expression> )

Con el fin de poner un ejemplo podremos ver el siguiente tip, donde se muestra la creación de un filtro para la subscripción y el envío de un mensaje con esta propiedad:

      var aggregateSubscription = namespaceManager.CreateSubscription("topic", "Aggregate", new SqlFilter("RequireAggregate=true"));

            var message = new BrokeredMessage("the content");
            message.Properties["RequireAggregate"] = true;

            topic.Send(new BrokeredMessage("the content"));

Bueno, hasta aquí hemos llegado, creo que no me dejo nada, si es así, hacérmelo saber…

Saludos

Unai

O bruxo mobile

EF 6: Operaciones de migraciones personalizadas

Commands y Windows Azure ServiceBus

EF 6: Command rewriters - I

IDbCommandInterceptor, reescritura de tu SQL

EF 6: Interceptors, segunda iteración

EF 6: Sorpresa, interceptors

Interception

Feedback

EF 6:Nuevas pequeñas grandes cosas..

AddRange

RemoveRange

HasChanges

EF 6: Connection resiliency y azure

IExecutionStrategy

IRetriableExceptionDetector

IRetryDelayStrategy

EF 6: Snack Preview de MapToStoreProcedures en EF 6

Cloud Tour

EF 6: Pluralization Service ahora es un servicio público

Haciendo el servicio público

Un pequeño añadido aprovechando la coyuntura..

Bonus

EF 6: Buffering versus Streaming

El cambio

Los motivos

Y si quiero mi antiguo comportamiento

EF 6: Estableciendo las configuraciones de forma automática

Carga automática de configuraciones

Visibilidad de tipos y constructores

Configuraciones en jerarquía

Recursos, mensajes de excepción y otras cadenas…..

EF Agregando configuraciones de forma automática

EF 6 Alpha: Custom Conventions

Introducción

Azure: AAL + Web API, una mezcla ‘casi’ perfecta

Diseño

La implementacion

El casi

Home Realm Discovery en MVC 4 y Identity and Access Tool

Azure: Windows Azure Authentication Library

Azure Authentication Library

Windows Azure Active Directory

AAL

Windows Azure Storage Account Monitoring and Logging

Azure Service Bus : Topic Brokered Message

Multiples lectores/subscriptores

Filtros