enero 2017 – O bruxo mobile

Shadow Properties – Otros ejemplos de uso

La verdad es que ya llevo unas cuantas charlas encima sobre EF Core 1.1 en las que trato de hacer un repaso por encima de las diferentes características nuevas o de como se han implementado las que ya conocíamos de EF 6.X. Por suerte, cada vez tenemos más características que enseñar o más capacidades dentro de las características ya existentes que hacen que estas charlas no sean tan repetitivas.

Una de estas características nuevas que suele llamar la atención es el concepto de Shadow Properties, o propiedades que existirán en nuestro modelo relacional pero no las tendremos «visibles» en nuestro modelo de entidades. Para explicar estas propiedades, casi siempre suelo recurrir al típico ejemplo de propiedades de «fontanería» como por ejemplo los típicos conceptos de UpdatedBy, UpdatedOn. Por lo general este tipo de elementos los queremos como elementos básicos de funcionamiento pero no son importantes a la hora de modelar un problema, por eso nos referimos a ellos como elementos de «fontanería». Incluir estos conceptos resulta de lo más trivial como podemos ver a continuación:

    class Order
    {
        public int Id { get; set; }

        public DateTime OrderDate { get; set; }
    }

    class OrderingContext
        :DbContext
    {
        protected override void OnModelCreating(ModelBuilder modelBuilder)
        {
            modelBuilder.Entity<Order>()
                .Property<DateTime>("UpdatedOn")
                .IsRequired();

            modelBuilder.Entity<Order>()
                .Property<String>("UpdatedBy")
                .IsRequired();
        }
    }

class Order

{

public int Id { get; set; }

public DateTime OrderDate { get; set; }

}

class OrderingContext

:DbContext

