Uso de convenciones en Entity Framework

Antes de adentrarnos en la parte técnica, vamos a repasar qué significa convención. Según la Real Academia Española, las acepciones de convención que aplican en este caso son:

convención. (Del lat. conventĭo, -ōnis).

1. f.Ajuste y concierto entre dos o más personas o entidades.
2. f.Conveniencia, conformidad.
3. f.Norma o práctica admitida tácitamente, que responde a precedentes o a la costumbre.

Así pues la convención es todo aquello que previamente se ha acordado, bien por costumbre (metodología, buenas prácticas, principios, reglas de programación) por decisiones del proyecto, por necesidades funcionales, técnicas, etc.

La convención sobre la configuración (o sus siglas en inglés CoC, Convention over configuration) es un enfoque de desarrollo de software de acuerdo con las convenciones típicas de programación, frente configuraciones programador definido. Permite la creación de software de forma rápida y sencilla, manteniendo los requisitos de software básicos. Este enfoque es conocido como programación por convención.

Este enfoque reduce o elimina la necesidad de que los archivos de configuración facilitando el desarrollo de software y su mantenimiento. Tiene muchas ventajas asociadas para el desarrollador:

• Se reduce el número de decisiones que el desarrollador debe de tomar, limitándose a los casos “no convencionales”.
• Permite desarrollar más rápido porque no es necesario crear código para aquello que ya se basa en convenciones.
• Facilita la curva de aprendizaje en un proyecto ya que cualquier desarrollador que conozca las convenciones puede trabajar de forma fácil y fluida.
• Permite excepciones. Aquellos casos que no se atengan a las normas de convención pueden ser tratados por el sistema de forma diferente, permitiendo flexibilidad a la hora de desarrollar.

No podía faltar un ejemplo que clarifique un poco esto: si tenemos una entidad que se almacena en base de datos, nos gustaría que el nombre de la tabla fuese similar al nombre de nuestra entidad. Si además nuestro modelo tiene 500 entidades nos gustaría que esto fuese automático y no tener que preocuparnos por ello.

Entity Framework viene por defecto con varias convenciones, entre ellas la nomenclatura de las tablas que se crean en base de datos. Sabemos que si creamos una clase “Customer”, la tabla que se creará para almacenar sus datos será “Customers”, es decir, el plural del nombre de nuestra clase. Así pues Entity Framework viene con una regla de convención algo así:

Nombre Clase -> Nombre Tabla =  Pluralizar(Nombre Clase)

Esto nos permite ahorrarnos mucho código ya que podemos definir reglas de comportamiento que sean interpretadas para funcionar de una determinada manera. Este es el funcionamiento de las convenciones en Entity Framework.

Las convenciones están soportadas desde la versión 6 de Entity Framework en adelante. A partir de esta versión podemos hacer uso de ellas para facilitar la tarea de mapear nuestros datos en una base de datos.

La clase Convention

Esta clase se encuentra en el ensamblado EntityFramework.dll bajo en espacio de nombres System.Data.Entity.ModelConfiguration.Conventions. Permite manipular el comportamiento de propiedades y tipos para configurarlos según necesitemos.

Por ejemplo, suele resultar útil que todos los campos del tipo DateTime usen el tipo de datos de SQL Server dateTime2.Para ello podemos crear la siguiente convención:

Así tenemos una clase que hereda de Convention y que configura todos los campos DateTime de nuestro contexto de datos como datetime2:

Agregar convenciones a nuestros contextos de datos

Una vez tenemos creadas nuestras convenciones de datos debemos decirle al contexto (DbContext) que las utilice o que quite convenciones por defecto que Entity Framework usa para configurar los modelos de datos sobre nuestra base de datos. Por ejemplo, el siguiente fragmento de código especifica que se añada nuestra convención para los tipos DateTime y elimina la convención de pluralización de Entity Framework que crea los nombres de tablas en plural:

Al sobrescribir el método OnModelCreating y manipular la estancia de la clase DbModelBuilder, el contexto de datos de Entity Framework alterará su comportamiento para aplicar las convenciones nuevas.

Composición y convenciones

Este mecanismo nos permite, por ejemplo, basar nuestro código en composición en lugar de en herencia. Un ejemplo: si tenemos clases temporales podemos crear una clase que contenga toda la información temporal necesaria y marcar nuestras clases temporales de la siguiente manera:

Una clase que hará las veces de composición, TemporalData. Esta clase contiene toda la información temporal. Una interfaz que permite declarar la propiedad temporal en aquellas clases que queramos marcar como temporales. Por último, una clase temporal que implemente nuestra interfaz. Si no especificamos nada, Entity Framework crearía una tabla para TemporalData. Si queremos que la propiedad Temporal se comporte como un objeto valor y cree columnas en la misma tabla que CustomerDraft podemos definir la siguiente convención:

Por último, agregamos la convención a nuestro contexto de datos:

El resultado en base de datos será el siguiente:

Convenciones para decoradores

Una herramienta importante para desarrollar de forma rápida es usar decoradores, es decir, atributos que marcan clases, propiedades o métodos y que permiten orientar la programación en aspectos. Dicho de manera más sencilla, olvidarnos de Entity Framework y centrarnos en nuestro modelo de clases definiendo en él el comportamiento de persistencia en base de datos.

Poniendo un ejemplo, podemos crear un atributo que pertenezca a nuestro dominio denominado NoPersist y decorar aquellas propiedades que no queramos que se almacenen en base de datos:

Lo primero es declarar nuestro atributo decorador.

Lo siguiente, declarar un tipo de convención que permite trabajar con atributos de .Net:

Heredando de esta clase podemos basarnos en atributos para configurar el comportamiento de persistencia de nuestras clases y codificar una convención que lea nuestro atributo para ignorar la propiedad marcada con dicho atributo:

Entity Framework incorpora un atributo llamado NotMappedAttribute que permite ignorar propiedades por lo que no es necesario implementar uno salvo que no queramos ningún tipo de dependencia con Entity Framework en nuestras entidades. Algo muy recomendable si es posible migrar en un futuro a otro ORM manteniendo el comportamiento por convención.

Descubre cómo SOGETI puede ayudarte con el desarrollo de proyectos de TI.

David Ruiz es Licenciado en Ingeniería informática, con más de 10 años de experiencia orientados al diseño, análisis y desarrollo de soluciones empresariales basadas en tecnologías Microsoft y a la supervisión de equipos de desarrollo, aplicando patrones, estándares y métricas de calidad. Desde 2012 ejerce como arquitecto de software dentro de la Unidad de Soluciones Microsoft de Sogeti España.