{

protected override void OnModelCreating(ModelBuilder modelBuilder)

{

modelBuilder.Entity<Order>()

.Property<DateTime>("UpdatedOn")

.IsRequired();

modelBuilder.Entity<Order>()

.Property<String>("UpdatedBy")

.IsRequired();

}

Fíjese como en nuestro método de configuración del modelo, OnModelCreating, hemos dispuesto dos propiedades nuevas que no tenemos en nuestra entidad. Si hacemos una simple migración podríamos ver como efectivamente EF generará estos elementos en nuestro modelo relacional.

            migrationBuilder.CreateTable(
                name: "Order",
                columns: table => new
                {
                    Id = table.Column<int>(nullable: false)
                        .Annotation("SqlServer:ValueGenerationStrategy", SqlServerValueGenerationStrategy.IdentityColumn),
                    OrderDate = table.Column<DateTime>(nullable: false),
                    UpdatedBy = table.Column<string>(nullable: false),
                    UpdatedOn = table.Column<DateTime>(nullable: false)
                },
                constraints: table =>
                {
                    table.PrimaryKey("PK_Order", x => x.Id);
                });

migrationBuilder.CreateTable(

name: "Order",

columns: table => new

{

Id = table.Column<int>(nullable: false)

.Annotation("SqlServer:ValueGenerationStrategy", SqlServerValueGenerationStrategy.IdentityColumn),

OrderDate = table.Column<DateTime>(nullable: false),

UpdatedBy = table.Column<string>(nullable: false),

UpdatedOn = table.Column<DateTime>(nullable: false)

constraints: table =>

{

table.PrimaryKey("PK_Order", x => x.Id);

});

Por supuesto, y más en este caso que las hemos establecido como requeridas, tenemos que tener la posibilidad de establecer los valores de las mismas. Aunque hay diferentes alternativas y patrones de código para hacer esto relativamente sencillo lo más natural para demostrarlo sería recurrir a nuestro SaveChanges para hacer este trabajo.

        public override int SaveChanges()
        {
            var orderEntries = this.ChangeTracker.Entries<Order>()
                .ToList();

            foreach (var item in orderEntries)
            {
                item.CurrentValues["UpdatedOn"] = DateTime.UtcNow;
                item.CurrentValues["UpdatedBy"] = "Here the identity of current user";
            }

            return base.SaveChanges();
        }

public override int SaveChanges()

{

var orderEntries = this.ChangeTracker.Entries<Order>()

.ToList();

foreach (var item in orderEntries)

{

item.CurrentValues["UpdatedOn"] = DateTime.UtcNow;

item.CurrentValues["UpdatedBy"] = "Here the identity of current user";

}

return base.SaveChanges();

}

Pues bien, aunque las Shadow Properties, se explican muy bien con estos conceptos de fontanería en realidad pueden tener más utilidades. Si hay algo que mucha gente pregunta con respecto a EF 6.X es que ya no existe el concepto de ComplexTypes, que por lo general eran usados como ValueObjects en estilos orientados al dominio. Una forma simple para realizar ValueObjects dentro de EF Core podría ser precisamente con el uso de Shadow Properties. Para ello, veamos un ejemplo simple, que por supuesto tiene detalles que deberían ser revisados y/o mejorados.

Lo primero, será definir una pequeña clase base que nos permita marcar ciertos elementos como Value Objects y por lo tanto que sepa compararlos por su contenido. Para ello, podemos buscar por internet muchos ejemplos de implementaciones, aunque lo más básico ( no lo mejor ) podría ser algo como esto:

    public abstract class ValueObject
    {
        
        protected static bool EqualOperator(ValueObject left, ValueObject right)
        {
            if (ReferenceEquals(left, null) ^ ReferenceEquals(right, null))
            {
                return false;
            }
            return ReferenceEquals(left, null) || left.Equals(right);
        }

        
        protected static bool NotEqualOperator(ValueObject left, ValueObject right)
        {
            return !(EqualOperator(left, right));
        }

       
        protected abstract IEnumerable<object> GetAtomicValues();

       
        public override bool Equals(object obj)
        {
            if (obj == null || obj.GetType() != GetType())
            {
                return false;
            }
            ValueObject other = (ValueObject)obj;
            IEnumerator<object> thisValues = GetAtomicValues().GetEnumerator();
            IEnumerator<object> otherValues = other.GetAtomicValues().GetEnumerator();
            while (thisValues.MoveNext() && otherValues.MoveNext())
            {
                if (ReferenceEquals(thisValues.Current, null) ^ ReferenceEquals(otherValues.Current, null))
                {
                    return false;
                }
                if (thisValues.Current != null && !thisValues.Current.Equals(otherValues.Current))
                {
                    return false;
                }
            }
            return !thisValues.MoveNext() && !otherValues.MoveNext();
        }

       
        public override int GetHashCode()
        {
            return GetAtomicValues()
               .Select(x => x != null ? x.GetHashCode() : 0)
               .Aggregate((x, y) => x ^ y);
        }

        public ValueObject GetCopy()
        {
            return this.MemberwiseClone() as ValueObject;
        }
    }

public abstract class ValueObject

{

protected static bool EqualOperator(ValueObject left, ValueObject right)

{

if (ReferenceEquals(left, null) ^ ReferenceEquals(right, null))

{

return false;

}

return ReferenceEquals(left, null) || left.Equals(right);

}

protected static bool NotEqualOperator(ValueObject left, ValueObject right)

{

return !(EqualOperator(left, right));

}

protected abstract IEnumerable<object> GetAtomicValues();

public override bool Equals(object obj)

{

if (obj == null || obj.GetType() != GetType())

{

return false;

}

ValueObject other = (ValueObject)obj;

IEnumerator<object> thisValues = GetAtomicValues().GetEnumerator();

IEnumerator<object> otherValues = other.GetAtomicValues().GetEnumerator();

while (thisValues.MoveNext() && otherValues.MoveNext())

{

if (ReferenceEquals(thisValues.Current, null) ^ ReferenceEquals(otherValues.Current, null))

{

return false;

}

if (thisValues.Current != null && !thisValues.Current.Equals(otherValues.Current))

{

return false;

}

return !thisValues.MoveNext() && !otherValues.MoveNext();

}

public override int GetHashCode()

{

return GetAtomicValues()

.Select(x => x != null ? x.GetHashCode() : 0)

.Aggregate((x, y) => x ^ y);

}

public ValueObject GetCopy()

{

return this.MemberwiseClone() as ValueObject;

}

Una vez definida esta clase, podemos ya marcar nuestras entidades con la misma, por ejemplo una clase Address, que podríamos escribir como sigue:

    class Address
        :ValueObject
    {
        public string City { get; set; }

        public string ZipCode { get; set; }

        protected override IEnumerable<object> GetAtomicValues()
        {
            yield return City;
            yield return ZipCode;
        }
    }

class Address

:ValueObject

{

public string City { get; set; }

public string ZipCode { get; set; }

protected override IEnumerable<object> GetAtomicValues()

{

yield return City;

yield return ZipCode;

}

¿Donde entre el uso de las Shadow Properties? Pues bien, una de las cosas que restringimos en nuestros Value Objects es el concepto de identidad en contenido. Es decir dos direcciones son iguales si su contenido es el mismo no si una clave de identidad es igual. Sin embargo EF nos obliga a que todas las entidades que mapeemos tengan un clave primaria/identidad. Las Shadow Properties nos permitirán sacar esta «restricción» fuera de nuestra clase Address y sin embargo que EF siga pudiendo funcionar.

En este caso el mapeo podría realizarse como sigue:

        protected override void OnModelCreating(ModelBuilder modelBuilder)
        {
            modelBuilder.Entity<Address>()
                 .Property<int>("Id")
                 .ForSqlServerUseSequenceHiLo("hilo");
        }

protected override void OnModelCreating(ModelBuilder modelBuilder)

{

modelBuilder.Entity<Address>()

.Property<int>("Id")

.ForSqlServerUseSequenceHiLo("hilo");

}

Como hemos visto, el concepto de Shadow Properties nos habilitan más escenarios que el simple de mecanismos de fontanería. En este caso hemos visto otro uso con respecto a la definición de Value Objects pero seguro que se le ocurren muchos más.

Saludos

Unai

Inyeccion de dependencias de .NET Core – #3 TransientAndDispose

Bien, esta será la última entrada por ahora de esta pequeña serie acerca de elementos con los que tenemos que tener cuidado cuando trabajemos con inyección de dependencias en .NET Core. En esta ocasión hablaremos sobre como funciona el ciclo de vida de nuestras dependencias y cuando se liberan los recursos de las mismas. Paria ello, vamos a empezar con la misma clase que hemos utilizado en esta serie, aunque ahora implementando IDisposable.

        public class DependencyClass
            : IDisposable
        {
            public void Dispose()
            {
                Debug.WriteLine("Disposed...");
            }
        }

public class DependencyClass

: IDisposable

{

public void Dispose()

{

Debug.WriteLine("Disposed...");

}

Bien, el sistema de DI de .NET Core nos asegura que la llamada a nuestro método Dispose se realizará una vez que el proveedor finalize su ámbito. Por el código que estoy viendo últimamente, mucha gente tiende a registrar ciertos componentes usando directamente el IServiceProvider que tenemos en nuestro método de configuración, que generalmente vivirá todo el tiempo que viva nuestra aplicación web. Por lo tanto, todas estas dependencias transient seguirán vivas en nuestras aplicaciones, haciendo que la memoria crezca ad infinitum. Vamos a ilustrar este caso con un sencillo ejemplo.

           services.AddTransient<DependencyClass>();


            var provider = services.BuildServiceProvider();
            
            var index = 0;

            while (index < 1000)
            {
                var solved = provider.GetRequiredService<DependencyClass>();

                ++index;
            }

services.AddTransient<DependencyClass>();

var provider = services.BuildServiceProvider();

var index = 0;

while (index < 1000)

{

var solved = provider.GetRequiredService<DependencyClass>();

++index;

}

Si cuando acaba la ejecución de este bucle revisáramos los miembros de nuestro provider veriamos un campo llamado _transientDisposables que mantienen una referencia a las 1000 dependencias que hemos resuelto del contenedor.

Por supuesto, esto no sucede en un ciclo normal de una aplicación ASP.NET Core puesto que las mismas se hacen en un scope que después es limpiado. Vendría ser algo como lo siguiente:

            services.AddTransient<DependencyClass>();
 
            var provider = services.BuildServiceProvider();

            var scopedFactory = provider.GetRequiredService<IServiceScopeFactory>();

            var index = 0;

            while (index < 1000)
            {
                using (var scope = scopedFactory.CreateScope())
                {
                    var solved = scope.ServiceProvider.GetRequiredService<DependencyClass>();
                }

                ++index;
            }

services.AddTransient<DependencyClass>();

var provider = services.BuildServiceProvider();

var scopedFactory = provider.GetRequiredService<IServiceScopeFactory>();

var index = 0;

while (index < 1000)

{

using (var scope = scopedFactory.CreateScope())

{

var solved = scope.ServiceProvider.GetRequiredService<DependencyClass>();

}

++index;

}

El corolario de esta entrada es entonces.. ten cuidado de que proveedor haces la resolución de tus dependencias, ten cuidado que el mismo se libere y todos tus objetos disposables puedan a su vez liberar recursos. Revisa _transientDisposables para obtener posible información de fugas de memoria.

Saludos

Unai

Inyeccion de dependencias de .NET Core – #2 Scoped2Singleton

Continuando con la serie empezada con los deadlock en la inyeccion de dependencias de .NET Core en esta ocasión vamos a hablar de otra práctica erronea como asignar una dependencia de tipo Scope a un componente registrado como Singleton. Empezaremos como siempre ilustrándolo con un pequeño ejemplo, dónde usaremos las mismas clases que en la entrada anterior:

        class SomeClass
        {
            private readonly DependencyClass _dependency;

            public DependencyClass Dependency => _dependency;

            public SomeClass(DependencyClass dependency)
            {
                _dependency = dependency;
            }
        }

        public class DependencyClass
        {
        }

class SomeClass

{

private readonly DependencyClass _dependency;

public DependencyClass Dependency => _dependency;

public SomeClass(DependencyClass dependency)

{

_dependency = dependency;

}

public class DependencyClass

{

}

Estas clases las registraremos como sigue:

            services.AddSingleton<SomeClass>();
            services.AddScoped<DependencyClass>();

1 2	services.AddSingleton<SomeClass>(); services.AddScoped<DependencyClass>();

Como observas, tenemos un componente SomeClass registrado como Singleton pero que depende de DependencyClass que está a su vez registrada como Scoped. El problema de este tipo de registros es que si no pensamos en realidad lo que estamos diciendo podemos pasar por alto que esta dependencia Scoped en realidad se convertirá en Singleton y, por lo tanto, podremos tener muchos problemas si no lo tenemos en consideración. Vamos a comprobarlo agregando el siguiente código después del registro de nuestras dependencias:

var provider = services.BuildServiceProvider();
var scopeFactory = provider.GetRequiredService<IServiceScopeFactory>();

while (true)
{
   using (var scope = scopeFactory.CreateScope())
   {
         var resolved = provider.GetRequiredService<SomeClass>();

         Debug.WriteLine(resolved.Dependency.GetHashCode());
   }
}

var provider = services.BuildServiceProvider();

var scopeFactory = provider.GetRequiredService<IServiceScopeFactory>();

while (true)

{

using (var scope = scopeFactory.CreateScope())

{

var resolved = provider.GetRequiredService<SomeClass>();

Debug.WriteLine(resolved.Dependency.GetHashCode());

}

En el código anterior estamos simulando la creación de diferentes scopes, recuerde que en una aplicación ASP.NET Core cada request sería un nuevo Scope. Si observamos el HashCode de cada elemento Dependency nos será fácil ver que siempre tenemos el mismo valor.

Como hemos dicho al principio, esto no es un bug sino una consideración que tenemos que tener y ser consicente de ella, toda dependencia scope de un singleton se convierte en singleton.

En .NET Core 1.1 tenemos un pequeño flag para indicarle a nuestro sistema de DI que nos avise sobre estos posibles errores. Con el uso de este flag en la situación anterior se lanzaría una excepcion al intentar resolver SomeClass. En el siguiente fragmento podemos ver el codigo completo con el uso de este flag.

        public void ConfigureServices(IServiceCollection services)
        {
            services.AddSingleton<SomeClass>();
            services.AddScoped<DependencyClass>();

            var provider = services.BuildServiceProvider(validateScopes: true);
            var scopeFactory = provider.GetRequiredService<IServiceScopeFactory>();

            while (true)
            {
                using (var scope = scopeFactory.CreateScope())
                {
                    var resolved = provider.GetRequiredService<SomeClass>();

                    Debug.WriteLine(resolved.Dependency.GetHashCode());
                }
            }
          
        }

public void ConfigureServices(IServiceCollection services)

{

services.AddSingleton<SomeClass>();

services.AddScoped<DependencyClass>();

var provider = services.BuildServiceProvider(validateScopes: true);

var scopeFactory = provider.GetRequiredService<IServiceScopeFactory>();

while (true)

{

using (var scope = scopeFactory.CreateScope())

{

var resolved = provider.GetRequiredService<SomeClass>();

Debug.WriteLine(resolved.Dependency.GetHashCode());

}

Saludos

Unai Zorrilla

Inyeccion de dependencias de .NET Core – #1 DeadLocks

A lo largo de esta serie de post que hoy empieza no quiero repetir muchos de los elementos que ya tenemos en la propia documentación oficial de .NET Core. El nuevo portal de documentación Microsoft Docs ya tiene mucha información sobre Quick Starts y los elementos más comunes, por lo que escribir sobre eso creo que no aporta demasiado. Incluso en el libro de introducción a .NET Core puedes ver muchos conceptos y prácticas más allá de estos «comienzos». En esta serie de entradas me gustaría hablar de ciertos aspectos problemáticos o con los que podemos tener problemas si no los tenemos en consideración. Continúa leyendo Inyeccion de dependencias de .NET Core – #1 DeadLocks