EF Core vs EF6: Comparar las versiones de Entity Framework

Contents
Entity Framework
EF Core y EF6
Comparar EF Core y EF6
Portabilidad de EF6 a EF Core
Información general
Portabilidad de un modelo basado en EDMX
Portabilidad de un modelo basado en código
EF6 y EF Core en la misma aplicación
Entity Framework Core
Versiones y planeamiento (plan de desarrollo)
Versiones actuales y planeadas
Proceso de planeamiento de versiones
EF Core 5.0
Plan de alto nivel
Novedades
EF Core 3.0
Nuevas características
Últimos cambios
EF Core 2.2
EF Core 2.1
EF Core 2.0
EF Core 1.1
EF Core 1.0
Actualización desde versiones anteriores
De 1.0 RC1 a RC2
De 1.0 RC2 a RTM
De 1.x a 2.0
Introducción
Tutorial de EF Core
Instalación de EF Core
Tutorial de ASP.NET Core >>
Aspectos básicos
Cadenas de conexión
Registro
Resistencia de la conexión
Prueba
Pruebas con SQLite
Pruebas con InMemory
Configuración de un DbContext
Tipos de referencia que aceptan valores NULL
Crear un modelo
Tipos de entidades
Propiedades de entidad
Claves
Valores generados
Tokens de simultaneidad
Propiedades reemplazadas
Relaciones
Índices
Herencia
Secuencias
Campos de respaldo
Conversiones de valores
Propagación de datos
Constructores de tipos de entidad
División de tablas
Tipos de entidad en propiedad
Tipos de entidad sin llave
Alternancia de modelos con el mismo DbContext
Datos espaciales
Administración de esquemas de base de datos
Migraciones
Entornos de equipo
Operaciones personalizadas
Uso de un proyecto independiente
Varios proveedores
Tabla de historial personalizada
Creación y eliminación de API
Utilización de técnicas de ingeniería inversa (scaffolding)
Consultar datos
Diferencias entre la evaluación de cliente y servidor
Diferencias entre seguimiento y sin seguimiento
Operadores de consulta complejos
Carga de datos relacionados
Consultas asincrónicas
Consultas SQL sin formato
Filtros de consulta global
Etiquetas de consulta
Funcionamiento de las consultas
Guardar datos
Guardado básico
Datos relacionados
Eliminación en cascada
Conflictos de simultaneidad
Transacciones
Guardado asincrónico
Entidades desconectadas
Valores explícitos para propiedades generadas
Implementaciones de .NET compatibles
Proveedores de bases de datos
Microsoft SQL Server
Tablas optimizadas para memoria
Especificación de opciones de Azure SQL Database
SQLite
Limitaciones de SQLite
Cosmos
Trabajo con datos no estructurados
Limitaciones de Cosmos
InMemory (para pruebas)
Escritura de un proveedor de base de datos
Cambios que afectan al proveedor
Herramientas y extensiones
Referencia de la línea de comandos
Consola del Administrador de paquetes (Visual Studio)
CLI de .NET Core
Creación de DbContext en tiempo de diseño
Servicios en tiempo de diseño
Referencia de la API de EF Core >>
Entity Framework 6
Novedades
Versiones anteriores
Actualización a EF6
Versiones de Visual Studio
Introducción
Aspectos básicos
Obtener Entity Framework
Trabajar con DbContext
Descripción de las relaciones
Consulta asincrónica y guardado
Configuración
Basada en código
Archivo config
Resolución de dependencias
Administración de conexiones
Lógica de reintento
Errores de confirmación de transacciones
Enlace de datos
WinForms
WPF
Entidades de autoseguimiento
Tutorial
Registro e intercepción
Rendimiento
Consideraciones sobre el rendimiento (notas del producto)
Uso de NGEN
Uso de vistas generadas previamente
Proveedores
Modelo de proveedor de EF6
Compatibilidad de elementos espaciales con los proveedores
Uso de servidores proxy
Pruebas con EF6
Uso de la simulación
Escritura de duplicados de pruebas propios
Capacidad de prueba con EF4 (artículo)
Crear un modelo
Uso de Code First
Workflows
Con una base de datos nueva
Con una base de datos existente
Anotaciones de datos
DbSets
Tipos de datos
Enumeraciones
Espacial
Convenciones
Convenciones integradas
Convenciones personalizadas
Convenciones de modelo
Configuración de Fluent
Relaciones
Tipos y propiedades
Uso en Visual Basic
Asignación de procedimientos almacenados
Migraciones
Migraciones automáticas
Trabajo con bases de datos existentes
Personalización del historial de migraciones
Uso de Migrate.exe
Migraciones en entornos de equipo
Uso de EF Designer
Workflows
Model-First
Database-First
Tipos de datos
Tipos complejos
Enumeraciones
Espacial
División de asignaciones
División de entidades
División de tablas
Asignaciones de herencia
Tabla por jerarquía
Tabla por tipo
Asignación de procedimientos almacenados
Consultar
Actualizar
Asignación de relaciones
Varios diagramas
Selección de la versión del entorno de ejecución
Generación de código
ObjectContext heredado
Avanzado
Formato de archivo EDMX
Definición de consulta
Varios conjuntos de resultados
Funciones con valores de tabla
Accesos directos del teclado
Consultar datos
Load (Método)
Datos locales
Consultas de seguimiento y no seguimiento
Uso de consultas SQL sin formato
Consulta de datos relacionados
Guardar datos
seguimiento de cambios
Detección de cambios automática
Estado de la entidad
Valores de propiedad
Control de conflictos de simultaneidad
Uso de transacciones
Validación de datos
Recursos adicionales
Blogs
Casos prácticos
Contribuciones
Obtener ayuda
Glosario
Base de datos de ejemplo School
Herramientas y extensiones
Licencias
EF5
Chino simplificado
Chino tradicional
Alemán
Inglés
Español
Francés
Italiano
Japonés
Coreano
Ruso
EF6
Versión preliminar
Chino simplificado
Chino tradicional
Alemán
Inglés
Español
Francés
Italiano
Japonés
Coreano
Ruso
Referencia de la API de EF6 >>
Documentación de Entity Framework
Entity Framework
Entity Framework es un asignador relacional de objetos (O/RM) que permite a los

desarrolladores de .NET trabajar con una base de datos mediante objetos .NET.
Elimina la necesidad de usar la mayoría del código de acceso a datos que los
programadores suelen tener que escribir.

EF Core es una versión ligera, extensible y multiplataforma de Entity Framework.
Entity Framework 6
EF 6 es una tecnología de acceso a datos probada con muchos años de características
y estabilización.
Elección
Descubra qué versión de EF es adecuada en su caso.
Portabilidad a EF Core
Guía sobre la portabilidad de una aplicación existente de EF 6 a EF Core.
EF Core
todo
EF Core es una versión ligera, extensible y multiplataforma de Entity Framework.
Introducción
Crear un modelo
Consultar datos
Guardar datos
Tutoriales
más…

SQL Server
MySQL
PostgreSQL
SQLite
Cosmos
más…
Referencia de API
DbContext
DbSet<TEntity>
más…
EF 6
EF 6 es una tecnología de acceso a datos probada con muchos años de características

y estabilización.
Introducción
Aprenda a acceder a los datos con Entity Framework 6.
Referencia de API
Examine la API de Entity Framework 6, organizada por espacio de nombres.
Comparar EF Core y EF6
08/04/2020 • 9 minutes to read • Edit Online
EF Core
Entity Framework Core (EF Core) es un asignador de base de datos de objeto moderno para .NET. Admite consultas
LINQ, seguimiento de cambios, actualizaciones y migraciones de esquemas.
EF Core funciona con SQL Server o SQL Azure, SQLite, Azure Cosmos DB, MySQL, PostgreSQL y muchas otras
bases de datos a través de un modelo de complemento de proveedor de bases de datos.
EF6
Entity Framework 6 (EF6) es un asignador relacional de objetos diseñado para .NET Framework, pero compatible
con .NET Core. EF6 es un producto estable y compatible, pero ya no se desarrolla activamente.
Comparación de características
EF Core ofrece nuevas características que no se implementarán en EF6. Sin embargo, no todas las características de
EF6 están implementadas actualmente en EF Core.
En las tablas siguientes se comparan las características disponibles en EF Core y EF6. Se trata de una comparación
general en la que no se muestran todas las características ni se explican las diferencias entre una misma
característica en las distintas versiones de EF.
La columna EF Core indica la versión del producto en la que la característica apareció por primera vez.
Creación de un modelo
C A RA C T ERÍST IC A EF 6. 4 EF C O RE
Asignación de clase básica Sí 1.0
Constructores con parámetros 2.1
Conversiones de valores de propiedad 2.1
Tipos asignados sin claves 2.1
Convenciones Sí 1.0
Convenciones personalizadas Sí 1.0 (parcial; n.º 214)
Anotaciones de datos Sí 1.0
API fluida Sí 1.0
Herencia: tabla por jerarquía (TPH) Sí 1.0
Herencia: tabla por tipo (TPT) Sí Planeado para la versión 5.0 (n.º 2266)
Herencia: tabla por clase concreta (TPC) Sí Stretch para la versión 5.0 (n.º 3170) (1)
Propiedades de estado reemplazadas 1.0
Claves alternativas 1.0
Navegaciones de varios a varios Sí Planeado para la versión 5.0 (n.º 19003)
Varios a varios sin entidad de Sí En el trabajo pendiente (n.º 1368)

combinación
Generación de claves: Base de datos Sí 1.0
Generación de claves: Cliente 1.0
Tipos complejos/de propiedad Sí 2.0
Datos espaciales Sí 2.2
Formato de modelo: Código Sí 1.0
Crear modelo desde base de datos: Sí 1.0

Línea de comandos
Actualizar modelo desde base de datos Parcial En el trabajo pendiente (n.º 831)
Filtros de consulta global 2.0
División de tablas Sí 2.0
División de entidades Sí Stretch para la versión 5.0 (n.º 620) (1)
Asignación de función escalar de base Insuficiente 2.0

de datos
Asignación de campos 1.1
Tipos de referencia que aceptan valores 3.0

NULL (C# 8.0)
Visualización gráfica de modelo Sí No hay soporte técnico planeado (2)
Editor de modelo gráfico Sí No hay soporte técnico planeado (2)
Formato de modelo: EDMX (XML) Sí No hay soporte técnico planeado (2)
Crear modelo desde base de datos: Sí No hay soporte técnico planeado (2)
Asistente de VS
Consulta de datos
Consultas LINQ Sí 1.0
SQL generado legible Insuficiente 1.0
Traslación de GroupBy Sí 2.1
Carga de datos relacionados: diligente Sí 1.0
Carga de datos relacionados: Carga 2.1

diligente para tipos derivados
Carga de datos relacionados: Vago Sí 2.1
Carga de datos relacionados: Explicit Sí 1.1
Consultas SQL sin formato: Tipos de Sí 1.0

entidad
Consultas SQL sin formato: Tipos de Sí 2.1

entidad sin llave
Consultas SQL sin formato: Redacción 1.0

con LINQ
Consultas compiladas de manera Insuficiente 2.0

explícita
await foreach (C# 8.0) 3.0
Lenguaje de consulta basado en texto Sí No hay soporte técnico planeado (2)

(Entity SQL)
Guardado de datos
Seguimiento de cambios: Depurador de Sí 1.0
Seguimiento de cambios: notificación Sí 1.0
Seguimiento de cambios: Servidores Sí Combinado para la versión 5.0

proxy (n.º 10949)
Acceso al estado con seguimiento Sí 1.0
Simultaneidad optimista Sí 1.0
Transacciones Sí 1.0
Procesamiento de instrucciones por 1.0

lotes
Asignación de procedimientos Sí En el trabajo pendiente (n.º 245)

almacenados
Grafo desconectado: API de bajo nivel Insuficiente 1.0
Grafo desconectado: de un extremo a 1.0 (parcial; n.º 5536)

otro
Otras características
Migraciones Sí 1.0
API de creación o eliminación de la base Sí 1.0

de datos
Datos de inicialización Sí 2.1
Resistencia de conexión Sí 1.1
Interceptores Sí 3.0
Events Sí 3.0 (parcial; n.º 626)
Registro simple (Database.Log) Sí Combinado para la versión 5.0

(n.º 1199)
Agrupación de DbContext 2.0
Proveedores de bases de datos (3)

SQL Server Sí 1.0
MySQL Sí 1.0
PostgreSQL Sí 1.0
Oracle Sí 1.0
SQLite Sí 1.0
SQL Server Compact Sí 1.0 (4)
DB2 Sí 1.0
Firebird Sí 2.0
Jet (Microsoft Access) 2.0 (4)

Azure Cosmos DB 3.0
En memoria (para pruebas) 1.0
1 Es probable que no se logren los objetivos de Stretch para una versión determinada. Sin embargo, si las cosas
van bien, intentaremos lograrlos.

2 Algunas características de EF6 no se implementarán en EF Core. Estas características dependen del Entity Data
Model (EDM) subyacente de EF6 o son características complejas con una rentabilidad de la inversión relativamente
baja. Siempre agradecemos los comentarios, pero, aunque EF Core permite muchas cosas que no son posibles en
EF6, no es factible que EF Core admita todas las características de EF6.
3 Es posible que los proveedores de bases de datos de EF Core implementados por terceros sufran un retraso en la
actualización a las versiones principales de EF Core. Vea Proveedores de bases de datos para obtener más
información.
4 Los proveedores de SQL Server Compact y Jet solo funcionan en .NET Framework (no en .NET Core).
Plataformas compatibles
EF Core 3.1 se ejecuta en .NET Core y .NET Framework a través del uso de .NET Standard 2.0. Sin embargo, EF
Core 5.0 no se ejecutará en .NET Framework. Consulte Plataformas para obtener más información.
EF6.4 se ejecuta en .NET Core y .NET Framework a través de la compatibilidad con múltiples versiones.
Guía para las aplicaciones nuevas

Use EF Core en .NET Core para todas las aplicaciones nuevas a menos que la aplicación necesite algún elemento
que solo se admita en .NET Framework.
Guía para las aplicaciones existentes de EF6

EF Core no es un reemplazo de EF6. Probablemente, cambiar de EF6 a EF Core requerirá cambios en la aplicación.
Al mover una aplicación de EF6 a .NET Core:
Siga usando EF6 si el código de acceso a datos es estable y no es probable que evolucione o necesite nuevas
características.
Realice el traslado a EF Core si el código de acceso a datos evoluciona o si la aplicación necesita nuevas
características que solo están disponibles en EF Core.
El traslado a EF Core también se realiza a menudo para obtener un mayor rendimiento. Sin embargo, no todos
los escenarios son más rápidos, así que genere primero algunos perfiles.
Para más información, consulteTraslado de EF6 a EF Core.
Portabilidad de EF6 a EF Core
08/04/2020 • 6 minutes to read
Debido a los cambios fundamentales en EF Core, no se recomienda que intente mover una aplicación de EF6 a EF
Core, salvo que tenga una razón convincente para hacerlo. Debe ver la migración de EF6 a EF Core como una
portabilidad en lugar de una actualización.
IMPORTANT
Antes de comenzar el proceso de portabilidad, es importante validar que EF Core cumple los requisitos de acceso a los datos
de la aplicación.
Características que faltan

Asegúrese de que EF Core tenga todas las características que necesita para usar en la aplicación. Vea Comparación
de características para obtener una comparación detallada del conjunto de características entre EF Core y EF6. Si
faltan algunas características necesarias, asegúrese de que puede compensar la falta de estas características antes
de portar a EF Core.
Cambios de comportamiento
Se trata de una lista no exhaustiva de algunos cambios de comportamiento entre EF6 y EF Core. Es importante
tener esto en cuenta cuando porte la aplicación, ya que pueden cambiar la forma en que se comporta la aplicación,
pero no se mostrarán como errores de compilación después de cambiar a EF Core.
DbSet.Add/Attach y comportamiento del grafo
En EF6, llamar DbSet.Add() en una entidad provoca una búsqueda recursiva de todas las entidades a las que se
hace referencia en sus propiedades de navegación. Las entidades que se encuentran, y a las que el contexto todavía
no ha realizado un seguimiento, también se marcarán como agregadas. DbSet.Attach() se comporta de la misma
forma, salvo que todas las entidades se marcan como sin cambios.
EF Core realiza una búsqueda recursiva similar, pero con algunas reglas ligeramente diferentes.
La entidad raíz siempre está en el estado de solicitada (agregada para DbSet.Add y sin cambios para
DbSet.Attach ).
Para las entidades que se encuentran durante la búsqueda recursiva de propiedades de

navegación:
Si la clave principal de la entidad se genera en el almacén
Si la clave principal no se establece en un valor, el estado se establece en agregada. El valor de
la clave principal se considera "no establecido" si se le asigna el valor predeterminado de CLR
para el tipo de propiedad (por ejemplo, 0 para int , null para string , etc.).
Si la clave principal no se establece en un valor, el estado se establece en sin cambios.
Si la clave principal no se genera en la base de datos, la entidad se coloca en el mismo estado que la
raíz.
Inicialización de la base de datos de Code First
EF6 tiene cier ta magia en torno a la selección de la conexión de base de datos y la inicialización de
la base de datos. Algunas de estas reglas incluyen:
Si no se realiza ninguna configuración, EF6 seleccionará una base de datos en SQL Express o LocalDb.
Si una cadena de conexión con el mismo nombre que el contexto está en el archivo App/Web.config de las
aplicaciones, se usará esta conexión.
Si la base de datos no existe, se creará.
Si no existe ninguna de las tablas del modelo en la base de datos, el esquema del modelo actual se agrega a
la base de datos. Si se habilitan las migraciones, se usan para crear la base de datos.
Si la base de datos existe y EF6 ha creado previamente el esquema, entonces se comprueba la
compatibilidad de dicho esquema con el modelo actual. Se inicia una excepción si el modelo ha cambiado
desde que se creó el esquema.
EF Core no lleva a cabo nada de esta magia.
La conexión de base de datos debe estar explícitamente configurada en el código.
No se realiza ninguna inicialización. Debe usar DbContext.Database.Migrate() para aplicar las migraciones (o
DbContext.Database.EnsureCreated() y EnsureDeleted() para crear o eliminar la base de datos sin usar
migraciones).
Convención de nomenclatura de tablas de Code First
EF6 ejecuta el nombre de clase de entidad a través de un servicio de pluralización para calcular el nombre de tabla
predeterminado al que está asignada la entidad.
EF Core usa el nombre de la propiedad DbSet en la que se expone la entidad en el contexto derivado. Si la entidad
no tiene una propiedad DbSet , se utiliza el nombre de clase.
Portabilidad de un modelo basado en EDMX de EF6
a EF Core
EF Core no admite el formato de archivo EDMX para los modelos. La mejor opción para realizar la portabilidad de
estos modelos consiste en generar un modelo nuevo basado en código a partir de la base de datos de la aplicación.
Instalación de los paquetes NuGet de EF Core

Instale el paquete NuGet Microsoft.EntityFrameworkCore.Tools .
Regeneración del modelo

Ahora puede usar la funcionalidad de ingeniería inversa para crear un modelo basado en la base de datos existente.
Ejecute el comando siguiente en la consola del Administrador de paquetes NuGet (Herramientas –> Administrador
de paquetes NuGet –> Consola del Administrador de paquetes). Vea Consola del Administrador de paquetes
(Visual Studio) para conocer las opciones de comando para aplicar scaffolding a un subconjunto de tablas, etc.
Scaffold-DbContext "<connection string>" <database provider name>
Por ejemplo, este es el comando para aplicar scaffolding a un modelo a partir de la base de datos Blogging en la
instancia de LocalDB de SQL Server.
Scaffold-DbContext "Server=(localdb)\mssqllocaldb;Database=Blogging;Trusted_Connection=True;"
Microsoft.EntityFrameworkCore.SqlServer
Eliminación del modelo de EF6

Ahora se quitará el modelo de EF6 de la aplicación.
No hay problema por dejar el paquete NuGet de EF6 (EntityFramework) instalado, ya que EF Core y EF6 se pueden
usar en paralelo en la misma aplicación. Sin embargo, si no va a usar EF6 en ninguna de las áreas de la aplicación,
la desinstalación del paquete le ayudará a dar errores de compilación en fragmentos de código que requieren
atención.
Actualización del código

En este punto, es cuestión de solucionar los errores de compilación y de revisar el código para ver si los cambios de
comportamiento entre EF6 y EF Core le afectarán.
Prueba del puerto

El hecho de que la aplicación se compile no significa que se haya trasladado correctamente a EF Core. Tendrá que
probar todas las áreas de la aplicación para asegurarse de que ninguno de los cambios de comportamiento afecte
de forma negativa a la aplicación.
Portabilidad de un modelo basado en código de EF6
a EF Core
Si ha leído todas las advertencias y está a punto para realizar la portabilidad, estas son algunas instrucciones que le
ayudarán a empezar.
Instalación de los paquetes NuGet de EF Core

Para usar EF Core, instale el paquete NuGet correspondiente al proveedor de base de datos que quiera usar. Por
ejemplo, cuando el destino es SQL Server, tendría que instalar Microsoft.EntityFrameworkCore.SqlServer . Para
obtener más información, vea Proveedores de bases de datos.
Si tiene previsto usar migraciones, también debe instalar el paquete Microsoft.EntityFrameworkCore.Tools .
No hay problema por dejar el paquete NuGet de EF6 (EntityFramework) instalado, ya que EF Core y EF6 se pueden
usar en paralelo en la misma aplicación. Sin embargo, si no va a usar EF6 en ninguna de las áreas de la aplicación,
la desinstalación del paquete le ayudará a dar errores de compilación en fragmentos de código que requieren
atención.
Intercambio de espacios de nombres

La mayoría de las API que se usan en EF6 se encuentran en el espacio de nombres System.Data.Entity (y los
subespacios de nombres relacionados). El primer cambio de código consiste en cambiar al espacio de nombres
Microsoft.EntityFrameworkCore . Normalmente, empezará con el archivo de código de contexto derivado y, después,
avanzará desde allí y solucionará los errores de compilación a medida que aparezcan.
Configuración del contexto (conexión, etc.)

Como se describe en Asegurarse de que EF Core funcionará para la aplicación, la detección de la base de datos a la
que se va a conectar EF Core tiene menos secretos. Tendrá que reemplazar el método OnConfiguring en el contexto
derivado y usar la API específica del proveedor de base de datos para configurar la conexión a la base de datos.
La mayoría de las aplicaciones EF6 almacenan la cadena de conexión en el archivo App/Web.config de las
aplicaciones. En EF Core, esta cadena de conexión se lee mediante la API ConfigurationManager . Es posible que
tenga que agregar una referencia al ensamblado del marco System.Configuration para poder usar esta API.
public class BloggingContext : DbContext

{
public DbSet<Blog> Blogs { get; set; }
public DbSet<Post> Posts { get; set; }
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)

{
optionsBuilder.UseSqlServer(ConfigurationManager.ConnectionStrings["BloggingDatabase"].ConnectionString);
}
}
Actualización del código

En este punto, es cuestión de solucionar los errores de compilación y de revisar el código para ver si los cambios de
comportamiento le afectarán.
Migraciones existentes
Realmente no existe una manera viable de realizar la portabilidad de las migraciones de EF6 existentes a EF Core.
Si es posible, es mejor suponer que todas las migraciones anteriores de EF6 se han aplicado a la base de datos y,
después, iniciar la migración del esquema desde ese punto mediante EF Core. Para ello, use el comando
Add-Migration para agregar una migración una vez que el modelo se haya trasladado a EF Core. Después, podría
quitar todo el código de los métodos Up y Down de la migración con scaffolding. Las migraciones posteriores se
compararán con el modelo cuando se haya aplicado scaffolding a la migración inicial.
Prueba del puerto

El hecho de que la aplicación se compile no significa que se haya trasladado correctamente a EF Core. Tendrá que
probar todas las áreas de la aplicación para asegurarse de que ninguno de los cambios de comportamiento afecte
de forma negativa a la aplicación.
Uso de EF Core y EF6 en la misma aplicación
Es posible usar EF Core y EF6 en la misma biblioteca o aplicación al instalar ambos paquetes NuGet.
Algunos tipos tienen los mismos nombres en EF Core y EF6 y solo difieren en el espacio de nombres, lo que puede
complicar el uso de EF Core y EF6 en el mismo archivo de código. La ambigüedad se puede eliminar fácilmente con
directivas de alias de espacios de nombres. Por ejemplo:
using Microsoft.EntityFrameworkCore; // use DbContext for EF Core

using EF6 = System.Data.Entity; // use EF6.DbContext for the EF6 version
Si traslada una aplicación existente que tiene varios modelos de EF, puede elegir trasladar de manera selectiva
algunos de ellos a EF Core y seguir usando EF6 para los demás.
Entity Framework (EF) Core es una versión ligera, extensible, de código abierto y multiplataforma de la popular
tecnología de acceso a datos Entity Framework.
EF Core puede servir como asignador relacional de objetos (O/RM), lo que permite a los desarrolladores de .NET
trabajar con una base de datos mediante objetos .NET y eliminar la mayoría del código de acceso a los datos que
normalmente deben escribir.
EF Core es compatible con muchos motores de base de datos; vea Proveedores de bases de datos para más
información.
El modelo
Con EF Core, el acceso a datos se realiza mediante un modelo. Un modelo se compone de clases de entidad y un
objeto de contexto que representa una sesión con la base de datos, lo que permite consultar y guardar los datos.
Vea Creación de un modelo para más información.
Puede generar un modelo a partir de una base de datos existente, codificar manualmente un modelo para que
coincida con la base de datos o usar migraciones de EF para crear una base de datos a partir del modelo y que
evolucione a medida que cambia el modelo.
using Microsoft.EntityFrameworkCore;
using System.Collections.Generic;
namespace Intro
{
{

{
optionsBuilder.UseSqlServer(
@"Server=(localdb)\mssqllocaldb;Database=Blogging;Integrated Security=True");
}
}
public class Blog

{
public int BlogId { get; set; }
public string Url { get; set; }
public int Rating { get; set; }
public List<Post> Posts { get; set; }
}
public class Post

{
public int PostId { get; set; }
public string Title { get; set; }
public string Content { get; set; }

public Blog Blog { get; set; }
}
}
Consultas
Las instancias de las clases de entidad se recuperan de la base de datos mediante Language Integrated Query
(LINQ). Vea Consulta de datos para más información.
using (var db = new BloggingContext())

{
var blogs = db.Blogs
.Where(b => b.Rating > 3)
.OrderBy(b => b.Url)
.ToList();
}
Guardado de datos
Los datos se crean, se eliminan y se modifican en la base de datos mediante instancias de las clases de entidad. Vea
Guardado de datos para más información.

{
var blog = new Blog { Url = "http://sample.com" };
db.Blogs.Add(blog);
db.SaveChanges();
}
Pasos siguientes
Para consultar tutoriales de introducción, vea Introducción a Entity Framework Core.
Versiones y planeamiento de EF Core
Versiones estables
M A RC O DE T RA B A JO DE
REL EA SE DEST IN O C O M PAT IB IL IDA D H A STA VÍN C ULO S
EF Core 3.1 .NET Standard 2.0 3 de diciembre de 2022 (LTS) Anuncio
EF Core 3.0 .NET Standard 2.1 Expiró el 3 de marzo de Anuncio / Cambios

2020 importantes
EF Core 2.2 .NET Standard 2.0 Expiró el 23 de diciembre de Anuncio

2019
EF Core 2.1 .NET Standard 2.0 21 de agosto de 2021 (LTS) Anuncio
EF Core 2.0 .NET Standard 2.0 Expiró el 1 de octubre de Anuncio

2018
EF Core 1.1 .NET Standard 1.3 Expiró el 27 de junio de Anuncio

2019
EF Core 1.0 .NET Standard 1.3 Expiró el 27 de junio de Anuncio

2019
Consulte las plataformas compatibles para saber qué plataformas concretas se admiten en cada versión de EF Core.
Consulte la Directiva de compatibilidad de .NET para obtener información sobre la fecha de expiración de la
compatibilidad y las versiones de compatibilidad a largo plazo (LTS).
Instrucciones para actualizar a nuevas versiones

Las versiones admitidas se revisan por motivos de seguridad y para solucionar otros errores críticos. Use
siempre el parche más reciente de una versión determinada. Por ejemplo, para EF Core 2.1, use 2.1.14.
Las actualizaciones de la versión principal (por ejemplo, de EF Core 2 a EF Core 3) suelen tener cambios
importantes. Se recomienda realizar pruebas exhaustivas al cambiar de una versión principal a otra. Use los
vínculos de cambios importantes anteriores para obtener información sobre cómo abordar los cambios
importantes.
Las actualizaciones de versiones secundarias no suelen contener cambios importantes. No obstante, sigue
siendo aconsejable realizar pruebas exhaustivas, ya que las nuevas características pueden introducir
regresiones.
Programación y planeación de versiones

Las versiones de EF Core siguen la programación de envío de .NET Core.
Normalmente, las versiones de revisión se envían mensualmente, pero tienen un largo plazo. Estamos trabajando
para mejorar esto.
Vea el proceso de planeamiento de versiones para obtener más información sobre cómo decidimos qué enviar en
cada versión. Por lo general, no hacemos un planeamiento detallado más allá de la siguiente versión principal o
secundaria.
EF Core 5.0
La siguiente versión estable planeada es EF Core 5.0 , programada para noviembre de 2020.
Se ha creado un plan de alto nivel para EF Core 5.0 siguiendo el proceso de planeamiento de versiones
documentado.
Sus comentarios sobre la planeación son importantes. La mejor manera de indicar la importancia de un problema
es votar (pulgar arriba ) por ese problema en GitHub. Estos datos se introducen en el proceso de planeación de
la próxima versión.
¡Obténgalo ahora!
Los paquetes de EF Core 5.0 están disponibles ahora como
Compilaciones diarias
Todas las características y correcciones de errores más recientes. Normalmente muy estable; se ejecutan
más de 57 000 pruebas en cada compilación.
Versiones preliminares en NuGet
Van a la zaga de las compilaciones diarias, pero están probadas para trabajar con las versiones
preliminares de ASP.NET Core y .NET Core correspondientes.
Usar las versiones preliminares o las compilaciones diarias es una excelente manera de detectar problemas y
proporcionar comentarios cuanto antes. Cuanto antes recibamos esos comentarios, más probable será que puedan
procesarse antes de la siguiente versión oficial.
Proceso de planeamiento de versiones
A menudo nos preguntan cómo se eligen características específicas para incluirlas en una versión concreta. En
este documento se describe el proceso que usamos. El proceso evoluciona continuamente a medida que
encontramos mejores formas de planeación, pero las ideas generales siguen siendo las mismas.
Diferentes tipos de versiones

Los distintos tipos de versión contienen distintos tipos de cambios. Esto significa que, a su vez, el planeamiento de
versiones es diferente para cada tipo de versión.
Versiones de revisión
Las versiones de revisión solo cambian la parte de "revisión" de la versión. Por ejemplo, EF Core 3.1.1 es una
versión en la que se han revisado los problemas encontrados en EF Core 3.1.0 .
Las versiones de revisión están diseñadas para corregir errores críticos para los clientes. Esto significa que las
versiones de revisión no incluyen nuevas características. No se permiten cambios de API en las versiones de
revisión, excepto en circunstancias especiales.
La dificultad para hacer un cambio en una versión de revisión es muy alta. Esto se debe a que es fundamental que
las versiones de revisión no presenten nuevos errores. Por lo tanto, el proceso de toma de decisiones enfatiza el
alto valor y el riesgo bajo.
Es más probable que revisemos un problema si se cumple una de las siguientes condiciones:
Afecta a varios clientes.
Es una regresión de una versión anterior.
El error provoca daños en los datos.
Es menos probable que revisemos un problema si se cumple una de las siguientes condiciones:
Existen soluciones alternativas razonables.
La corrección implica un alto riesgo de interrumpir algo más.
El error es un caso límite.
La dificultad aumenta gradualmente a lo largo de la vigencia de una versión de soporte técnico a largo plazo
(LTS). Esto se debe a que las versiones de LTS enfatizan la estabilidad.
La decisión final sobre si un problema se revisa o no la realizan los directores de .NET en Microsoft.
Versiones secundarias
Las versiones secundarias solo cambian la parte "secundaria" de la versión. Por ejemplo, EF Core 3.1 .0 es una
versión que mejora EF Core 3.0 .0.
Versiones secundarias:
Están diseñadas para mejorar la calidad y las características de la versión anterior.
Normalmente contienen correcciones de errores y nuevas características.
No incluyen cambios importantes intencionados.
Tienen algunas vistas previas de versiones preliminares insertadas en NuGet.
Versiones principales:
Las versiones principales cambian el número de versión "principal" de EF. Por ejemplo, EF Core 3 .0.0 es una
versión principal que da un gran paso adelante con respecto a EF Core 2.2.x.
Versiones principales:
Están diseñadas para mejorar la calidad y las características de la versión anterior.
Normalmente contienen correcciones de errores y nuevas características.
Algunas de las nuevas características pueden ser cambios fundamentales en el funcionamiento de EF
Core.
Normalmente, incluyen cambios importantes intencionados.
Los cambios importantes son parte necesaria de la evolución de EF Core a medida que aprendemos.
Sin embargo, estudiamos mucho la realización de los cambios importantes debido al posible impacto
que puedan tener en el cliente. Es posible que hayamos sido demasiado radicales con cambios
importantes en el pasado. De ahora en adelante, nos esforzaremos por minimizar los cambios que
interrumpan el funcionamiento de las aplicaciones y reducir los cambios que interrumpan el
funcionamiento de los proveedores de bases de datos y las extensiones.
Tienen muchas vistas previas de versiones preliminares insertadas en NuGet.
Planeación de versiones principales o secundarias

Seguimiento de problemas de GitHub
GitHub (https://github.com/dotnet/efcore) es la fuente fiable de toda la planeación de EF Core.
Los problemas en GitHub cuentan con lo siguiente:
Un estado
Si un problema está abierto significa que no se ha abordado.
Si un problema está cerrado significa que se ha abordado.
Todos los problemas que se han corregido se etiquetan con el estado “closed-fixed” (cerrado:
corregido). Un problema con la etiqueta “closed-fixed” está corregido y combinado, pero es
posible que no se haya publicado.
Las demás etiquetas de closed- indican otras razones por las que se ha cerrado un problema.
Por ejemplo, los duplicados se etiquetan con “closed-duplicate” (cerrado: duplicado).
Un tipo
El tipo Bugs (Errores) representa errores.
El tipo Enhancements (Mejoras) corresponde a nuevas características o una mejor funcionalidad en las
características existentes.
Un hito
Si un problema no tiene hito, significa que el equipo lo está considerando. La decisión sobre qué hacer
con el problema aún no se ha tomado o se está considerando cambiarla.
Los problemas en el hito Backlog (Trabajo pendiente) son elementos en los que el equipo de EF
considerará que debe trabajar en una versión futura.
Es posible que los problemas del trabajo pendiente tengan la etiqueta consider-for-next-release
(considerar en la próxima versión), lo que indica que este elemento de trabajo es una de las
prioridades para la próxima versión.
Los problemas abiertos en un hito con versión son elementos en los que el equipo tiene previsto
trabajar en esa versión. Por ejemplo, estos son los problemas con los que tenemos previsto trabajar en
EF Core 5.0.
Los problemas cerrados en un hito con versión son los que se completan para esa versión. Tenga en
cuenta que es posible que la versión todavía no se haya lanzado. Por ejemplo, estos son los problemas
completados para EF Core 3.0.
Votos
La votación es la mejor manera de que el usuario indique que un problema es importante.
Para votar, solo tiene que agregar un "pulgar" al problema. Por ejemplo, estos son los problemas
más votados.
También debe incluir un comentario con las razones específicas por las que necesita la característica si
cree que puede ser útil. Comentar "+ 1" o algo similar no agrega ningún valor.
Proceso de planeación
El proceso de planeación es más complicado que simplemente tomar las principales características más
solicitadas del trabajo pendiente. Esto se debe a que se recopilan comentarios de varias partes interesadas de
varias maneras. Por lo tanto, formamos una versión basada en lo siguiente:
Comentarios de los clientes
Comentarios de otras partes interesadas
Dirección estratégica
Recursos disponibles
Programación
Algunas de las preguntas que formulamos son:
1. ¿Cuántos desarrolladores creemos que usarán la característica y en qué medida mejorará las
aplicaciones o la experiencia? Para responder a esta pregunta, recopilamos información de varias
fuentes, y los comentarios y los votos son una de ellas. Las involucraciones específicas con clientes
importantes son otra.
2. ¿Qué soluciones alternativas pueden adoptar los usuarios si todavía no se ha implementado
una característica? Por ejemplo, hay muchos desarrolladores que pueden asignar una tabla de unión
para poder trabajar a pesar de la falta de compatibilidad múltiple de forma nativa. Obviamente, no todos
los desarrolladores quieren hacerlo, pero muchos pueden, y eso se considera un factor decisivo.
3. ¿La implementación de esta característica hará evolucionar la arquitectura de EF Core tanto
como para poder implementar otras características? Normalmente tienen preferencia las
características que actúan como bloques de creación de otras características. Por ejemplo, las entidades
contenedoras de propiedades pueden ayudarnos a avanzar hacia la compatibilidad de varios a varios, y los
constructores de entidades han habilitado nuestra compatibilidad de carga diferida.
4. ¿La característica es un punto de extensibilidad? Los puntos de extensibilidad suelten tener
preferencia sobre las características normales porque permiten que los desarrolladores puedan crear sus
propios comportamientos y compensar las funcionalidades que faltan.
5. ¿Cuál es la sinergia de la característica cuando se usa en combinación con otros productos?
Tienen preferencia las características que permiten o mejoran significativamente la experiencia de uso de
EF Core con otros productos, como .NET Core, la última versión de Visual Studio, Microsoft Azure, etc.
6. ¿Cuáles son las habilidades de las personas disponibles para trabajar en una característica y
cómo se aprovechan mejor estos recursos? Todos los miembros del equipo de EF, e incluso los
colaboradores de la comunidad, tienen diferentes niveles de experiencia en varias áreas, y tenemos que
elaborar el plan de acuerdo con ello. Incluso aunque quisiéramos tener a todos trabajando en una
característica específica, como las traducciones de GroupBy o las relaciones múltiples, no sería práctico.
Plan para Entity Framework Core 5.0
Como se describe en el proceso de planeamiento, se ha recopilado la información de las partes interesadas en un

plan provisional para la versión EF Core 5.0.
IMPORTANT
Este plan sigue siendo un trabajo en curso. Nada de esto es un compromiso. Este plan es un punto de partida que
evolucionará a medida que se obtenga más información. Es posible que algunos aspectos no planeados en la actualidad se
incorporen a la versión 5.0. Es posible que algunos aspectos planeados en la actualidad se eliminen de la versión 5.0.
Número de versión y fecha de lanzamiento.

En la actualidad, el lanzamiento de EF Core 5.0 está programado al mismo tiempo que .NET 5.0. Se ha elegido la
versión "5.0" para la alineación con .NET 5.0.
Plataformas compatibles
Está previsto que EF Core 5.0 se ejecute en cualquier plataforma .NET 5.0 en función de la convergencia de estas
plataformas a .NET Core. Lo que esto significa en términos de .NET Standard y el TFM real que se usa todavía está
por determinar.
EF Core 5.0 no se ejecutará en .NET Framework.
Cambios importantes
EF Core 5.0 contendrá algunos cambios importantes, pero serán mucho menos graves que en el caso de EF
Core 3.0. El objetivo es permitir que la gran mayoría de las aplicaciones se actualicen sin interrupciones.
Se espera que haya algunos cambios importantes para los proveedores de bases de datos, especialmente
relacionados con la compatibilidad con TPT. Pero se espera que el trabajo para actualizar un proveedor para 5.0
sea menor que el necesario para 3.0.
Temas
Hemos extraído algunas áreas o temas importantes que formarán la base de las grandes inversiones en EF
Core 5.0.
Propiedades de navegación de varios a varios (también denominado

"omitir navegaciones")
Jefes de desarrollo: @smitpatel y @AndriySvyryd
Seguimiento realizado por #19003
Talla de camiseta: L
Estado: En curso
Varios a varios es la característica más solicitada (407 votos aproximadamente) en el trabajo pendiente de GitHub.
Se realiza un seguimiento de la compatibilidad con las relaciones de varios a varios en su totalidad como #10508.
Puede dividirse en tres áreas principales:
Omitir propiedades de navegación. Permiten usar el modelo para las consultas, etc., sin hacer referencia a la
entidad de la tabla de combinación subyacente. (#19003)
Tipos de entidad de contenedor de propiedades. Permiten usar un tipo CLR estándar (por ejemplo, Dictionary )
para las instancias de entidad, de modo que no se necesite un tipo CLR explícito para cada tipo de entidad.
(Stretch para la versión 5.0: #9914).
Facilitar la configuración de relaciones varios a varios. (Stretch para la versión 5.0).
Creemos que el principal obstáculo para los que quieren que se admitan las relaciones varios a varios es la
imposibilidad de usar relaciones "naturales", sin hacer referencia a la tabla de combinación, en la lógica de
negocios, como las consultas. Es posible que el tipo de entidad de tabla de combinación siga existiendo, pero no
debería interferir con la lógica de negocios. Por este motivo hemos optado por abordar la omisión de propiedades
de navegación en la versión 5.0.
En este momento, los demás elementos de las relaciones varios a varios se han convertido en un objetivo de
extensión para EF Core 5.0. Esto significa que actualmente no se incluyen en el plan para la versión 5.0, pero si
todo va bien esperamos incorporarlos.
Asignación de herencia de tabla por tipo (TPT)

Jefe de desarrollo: @AndriySvyryd
Talla de camiseta: XL
Estado: En curso
TPT se va a incluir porque se trata de una característica muy solicitada (aproximadamente 254 votos; en tercera
posición) y porque requiere algunos cambios de bajo nivel que consideramos adecuados para la naturaleza
fundamental del plan general de .NET 5. Esperamos que esto genere cambios importantes para los proveedores
de bases de datos, aunque deberían ser mucho menos graves que los necesarios para la versión 3.0.
Inclusión filtrada
Jefe de desarrollo: @maumar
Talla de camiseta: M
Estado: En curso
La inclusión filtrada es una característica muy solicitada (aproximadamente 317 votos; en segunda posición) que
no requiere demasiado trabajo y que creemos que desbloqueará o facilitará escenarios que actualmente requieren
filtros de nivel de modelo o consultas más complejas.
Racionalización de ToTable, ToQuery, ToView, FromSql, etc.

Jefes de desarrollo: @maumar y @smitpatel
Estado: En curso
Se han realizado avances en versiones anteriores hacia la compatibilidad con SQL sin procesar, tipos sin clave y
áreas relacionadas. Pero hay brechas e incoherencias en el funcionamiento en conjunto de todos los elementos. El
objetivo para la versión 5.0 es corregirlos y crear una buena experiencia para definir, migrar y usar otros tipos de
entidades y sus consultas y artefactos de base de datos asociados. Esto también puede implicar actualizaciones de
la API de consulta compilada.
Tenga en cuenta que este elemento puede dar lugar a algunos cambios importantes en el nivel de la aplicación, ya
que algunas de las funcionalidades actuales son demasiado permisivas, lo que puede conducir rápidamente a que
los usuarios cometan errores. Lo más probable es que parte de esta funcionalidad se bloquee y se proporcionen
instrucciones sobre lo que se debe hacer en su lugar.
Mejoras generales de consultas

Jefes de desarrollo: @smitpatel y @maumar
Seguimiento por problemas etiquetados con area-query en el hito 5.0
Talla de camiseta: XL
Estado: En curso
El código de traducción de consultas se ha reescrito de forma exhaustiva para EF Core 3.0. Por este motivo, el
código de consulta tiene un estado mucho más robusto. Para la versión 5.0, no se planean cambios importantes en
las consultas más allá de los necesarios para admitir TPT y la omisión de propiedades de navegación. Pero se
necesita un trabajo importante para corregir las deudas técnicas generadas tras la revisión de la versión 3.0.
También tenemos previsto corregir muchos errores e implementar pequeñas mejoras para mejorar aún más la
experiencia general de las consultas.
Migraciones y experiencia de implementación

Jefes de desarrollo: @bricelam
Estado: En curso
En la actualidad, muchos desarrolladores migran sus bases de datos en el momento de inicio de la aplicación. Esto
es fácil, pero no se recomienda porque:
Es posible que varios subprocesos, procesos o servidores intenten migrar la base de datos simultáneamente
Es posible que las aplicaciones intenten acceder a un estado incoherente mientras se produce esta operación
Normalmente, no se deben conceder los permisos de base de datos para modificar el esquema para la
ejecución de la aplicación
Es difícil revertir a un estado limpio si se produce algún error
Queremos ofrecer una mejor experiencia que permita migrar la base de datos de forma sencilla en el momento de
la implementación. Esto debería:
Funcionar en Linux, Mac y Windows
Ser una experiencia positiva en la línea de comandos
Admitir escenarios con contenedores
Funcionar con flujos y herramientas de implementación del mundo real que se usan habitualmente
Integrarse al menos en Visual Studio
Lo más probable es que el resultado sea un gran número de pequeñas mejoras en EF Core (por ejemplo, mejores
migraciones en SQLite), junto con instrucciones y colaboraciones a largo plazo con otros equipos para mejorar las
experiencias de un extremo a otro que van más allá de EF exclusivamente.
Experiencia de las plataformas de EF Core
Jefes de desarrollo: @roji y @bricelam
Estado: Sin iniciar
Disponemos de instrucciones de calidad para usar EF Core en aplicaciones web tradicionales similares a MVC. Las
instrucciones para otras plataformas y modelos de aplicación no existen o no están actualizadas. Para EF Core 5.0,
el objetivo es investigar, mejorar y documentar la experiencia de uso de EF Core con:
Blazor
Xamarin, incluido el uso del artículo de AOT o vinculador
WinForms, WPF, WinUI y posiblemente otras interfaces de usuario frameworks
Lo más probable es que el resultado sea un gran número de pequeñas mejoras en EF Core, junto con instrucciones
y colaboraciones a largo plazo con otros equipos para mejorar las experiencias de un extremo a otro que van más
allá de EF exclusivamente.
Las áreas concretas que tenemos previsto examinar son las siguientes:
Implementación, incluida la experiencia en el uso de herramientas de EF como para migraciones
Modelos de aplicación, como Xamarin y Blazor, y probablemente otros
Experiencias de SQLite, incluida la experiencia espacial y las recompilaciones de tabla
Experiencias de AOT y vinculación
Integración de diagnósticos, incluidos los contadores de rendimiento
Rendimiento
Jefe de desarrollo: @roji
Seguimiento por problemas etiquetados con area-perf en el hito 5.0
Estado: En curso
Para EF Core, el plan es mejorar nuestro conjunto de pruebas comparativas de rendimiento y realizar mejoras de
rendimiento dirigidas al tiempo de ejecución. Además, tenemos previsto completar la nueva API de procesamiento
por lotes de ADO.NET, que se ha creado como prototipo durante el ciclo de versiones de 3.0. En el nivel de
ADO.NET también se planean mejoras de rendimiento adicionales para el proveedor Npgsql.
Como parte de este trabajo, también está previsto agregar contadores de rendimiento de ADO.NET y EF Core, y
otros diagnósticos según corresponda.
Documentación de arquitectura y colaboradores

Jefe de documentación: @ajcvickers
Estado: En curso
La idea es facilitar la comprensión de lo que sucede dentro de EF Core. Esto puede ser útil para cualquiera que
utilice EF Core, pero la motivación principal es facilitarlo para los usuarios externos:
Contribuir al código de EF Core
Crear proveedores de bases de datos
Compilar otras extensiones
Documentación de Microsoft.Data.Sqlite
Jefe de documentación: @bricelam
Talla de camiseta: M
Estado: Completado. La nueva documentación está activa en el sitio de documentación de Microsoft.
El equipo de EF también posee el proveedor de ADO.NET Microsoft.Data.Sqlite. Tenemos previsto documentar
completamente este proveedor como parte de la versión 5.0.
Documentación general
Jefe de documentación: @ajcvickers
Seguimiento mediante problemas en el repositorio de documentación del hito 5.0
Estado: En curso
Ya se ha iniciado el proceso de actualización de la documentación de las versiones 3.0 y 3.1. También se está
trabajando en:
Una revisión de la documentación de introducción para que sea más fácil de seguir
La reorganización de la documentación para facilitar la búsqueda y la adición de referencias cruzadas
La incorporación de más detalles y aclaraciones a la documentación existente
La actualización de los ejemplos y la incorporación de otros nuevos
Corrección de errores
Seguimiento por problemas etiquetados con type-bug en el hito 5.0
Desarrolladores: @roji, @maumar, @bricelam, @smitpatel, @AndriySvyryd, @ajcvickers
Estado: En curso
En el momento de escribir este documento, se han evaluado 135 errores para corregirlos en la versión 5.0 (ya se
han corregido 62), pero hay una superposición significativa con la sección anterior Mejoras generales de
consultas.
La velocidad de entrada (problemas que acaban como trabajo en un hito) fue de aproximadamente 23 problemas
al mes en el transcurso de la versión 3.0. No todos se tendrán que corregir en la versión 5.0. Como estimación
aproximada, tenemos previsto corregir unos 150 problemas adicionales para la versión 5.0.
Mejoras menores
Seguimiento por problemas etiquetados con type-enhancement en el hito 5.0
Desarrolladores: @roji, @maumar, @bricelam, @smitpatel, @AndriySvyryd, @ajcvickers
Estado: En curso
Además de las características más importantes descritas antes, también hay muchas mejoras más pequeñas
programadas para la versión 5.0 a fin de corregir los "elementos excluidos". Tenga en cuenta que muchas de estas
mejoras también se incluyen en los temas más generales descritos antes.
Nivel inferior
Seguimiento por problemas etiquetados con consider-for-next-release
Se trata de correcciones de errores y mejoras no programadas actualmente para la versión 5.0, pero que se
considerarán objetivos de extensión en función del progreso realizado en el trabajo anterior.
Además, durante la planeación siempre se tienen en cuenta los problemas más votados. Excluir cualquiera de
estos problemas de una versión siempre es complicado, pero necesitamos un plan realista para los recursos que
tenemos.
Comentarios
Sus comentarios sobre la planeación son importantes. La mejor manera de indicar la importancia de un problema
es votar (pulgar) por ese problema en GitHub. Estos datos se introducirán después en el proceso de planeación de
la próxima versión.
Novedades en EF Core 5.0
EF Core 5.0 está actualmente en desarrollo. Esta página contendrá información general sobre los cambios
interesantes introducidos en cada versión preliminar.
Esta página no duplica el plan para EF Core 5.0. En el plan se describen los temas generales relativos a EF Core 5.0,
incluido todo lo que estamos planeando incluir antes de publicar la versión final.
A medida que se publique el contenido, se agregarán vínculos que redirigirán de esta página a la documentación
oficial.
Versión preliminar 1
Registro sencillo
Esta característica agrega funcionalidad similar a Database.Log en EF6. Es decir, proporciona una manera sencilla
de obtener registros de EF Core sin necesidad de configurar ningún tipo de plataforma de registro externa.
La documentación preliminar se incluye en el estado semanal de EF del 5 de diciembre de 2019.
En el problema n.º 2085 se realiza el seguimiento de la documentación adicional.
Forma sencilla de generar contenido SQL
EF Core 5.0 presenta el método de extensión ToQueryString que devolverá el contenido SQL que EF Core generará
al ejecutar una consulta LINQ.
La documentación preliminar se incluye en el estado semanal de EF del 9 de enero de 2020.
Uso de un atributo de C# para indicar que una entidad no tiene clave
Ahora se pueden configurar los tipos de entidad para indicar que no tienen clave mediante el nuevo valor
KeylessAttribute . Por ejemplo:
[Keyless]
public class Address
{
public string Street { get; set; }
public string City { get; set; }
public int Zip { get; set; }
}
En el problema n.º 2186 se realiza el seguimiento de la documentación.

Posibilidad de cambiar la conexión o la cadena de conexión en una instancia inicializada de DbContext
Ahora es más fácil crear una instancia de DbContext sin ninguna conexión o cadena de conexión. Además, la
conexión o la cadena de conexión ahora también se pueden mutar en la instancia de contexto. Esto permite que la
misma instancia de contexto se conecte dinámicamente a diferentes bases de datos.
Proxies de seguimiento de cambios
Ahora EF Core puede generar proxies del entorno de ejecución que implementen automáticamente
INotifyPropertyChanging y INotifyPropertyChanged. A continuación, los cambios de valor en las propiedades de
las entidades se notifican directamente a EF Core, lo cual evita la necesidad de buscar los cambios. Sin embargo, los
proxies vienen con su propio conjunto de limitaciones, por lo que no son para todo el mundo.
Vistas de depuración mejoradas
Las vistas de depuración son una forma fácil de consultar los aspectos internos de EF Core al depurar problemas.
Hace algún tiempo ya se implementó una vista de depuración para el modelo. En el caso de EF Core 5.0, hemos
facilitado la lectura de la vista de modelo y hemos agregado una nueva vista de depuración para las entidades de
las que se ha realizado un seguimiento en el administrador de estado.
Control mejorado de la semántica de valores NULL de base de datos
Normalmente, las bases de datos relacionales tratan NULL como valores desconocidos y, por lo tanto, no son
iguales a otros valores NULL. C#, por otro lado, trata los valores NULL como valores definidos y los compara igual
que con cualquier otro valor NULL. De forma predeterminada, EF Core traduce las consultas para que usen la
semántica de valores NULL de C#. EF Core 5.0 mejora en gran medida la eficacia de dichas traducciones.
Propiedades del indizador
EF Core 5.0 admite la asignación de propiedades de indizador de C#. Esto permite a las entidades actuar como
bolsas de propiedades en las que las columnas se asignan a las propiedades con nombre en la bolsa.
Generación de restricciones CHECK para las asignaciones de enumeración
Las migraciones de EF Core 5.0 ahora pueden generar restricciones CHECK para las asignaciones de propiedades
de enumeración. Por ejemplo:
MyEnumColumn VARCHAR(10) NOT NULL CHECK (MyEnumColumn IN('Useful', 'Useless', 'Unknown'))

IsRelational
Se ha agregado un nuevo método IsRelational , además de los existentes, que son IsSqlServer , IsSqlite y
IsInMemory . Se puede usar para comprobar si DbContext está usando algún proveedor de bases de datos
relacionales. Por ejemplo:
protected override void OnModelCreating(ModelBuilder modelBuilder)

{
if (Database.IsRelational())
{
// Do relational-specific model configuration.
}
}

Simultaneidad optimista de Cosmos con mecanismos ETag
El proveedor de bases de datos de Azure Cosmos DB ya es compatible con la simultaneidad optimista mediante
mecanismos ETag. Utilice el generador de modelos de OnModelCreating para confirmar un mecanismo ETag:
builder.Entity<Customer>().Property(c => c.ETag).IsEtagConcurrency();
Después, SaveChanges generará una excepción DbUpdateConcurrencyException en un conflicto de simultaneidad,

que se podrá manipular, por ejemplo, para implementar reintentos.
En el problema n.º 2099 realiza se el seguimiento de la documentación.
Traducciones de consultas para más construcciones DateTime
Ahora las consultas que contienen la nueva construcción DateTime se traducen.
Además, ahora se asignan las funciones de SQL Server que hay a continuación:
DateDiffWeek
DateFromParts
Por ejemplo:
var count = context.Orders.Count(c => date > EF.Functions.DateFromParts(DateTime.Now.Year, 12, 25));

Traducciones de consultas para más construcciones de matriz de bytes
Las consultas que usan Contains, Length, SequenceEqual, etc. en las propiedades byte[] ahora se traducen a SQL.
Traducción de consultas para Reverse
Las consultas que usan Reverse ahora se traducen. Por ejemplo:
context.Employees.OrderBy(e => e.EmployeeID).Reverse()

Traducción de consultas para operadores bit a bit
Las consultas que usan operadores bit a bit ahora se traducen en más casos, por ejemplo:
context.Orders.Where(o => ~o.OrderID == negatedId)

Traducción de consultas para cadenas en Cosmos
Al emplear el proveedor Azure Cosmos DB, las consultas que usan los métodos de cadena Contains, StartsWith y
EndsWith ahora se traducen.
Características nuevas de Entity Framework Core 3.0
En la lista siguiente se incluyen las principales características nuevas de EF Core 3.0.

Como versión principal, EF Core 3.0 también presenta varios cambios importantes, que son mejoras en la API que
podrían afectar negativamente a las aplicaciones existentes.
Revisión de LINQ
LINQ permite escribir consultas a la base de datos en el lenguaje .NET que prefiera, con lo que se aprovecha la
información de tipo enriquecido para ofrecer la comprobación de IntelliSense y de tipos en tiempo de compilación.
Pero LINQ también permite escribir un número ilimitado de consultas complicadas que contienen expresiones
arbitrarias (llamadas a métodos u operaciones). Cómo controlar todas esas combinaciones es el principal desafío
para los proveedores LINQ.
En EF Core 3,0, hemos rediseñado nuestro proveedor LINQ para habilitar la conversión de más patrones de
consulta en SQL, la generación de consultas eficientes en más casos y la prevención de que las consultas ineficaces
no se detecten. El nuevo proveedor LINQ es la base sobre la que podremos ofrecer nuevas funcionalidades de
consulta y mejoras de rendimiento en futuras versiones, sin interrumpir las aplicaciones y los proveedores de datos
existentes.
Evaluación de cliente restringida
El cambio de diseño más importante tiene que ver con la forma en que manejamos las expresiones LINQ que no se
pueden convertir a parámetros ni traducir a SQL.
En las versiones anteriores, EF Core identificada qué partes de una consulta se podían traducir a SQL y ejecutaba el
resto de la consulta en el cliente. Este tipo de ejecución en el lado cliente es una opción interesante en algunas
situaciones, pero en muchos otros casos puede dar lugar a consultas ineficaces.
Por ejemplo, si EF Core 2.2 no podía traducir un predicado en una llamada a Where() , ejecutaba una instrucción
SQL sin filtro, transfería todas las filas de la base de datos y luego las filtraba en memoria:
var specialCustomers = context.Customers

.Where(c => c.Name.StartsWith(n) && IsSpecialCustomer(c));
Esta operación puede ser aceptable si la base de datos contiene pocas filas, pero puede dar lugar a problemas de
rendimiento considerables o incluso errores en la aplicación si la base de datos contiene muchas filas.
En EF Core 3.0 hemos restringido la evaluación de cliente para que solo suceda en la proyección de nivel superior
(fundamentalmente, la última llamada a Select() ). Cuando EF Core 3.0 detecta expresiones que no se pueden
traducir en ningún otro lugar de la consulta, produce una excepción en tiempo de ejecución.
Para evaluar una condición de predicado en el cliente como en el ejemplo anterior, los desarrolladores ahora tienen
que cambiar explícitamente la evaluación de la consulta a LINQ to Objects:
var specialCustomers = context.Customers

.Where(c => c.Name.StartsWith(n))
.AsEnumerable() // switches to LINQ to Objects
.Where(c => IsSpecialCustomer(c));
Consulte la documentación sobre cambios importantes para más detalles sobre cómo esto puede afectar a las
aplicaciones existentes.
Instrucción SQL única por consulta LINQ
Otro aspecto del diseño que cambió significativamente en la versión 3.0 es que ahora siempre se genera una única
instrucción SQL por cada consulta LINQ. En versiones anteriores, se usaba para generar varias instrucciones SQL en
ciertos casos, llamadas Include() traducidas en las propiedades de navegación de la colección y consultas
traducidas que seguían determinados patrones con subconsultas. Aunque en ocasiones este diseño resultaba
práctico y, en el caso de Include() , incluso ayudaba a evitar el envío de datos redundantes a través de la conexión,
la implementación era compleja y se producían algunos comportamientos considerablemente ineficaces (consultas
N+1). Había situaciones en las que los datos devueltos en varias consultas eran incoherentes en potencia.
De forma similar a la evaluación del cliente, si EF Core 3.0 no puede convertir una consulta LINQ en una única
instrucción SQL, se inicia una excepción en tiempo de ejecución. Pero hicimos que EF Core fuera capaz de traducir
muchos de los patrones comunes que solían generar varias consultas en una sola consulta con JOIN.
Compatibilidad con Cosmos DB

Con el proveedor de Cosmos DB para EF Core, los desarrolladores que están familiarizados con el modelo de
programación de EF puedan usar fácilmente Azure Cosmos DB como base de datos de aplicación. El objetivo es
hacer que algunas de las ventajas de Cosmos DB, como la distribución global, la disponibilidad "AlwaysOn", la
escalabilidad elástica y la baja latencia, sean aún más accesibles para los desarrolladores de .NET. El proveedor
habilita la mayoría de las características de EF Core, como el seguimiento automático de cambios, LINQ y
conversiones de valores, en comparación con SQL API de Cosmos DB.
Consulte la documentación del proveedor Cosmos DB para más detalles.
Compatibilidad con C# 8.0

EF Core 3.0 aprovecha varias características nuevas de C# 8.0:
Secuencias asincrónicas
Los resultados de la consulta asincrónica se exponen ahora mediante la nueva interfaz de IAsyncEnumerable<T>
estándar y se pueden usar con await foreach .
var orders =
from o in context.Orders
where o.Status == OrderStatus.Pending
select o;
await foreach(var o in orders.AsAsyncEnumerable())

{
Process(o);
}
Consulte las transmisiones asíncronas en la documentación de C# para más detalles.

Tipos de referencia que aceptan valores NULL
Cuando esta nueva característica está habilitada en el código, EF Core examina la nulabilidad de las propiedades de
tipo de referencia y la aplica a las columnas y relaciones correspondientes en la base de datos: las propiedades de
los tipos de referencia no anulables se tratan como si tuvieran el atributo de anotación de datos [Required] .
Por ejemplo, en la clase siguiente, las propiedades marcadas como de tipo string? se configurarán como
opcionales, mientras que string se configurará según sea necesario:
public class Customer
{
public int Id { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
public string? MiddleName { get; set; }
}
Consulte Trabajar con tipos de referencia que aceptan valores NULL en la documentación de EF Core para más
detalles.
Intercepción de operaciones de bases de datos

La nueva API de intercepción en EF Core 3.0 permite proporcionar una lógica personalizada que se invoca
automáticamente cada vez que se producen operaciones de base de datos de bajo nivel como parte del
funcionamiento normal de EF Core. Por ejemplo, al abrir conexiones, confirmar transacciones o ejecutar comandos.
De manera similar a las características de intercepción que existían en EF 6, los interceptores le permiten interceptar
operaciones antes o después de que sucedan. Cuando las intercepta antes de que sucedan, puede omitir la
ejecución y proporcionar resultados alternativos de la lógica de intercepción.
Por ejemplo, para manipular el texto del comando, puede crear IDbCommandInterceptor :
public class HintCommandInterceptor : DbCommandInterceptor

{
public override InterceptionResult ReaderExecuting(
DbCommand command,
CommandEventData eventData,
InterceptionResult result)
{
// Manipulate the command text, etc. here...
command.CommandText += " OPTION (OPTIMIZE FOR UNKNOWN)";
return result;
}
}
Y registrarlo con su DbContext :
services.AddDbContext(b => b
.UseSqlServer(connectionString)
.AddInterceptors(new HintCommandInterceptor()));
Ingeniería inversa de vistas de base de datos

El nombre de los tipos de consulta, que representan datos que pueden leerse de la base de datos pero no
actualizarse, se ha cambiado a tipos de entidad sin clave. Como son una excelente opción para asignar vistas de
bases de datos en la mayoría de los escenarios, EF Core ahora crea automáticamente tipos de entidades sin clave
cuando se invierten las vistas de bases de datos de ingeniería.
Por ejemplo, con la herramienta de línea de comandos dotnet ef, puede escribir:
dotnet ef dbcontext scaffold "Server=(localdb)\mssqllocaldb;Database=Blogging;Trusted_Connection=True;"

Y la herramienta ahora anulará automáticamente los tipos de scaffold para vistas y tablas sin claves:
{
modelBuilder.Entity<Names>(entity =>
{
entity.HasNoKey();
entity.ToView("Names");
});
modelBuilder.Entity<Things>(entity =>
{
entity.HasNoKey();
});
}
Ahora, las entidades dependientes que comparten la tabla con la

entidad de seguridad son opcionales
A partir de la versión EF Core 3.0, si OrderDetails pertenece a Order o está asignado a la misma tabla
explícitamente, será posible agregar Order sin OrderDetails ; todas las propiedades OrderDetails , salvo la clave
principal, se asignarán a columnas que aceptan valores NULL.
Al realizar consultas, EF Core establecerá OrderDetails en null si ninguna de las propiedades necesarias tiene un
valor, o bien no tiene las propiedades necesarias más allá de la clave principal y todas las propiedades son null .
public class Order

{
public int CustomerId { get; set; }
public OrderDetails Details { get; set; }
}
[Owned]
public class OrderDetails
{
public string ShippingAddress { get; set; }
}
EF 6.3 en .NET Core

Esta no es realmente una característica de EF Core 3.0, pero creemos que es importante para muchos de nuestros
clientes actuales.
Entendemos que muchas aplicaciones existentes utilizan versiones anteriores de EF y que portarlas a EF Core solo
para aprovechar las ventajas de .NET Core puede requerir un esfuerzo considerable. Por ese motivo, decidimos
portar a la versión más reciente de EF 6 para que se ejecute en .NET Core 3.0.
Para más detalles, consulte Novedades de EF 6.
Características pospuestas
Algunas características planeadas originalmente para EF Core 3.0 se pospusieron para versiones futuras:
Capacidad de omitir partes de un modelo en migraciones, con seguimiento realizado a través del problema nº
2725.
Entidades contenedoras de propiedades, de las que se realiza un seguimiento a través de dos problemas
independientes: nº 9914 sobre las entidades de tipo compartido y nº 13610 sobre la compatibilidad con la
asignación de propiedades indizadas.
Cambios importantes incluidos en EF Core 3.0
Es posible que los siguientes cambios de API y comportamiento interrumpan las aplicaciones actuales cuando se
actualicen a la versión 3.0.0. Los cambios que esperamos que solo afecten a proveedores de base de datos se
documentan en Cambios para proveedores.
Resumen
C A M B IO IM P O RTA N T E IM PA C TO
Las consultas LINQ ya no se evalúan en el cliente Alto
EF Core 3.0 tiene como destino .NET Standard 2.1, y no .NET Alto
Standard 2.0
La herramienta de línea de comandos de EF Core, dotnet ef, Alto

ya no forma parte del SDK de .NET Core
DetectChanges respeta los valores de clave generados por el Alto

almacén
FromSql, ExecuteSql y ExecuteSqlAsync han cambiado de Alto

nombre
Los tipos de consulta se consolidan con tipos de entidad Alto
Entity Framework Core ya no forma parte del marco Media

compartido ASP.NET Core
Las eliminaciones en cascada ahora se realizan Media

inmediatamente de forma predeterminada
La carga diligente de entidades relacionadas ahora se realiza Media

en una sola consulta
DeleteBehavior.Restrict tiene una semántica más limpia Media
La API de configuración para las relaciones de tipo de Media

propiedad ha cambiado
Cada propiedad usa la generación de claves enteras en Media

memoria independiente
Las consultas sin seguimiento ya no realizan la resolución de Media

la identidad
Cambios en la API de metadatos Media
Cambios en la API de metadatos específicos del proveedor Media

Se ha quitado el elemento UseRowNumberForPaging Media
Cuando el método FromSql se usa con un procedimiento Media

almacenado no se puede redactar
Solo se pueden especificar métodos de FromSql en raíces de Bajo

consulta
La ejecución de consultas se registra en el nivel de depuración Bajo

Revertido
Los valores de clave temporal ya no se establecen en Bajo

instancias de entidad
Las entidades dependientes que comparten la tabla con la Bajo

entidad de seguridad son ahora opcionales
Todas las entidades que compartan una tabla con una Bajo
columna de token de simultaneidad tienen que asignarla a
una propiedad
Las entidades en propiedad no se pueden consultar sin el Bajo

propietario mediante una consulta de seguimiento
Las propiedades heredadas de tipos sin asignar se asignan Bajo

ahora a una única columna para todos los tipos derivados
La convención de propiedad de clave externa ya no coincide Bajo

con el mismo nombre que la propiedad de entidad de
seguridad
La conexión de base de datos ahora se cierra si ya no se usa Bajo

antes de que se complete TransactionScope
Los campos de respaldo se usan de forma predeterminada Bajo
Inicio de excepciones si se encuentran varios campos de Bajo

respaldo compatibles
Los nombres de propiedades de solo campo deben coincidir Bajo

con el nombre del campo
AddDbContext/AddDbContextPool ya no llaman a Bajo

AddLogging ni a AddMemoryCache
AddEntityFramework* agrega IMemoryCache con un límite Bajo

de tamaño
DbContext.Entry realiza ahora una operación DetectChanges Bajo

local
El cliente no genera las claves de matriz de cadena y byte de Bajo

forma predeterminada
ILoggerFactory es ahora un servicio con ámbito Bajo
En los proxies de carga diferida ya no se supone que las Bajo

propiedades de navegación están totalmente cargadas
La creación excesiva de proveedores de servicios internos Bajo

ahora es un error de forma predeterminada
Comportamiento nuevo de HasOne/HasMany llamado con Bajo

una sola cadena
El tipo de valor devuelto para varios métodos asincrónicos se Bajo

ha cambiado de Task a ValueTask
La anotación Relational:TypeMapping ahora es simplemente Bajo

TypeMapping
ToTable en un tipo derivado produce una excepción Bajo
EF Core ya no envía pragma para el cumplimiento de SQLite Bajo

FK
Microsoft.EntityFrameworkCore.Sqlite ahora depende de Bajo

SQLitePCLRaw.bundle_e_sqlite3
Los valores GUID se almacenan ahora como TEXT en SQLite Bajo
Los valores char se almacenan ahora como TEXT en SQLite Bajo
Los id. de migración ahora se generan usando el calendario Bajo

de la referencia cultural invariable
La información o los metadatos de la extensión se han Bajo

quitado de IDbContextOptionsExtension
LogQueryPossibleExceptionWithAggregateOperator ha Bajo
cambiado de nombre
Clarificación de la API para nombres de restricciones de claves Bajo

externas
IRelationalDatabaseCreator.HasTables/HasTablesAsync se han Bajo

hecho públicos
Microsoft.EntityFrameworkCore.Design es ahora un paquete Bajo

DevelopmentDependency
SQLitePCL.raw se ha actualizado a la versión 2.0.0 Bajo
NetTopologySuite se actualizó a la versión 2.0.0 Bajo
Se usa Microsoft.Data.SqlClient en lugar de Bajo

System.Data.SqlClient
Se deben configurar varias relaciones de referencia Bajo

automática ambiguas
DbFunction.Schema es NULL o la cadena vacía lo configura Bajo

para estar en el esquema predeterminado del modelo
Las consultas LINQ ya no se evalúan en el cliente

Problema de seguimiento n.° 14935 Consulte también el problema n.° 12795
Compor tamiento anterior
Antes de 3.0, cuando en EF Core no se podía convertir una expresión que formaba parte de una consulta SQL o un
parámetro, la expresión se evaluaba de forma automática en el cliente. De forma predeterminada, la evaluación de
cliente de expresiones potencialmente costosas solo desencadenaba una advertencia.
Compor tamiento nuevo
A partir de 3.0, en EF Core solo se permite que se evalúen en el cliente las expresiones en la proyección de nivel
superior (la última llamada a Select() de la consulta). Cuando las expresiones de otra parte de la consulta no se
pueden convertir en SQL o un parámetro, se inicia una excepción.
Por qué
La evaluación de cliente automática de las consultas permite que se ejecuten muchas consultas incluso si no se
pueden convertir elementos importantes de ellas. Esto puede provocar un comportamiento inesperado y
potencialmente dañino que es posible que solo sea evidente en entornos de producción. Por ejemplo, una
condición en una llamada a Where() que no se puede convertir puede provocar que todas las filas de la tabla se
transfieran desde el servidor de base de datos y que el filtro se aplique en el cliente. Esta situación puede pasar
desapercibida fácilmente si la tabla solo contiene algunas filas en la fase de desarrollo, pero ser más grave cuando
la aplicación pase a producción, donde la tabla puede contener millones de filas. Las advertencias de evaluación
de cliente también se suelen pasar por alto durante el desarrollo.
Además de esto, la evaluación de cliente automática puede causar problemas en los que la mejora de la
traducción de consultas para expresiones específicas provocaba cambios importantes no deseados entre
versiones.
Mitigaciones
Si una consulta no se puede traducir totalmente, vuelva a escribirla en un formato que se pueda traducir, o bien
use AsEnumerable() , ToList() o una función similar para devolver los datos al cliente de forma explícita, donde
después se puedan seguir procesando mediante LINQ to Objects.
EF Core 3.0 tiene como destino .NET Standard 2.1, y no .NET Standard 2.0
Problema de seguimiento n.º 15498
IMPORTANT
EF Core 3.1 vuelve a tener como objetivo a .NET Standard 2.0. Esto reincorpora la compatibilidad con .NET Framework.

Antes de la versión 3.0, EF Core tenía como destino .NET Standard 2.0 y se podía ejecutar en todas las plataformas
que admitieran dicho estándar, incluido .NET Framework.
A partir de la versión 3.0, EF Core tiene como destino .NET Standard 2.1 y se puede ejecutar en todas las
plataformas que admitan dicho estándar. Esto no incluye .NET Framework.
Por qué
Esto forma parte de una decisión estratégica para todas las tecnologías de .NET que tiene como objetivo centrar
los esfuerzos en .NET Core y otras plataformas modernas de .NET, como Xamarin.
Mitigaciones
Use EF Core 3.1.
Entity Framework Core ya no forma parte del marco compartido ASP.NET Core
Anuncios del problema de seguimiento n.º 325
Antes de ASP.NET Core 3.0, cuando se agregaba una referencia de paquete a Microsoft.AspNetCore.App o
Microsoft.AspNetCore.All , se incluía EF Core y algunos de los proveedores de datos de EF Core, como el de SQL
Server.
A partir de la versión 3.0, el marco compartido ASP.NET Core no incluye EF Core ni ningún proveedor de datos de
EF Core.
Por qué
Antes de este cambio, para obtener EF Core se necesitaban varios pasos en función de si la aplicación se destinaba
a ASP.NET Core y SQL Server o no. Además, la actualización de ASP.NET Core forzaba la de EF Core y el proveedor
de SQL Server, lo que no siempre es deseable.
Con este cambio, la experiencia de obtención de EF Core es la misma en todos los proveedores, implementaciones
admitidas de .NET y tipos de aplicación. Ahora los desarrolladores también pueden controlar exactamente cuándo
se actualizan EF Core y los proveedores de datos de EF Core.
Mitigaciones
Para usar EF Core en una aplicación ASP.NET Core 3.0 o cualquier otra aplicación compatible, debe agregar de
forma explícita una referencia de paquete al proveedor de base de datos de EF Core que se va a usar en la
aplicación.
La herramienta de línea de comandos de EF Core, dotnet ef, ya no forma parte del SDK de .NET Core
Antes de 3.0, la herramienta dotnet ef se incluía en el SDK de .NET Core y estaba disponible para usarse desde la
línea de comandos de cualquier proyecto sin necesidad de realizar pasos adicionales.
A partir de la versión 3.0, el SDK de .NET no incluye la herramienta dotnet ef , por lo que antes de poder usarla
tendrá que instalarla de forma explícita como una herramienta local o global.
Por qué
Este cambio nos permite distribuir y actualizar dotnet ef como una herramienta convencional de la CLI de .NET
en NuGet, coherente con el hecho de que la versión 3.0 de EF Core también se distribuye siempre como un
paquete NuGet.
Mitigaciones
Para poder administrar las migraciones o aplicar scaffolding a DbContext , instale dotnet-ef como herramienta
global:
$ dotnet tool install --global dotnet-ef
También se puede obtener una herramienta local cuando se restauran las dependencias de un proyecto que la
declara como una dependencia de herramientas mediante un archivo de manifiesto de herramientas.
FromSql, ExecuteSql y ExecuteSqlAsync han cambiado de nombre
Antes de EF Core 3.0, estos nombres de métodos se sobrecargaban para funcionar tanto con una cadena normal
como con una cadena que se debería interpolar en SQL y parámetros.
A partir de la versión EF Core 3.0, use FromSqlRaw , ExecuteSqlRaw y ExecuteSqlRawAsync para crear una consulta
con parámetros donde los parámetros se pasan por separado de la cadena de consulta. Por ejemplo:
context.Products.FromSqlRaw(
"SELECT * FROM Products WHERE Name = {0}",
product.Name);
Use FromSqlInterpolated , ExecuteSqlInterpolated y ExecuteSqlInterpolatedAsync para crear una consulta con

parámetros donde los parámetros se pasan como parte de una cadena de consulta interpolada. Por ejemplo:
context.Products.FromSqlInterpolated(
$"SELECT * FROM Products WHERE Name = {product.Name}");
Tenga en cuenta que las dos consultas anteriores producirán el mismo código SQL parametrizado con los mismos
parámetros SQL.
Por qué
Las sobrecargas del método como esta facilitan las llamadas accidentales al método de cadena sin procesar
cuando la intención era llamar al método de cadena interpolada y viceversa. Esto podría resultar en consultas que
no se parametrizan cuando deberían.
Mitigaciones
Haga el cambio para usar los nuevos nombres de métodos.
Cuando el método FromSql se usa con un procedimiento almacenado no se puede redactar
Problema de seguimiento n.° 15392
Antes de EF Core 3.0, el método FromSql intentaba detectar si se podía redactar en el código SQL pasado. Cuando
el código SQL no se podía redactar, como un procedimiento almacenado, realizaba la evaluación de cliente. La
consulta siguiente funcionaba al ejecutar el procedimiento almacenado en el servidor y aplicar FirstOrDefault en
el lado cliente.
context.Products.FromSqlRaw("[dbo].[Ten Most Expensive Products]").FirstOrDefault();

A partir de EF Core 3.0, EF Core no intentará analizar el código SQL. Por tanto, si va a redactar después de
FromSqlRaw/FromSqlInterpolated, EF Core redactará el código SQL generando una subconsulta. Por tanto, si usa
un procedimiento almacenado con la redacción, obtendrá una excepción de sintaxis de SQL no válida.
Por qué
EF Core 3.0 no admite la evaluación automática de cliente, ya que era propenso a errores, como se explica aquí.
Mitigación
Si usa un procedimiento almacenado en FromSqlRaw/FromSqlInterpolated, sabe que no se puede redactar, por lo
que puede agregar AsEnumerable/AsAsyncEnumerable justo después de la llamada al método FromSql para
evitar cualquier redacción en el lado servidor.
context.Products.FromSqlRaw("[dbo].[Ten Most Expensive Products]").AsEnumerable().FirstOrDefault();
Solo se pueden especificar métodos de FromSql en raíces de consulta.

Antes de EF Core 3.0, el método FromSql podía especificarse en cualquier lugar en la consulta.
A partir de EF Core 3.0, los nuevos métodos FromSqlRaw y FromSqlInterpolated (que reemplazan a FromSql ) solo
pueden especificarse en las raíces de la consulta, es decir, directamente en DbSet<> . Si intenta especificarlos en
cualquier otro lugar se producirá un error de compilación.
Por qué
La especificación de FromSql en cualquier otro lugar diferente de DbSet no tenía un significado o valor agregado,
y podría causar ambigüedad en ciertos escenarios.
Mitigaciones
Las invocaciones de FromSql se deben mover para que estén directamente en el DbSet al que se aplican.
Las consultas sin seguimiento ya no realizan la resolución de la identidad
Antes de EF Core 3.0, se usaba la misma instancia de la entidad para cada aparición de una entidad con un tipo e
identificador determinados. Este comportamiento coincide con el de las consultas de seguimiento. Por ejemplo,
esta consulta:
var results = context.Products.Include(e => e.Category).AsNoTracking().ToList();
Esta consulta devolverá la misma instancia de Category para cada elemento Product asociado con la categoría
determinada.
A partir de EF Core 3.0, se crean distintas instancias de la entidad si se encuentra una entidad con un tipo e
identificador determinados en varias ubicaciones del gráfico devuelto. Por ejemplo, la consulta anterior ahora
devolverá una nueva instancia de Category para cada elemento Product cuando haya dos productos asociados a
la misma categoría.
Por qué
La resolución de las identidades (es decir, el hecho de determinar que una entidad tiene los mismos tipo e
identificador que la entidad encontrada) agrega más rendimiento y sobrecarga de memoria. Este enfoque suele
ser contrario a por qué las consultas sin seguimiento se usan en primer lugar. Además, aunque la resolución de las
identidades a veces puede resultar útil, no es necesaria si las entidades se van a serializar y enviar a un cliente,
algo habitual para las consultas sin seguimiento.
Mitigaciones
Si se requiere la resolución de identidad, use una consulta de seguimiento.
La ejecución de consultas se registra en el nivel de depuración Revertido
Revertimos este cambio porque la nueva configuración de EF Core 3.0 permite a la aplicación especificar el nivel
de registro para cualquier evento. Por ejemplo, para cambiar el registro de SQL a Debug , configure el nivel de
forma explícita en OnConfiguring o AddDbContext :

=> optionsBuilder
.ConfigureWarnings(c => c.Log((RelationalEventId.CommandExecuting, LogLevel.Debug)));
Los valores de clave temporal ya no se establecen en instancias de entidad

Antes de EF Core 3.0, los valores temporales se asignaban a todas las propiedades de clave para las que
posteriormente la base de datos generaba un valor real. Normalmente, estos valores temporales eran números
negativos grandes.
A partir de la versión 3.0, en EF Core se almacena el valor de clave temporal como parte de la información de
seguimiento de la entidad y la propiedad clave en sí no se modifica.
Por qué
Este cambio se ha realizado para evitar que los valores de clave temporales se conviertan erróneamente en
permanentes cuando una entidad de la que previamente una instancia de DbContext ha realizado el seguimiento
se mueve a otra instancia de DbContext .
Mitigaciones
Las aplicaciones que asignan valores de clave principal a claves externas para crear asociaciones entre entidades
pueden depender del comportamiento anterior si las claves principales son generadas por el almacén y
pertenecen a entidades en el estado Added . Esto se puede evitar con las siguientes situaciones:
No se usan claves generadas por el almacén.
Se establecen propiedades de navegación para crear relaciones en lugar de establecer valores de clave externa.
Se obtienen los valores de clave temporal reales de la información de seguimiento de la entidad. Por ejemplo,
context.Entry(blog).Property(e => e.Id).CurrentValue devolverá el valor temporal aunque no se haya
establecido blog.Id .
DetectChanges respeta los valores de clave generados por el almacén
Antes de EF Core 3.0, se realizaba el seguimiento en el estado DetectChanges de las entidades sin seguimiento
detectadas por Added y se insertaban como una fila nueva cuando se llamaba a SaveChanges .
A partir de EF Core 3.0, si una entidad usa valores de clave generados y se establece un valor de clave, se realizará
el seguimiento de la entidad en el estado Modified . Esto significa que se supone que existe una fila para la
entidad y que se actualizará cuando se llame a SaveChanges . Si no se establece el valor de clave, o bien si el tipo
de entidad no usa claves generadas, se seguirá realizando el seguimiento de la entidad nueva como Added al
igual que en las versiones anteriores.
Por qué
Este cambio se ha realizado para que sea más sencillo y coherente trabajar con gráficos de entidades
desconectadas mientras se usan claves generadas por el almacén.
Mitigaciones
Este cambio puede interrumpir una aplicación si se configura un tipo de entidad para usar claves generadas, pero
se establecen de forma explícita valores de clave para las instancias nuevas. La solución consiste en configurar de
forma explícita las propiedades de clave para que no usen valores generados. Por ejemplo, con la API fluida:
modelBuilder
.Entity<Blog>()
.Property(e => e.Id)
.ValueGeneratedNever();
O bien con anotaciones de datos:
[DatabaseGenerated(DatabaseGeneratedOption.None)]
public string Id { get; set; }
Las eliminaciones en cascada ahora se realizan inmediatamente de forma predeterminada

Antes de la versión 3.0, en EF Core no se aplicaban acciones en cascada (eliminación de entidades dependientes
cuando se eliminaba una entidad de seguridad obligatoria o cuando se rompía la relación con una entidad de
seguridad obligatoria) hasta que se llamaba a SaveChanges.
A partir de 3.0, en EF Core las acciones en cascada se aplican en cuanto se detecta la condición desencadenadora.
Por ejemplo, como resultado de la llamada a context.Remove() para eliminar una entidad de seguridad, todos los
dependientes obligatorios relacionados de los que se realiza el seguimiento también se establecen en Deleted
inmediatamente.
Por qué
Este cambio se ha realizado para mejorar la experiencia en escenarios de auditoría y enlace de datos, donde es
importante comprender qué entidades se van a eliminar antes de llamar a SaveChanges .
Mitigaciones
El comportamiento anterior se puede restaurar mediante opciones de context.ChangeTracker . Por ejemplo:
context.ChangeTracker.CascadeDeleteTiming = CascadeTiming.OnSaveChanges;
context.ChangeTracker.DeleteOrphansTiming = CascadeTiming.OnSaveChanges;
La carga diligente de entidades relacionadas ahora se realiza en una sola consulta

Antes de la versión 3.0, la carga diligente de navegaciones de colección a través de operadores Include
provocaba la generación de varias consultas en la base de datos relacional, una para cada tipo de entidad
relacionada.
A partir de la versión 3.0, EF Core genera una sola consulta con operadores JOIN en las bases de datos
relacionales.
Por qué
La emisión de varias consultas para implementar una única consulta LINQ provocaba numerosos problemas,
incluido el rendimiento negativo, ya que se necesitaban varios recorridos de ida y vuelta a la base de datos, y
problemas de coherencia de datos, ya que cada consulta podía observar un estado distinto de la base de datos.
Mitigaciones
Aunque técnicamente esto no es un cambio importante, podría tener un efecto considerable en el rendimiento de
la aplicación cuando una sola consulta contiene un gran número de operadores Include en las navegaciones de
la colección. Vea este comentario para obtener más información y para volver a escribir las consultas de una
manera más eficaz.
**
DeleteBehavior.Restrict tiene una semántica más limpia
Antes de la versión 3.0, DeleteBehavior.Restrict creaba claves externas en la base de datos con la semántica
Restrict , pero también realizaba una corrección interna de manera no evidente.

A partir de la versión 3.0, DeleteBehavior.Restrict garantiza que las claves externas se crean con la semántica
Restrict , es decir, sin cascadas y realizando una infracción de restricción, sin llevar a cabo correcciones internas
de EF.
Por qué
Este cambio se realizó para mejorar la experiencia de uso de DeleteBehavior de manera intuitiva sin efectos
secundarios inesperados.
Mitigaciones
El comportamiento anterior se puede restaurar con DeleteBehavior.ClientNoAction .
Los tipos de consulta se consolidan con tipos de entidad
Antes de EF Core 3.0, los tipos de consulta eran un medio para consultar los datos que no definen una clave
principal de una manera estructurada. Es decir, un tipo de consulta se usaba para asignar tipos de entidad sin
claves (más probablemente desde una vista, pero posiblemente desde una tabla), mientras que un tipo de entidad
estándar se usaba cuando había una clave disponible (más probablemente desde una tabla, pero posiblemente
desde una vista).
Ahora un tipo de consulta se convierte en un tipo de entidad sin una clave principal. Los tipos de entidad sin clave
tienen la misma funcionalidad que los tipos de consulta de las versiones anteriores.
Por qué
Este cambio se ha realizado para reducir la confusión en torno a la finalidad de los tipos de consulta. En concreto,
son tipos de entidad sin clave y, por ello, intrínsecamente son de solo lectura, pero no se deben usar solo porque
un tipo de entidad tenga que ser de solo lectura. Del mismo modo, se suelen asignar a vistas, pero solo porque las
vistas no suelen definir claves.
Mitigaciones
Los elementos siguientes de la API ahora están obsoletos:
ModelBuilder.Query<>() : en su lugar es necesario llamar a ModelBuilder.Entity<>().HasNoKey() para marcar
un tipo de entidad como sin claves. Esto todavía no se configurará por convención para evitar una
configuración incorrecta cuando se espera una clave principal, pero no coincide con la convención.
DbQuery<> : en su lugar se debe usar DbSet<> .
DbContext.Query<>() : en su lugar se debe usar DbContext.Set<>() .
La API de configuración para las relaciones de tipo de propiedad ha cambiado

Problema de seguimiento n.º 12444 Problema de seguimiento n.º 9148 Problema de seguimiento n.º 14153
Antes de EF Core 3.0, la configuración de la relación de propiedad se realizaba directamente después de la
llamada a OwnsOne o OwnsMany .
A partir de EF Core 3.0, ahora hay una API fluida para configurar una propiedad de navegación para el propietario
mediante WithOwner() . Por ejemplo:
modelBuilder.Entity<Order>.OwnsOne(e => e.Details).WithOwner(e => e.Order);
La configuración relacionada con la relación entre el propietario y lo que se posee ahora se debe encadenar
después de WithOwner() , de forma similar a cómo se configuran otras relaciones. Pero la configuración del propio
tipo de propiedad se seguirá encadenando después de OwnsOne()/OwnsMany() . Por ejemplo:
modelBuilder.Entity<Order>.OwnsOne(e => e.Details, eb =>
{
eb.WithOwner()
.HasForeignKey(e => e.AlternateId)
.HasConstraintName("FK_OrderDetails");
eb.ToTable("OrderDetails");
eb.HasKey(e => e.AlternateId);
eb.HasIndex(e => e.Id);
eb.HasOne(e => e.Customer).WithOne();
eb.HasData(
new OrderDetails
{
AlternateId = 1,
Id = -1
});
});
Además, la llamada a Entity() , HasOne() o Set() con un tipo de propiedad de destino ahora iniciará una
excepción.
Por qué
Este cambio se ha realizado para crear una separación más clara entre la configuración del propio tipo de
propiedad y la relación con el tipo de propiedad. A su vez, esto elimina la ambigüedad y la confusión de métodos
como HasForeignKey .
Mitigaciones
Cambie la configuración de las relaciones de tipo de propiedad para usar la nueva superficie de API, como se
muestra en el ejemplo anterior.
Ahora, las entidades dependientes que comparten la tabla con la entidad de seguridad son opcionales
Considere el modelo siguiente:
public class Order

{
}

{
}
Antes de EF Core 3.0, si OrderDetails era propiedad de Order o estaba asignado explícitamente a la misma tabla,
siempre era necesaria una instancia de OrderDetails al agregar un elemento Order nuevo.
A partir de la versión 3.0, EF Core permite agregar Order sin OrderDetails y asigna todas las propiedades
OrderDetails a excepción de la clave principal a columnas que aceptan valores NULL. Al realizar consultas, EF
Core establece OrderDetails en null si ninguna de las propiedades necesarias tiene un valor o si no tiene
propiedades necesarias más allá de la clave principal y todas las propiedades son null .
Mitigaciones
Si el modelo tiene una tabla que comparte dependencias con todas las columnas opcionales, pero la navegación
que apunta a ella no se espera que sea null , la aplicación debería modificarse para controlar los casos en los que
la navegación sea null . Si esto no es posible, debería agregarse una propiedad necesaria al tipo de entidad o, al
menos, una entidad debería tener un valor distinto a null asignado.
Todas las entidades que compartan una tabla con una columna de token de simultaneidad tienen que asignarla
a una propiedad
public class Order

{
public byte[] Version { get; set; }
}

{
}

{
modelBuilder.Entity<Order>()
.Property(o => o.Version).IsRowVersion().HasColumnName("Version");
}
Antes de EF Core 3.0, si OrderDetails era propiedad de Order o estaba asignado explícitamente a la misma tabla,
si solo se actualizaba OrderDetails , no se actualizaba el valor Version en el cliente y se producía un error en la
próxima actualización.
A partir de la versión 3.0, EF Core propaga el nuevo valor Version en Order si posee OrderDetails . En caso
contrario, se produce una excepción durante la validación del modelo.
Por qué
Este cambio se realizó para evitar un valor de token de simultaneidad obsoleto cuando solo se actualiza una de las
entidades asignadas a la misma tabla.
Mitigaciones
Todas las entidades que comparten la tabla deben incluir una propiedad que se asigna a la columna del token de
simultaneidad. Es posible crear una en estado reemplazado:
{
modelBuilder.Entity<OrderDetails>()
.Property<byte[]>("Version").IsRowVersion().HasColumnName("Version");
}
Las entidades en propiedad no se pueden consultar sin el propietario mediante una consulta de seguimiento
Antes de EF Core 3.0, las entidades en propiedad se podían consultar como cualquier otra navegación.
context.People.Select(p => p.Address);

A partir de la versión 3.0, EF Core iniciará una excepción si una consulta de seguimiento proyecta una entidad en
propiedad sin el propietario.
Por qué
Las entidades en propiedad no se pueden manipular sin el propietario, por lo que en la mayoría de los casos es un
error consultarlas de esta manera.
Mitigaciones
Si se debe realizar el seguimiento de la entidad en propiedad para modificarla de cualquier manera posterior, el
propietario se debe incluir en la consulta.
De lo contrario, agregue una llamada a AsNoTracking() :
context.People.Select(p => p.Address).AsNoTracking();
Ahora, las propiedades heredadas de tipos sin asignar se asignan a una única columna para todos los tipos
derivados
public abstract class EntityBase
{
}
public abstract class OrderBase : EntityBase

{
public int ShippingAddress { get; set; }
}
public class BulkOrder : OrderBase

{
}
public class Order : OrderBase

{
}

{
modelBuilder.Ignore<OrderBase>();
modelBuilder.Entity<EntityBase>();
modelBuilder.Entity<BulkOrder>();
modelBuilder.Entity<Order>();
}
Antes de EF Core 3.0, la propiedad ShippingAddress se asignaba a columnas distintas para BulkOrder y Order de
forma predeterminada.
A partir de la versión3.0, EF Core solo crea una columna para ShippingAddress .
Por qué
El comportamiento anterior no era el esperado.
Mitigaciones
Todavía se puede asignar explícitamente la propiedad a columnas separadas en los tipos derivados:

{
modelBuilder.Ignore<OrderBase>();
modelBuilder.Entity<EntityBase>();
modelBuilder.Entity<BulkOrder>()
.Property(o => o.ShippingAddress).HasColumnName("BulkShippingAddress");
.Property(o => o.ShippingAddress).HasColumnName("ShippingAddress");
}
La convención de propiedad de clave externa ya no coincide con el mismo nombre que la propiedad de
entidad de seguridad
{
public ICollection<Order> Orders { get; set; }
}
public class Order

{
}
Antes de EF Core 3.0, se podía usar la propiedad CustomerId para la clave externa por convención. Pero si Order
es un tipo de propiedad, entonces esto convertiría también a CustomerId en la clave principal, algo que no suele
ser lo esperado.
A partir de la versión 3.0, EF Core no intenta usar las propiedades de claves externas por convención si tienen el
mismo nombre que la propiedad de entidad de seguridad. Los patrones de nombre de tipo de entidad de
seguridad concatenado con el nombre de propiedad de la entidad de seguridad y de nombre de navegación
concatenado con el nombre de propiedad de la entidad de seguridad todavía se hacen coincidir. Por ejemplo:

{
}
public class Order

{
}

{
}
public class Order

{
public int BuyerId { get; set; }
public Customer Buyer { get; set; }
}
Por qué
Este cambio se ha realizado para evitar definir erróneamente una propiedad de clave principal en el tipo de
propiedad.
Mitigaciones
Si la propiedad se ha diseñado para ser la clave externa y, por tanto, parte de la clave principal, se debe configurar
explícitamente como tal.
Ahora, la conexión de base de datos se cierra si ya no se usa antes de que se complete TransactionScope
Antes de EF Core 3.0, si el contexto abría la conexión dentro de TransactionScope , la conexión permanecía abierta
mientras el ámbito actual TransactionScope estuviese activo.
using (new TransactionScope())

{
using (AdventureWorks context = new AdventureWorks())
{
context.ProductCategories.Add(new ProductCategory());
context.SaveChanges();
// Old behavior: Connection is still open at this point
var categories = context.ProductCategories().ToList();

}
}

A partir de la versión 3.0, EF Core cierra la conexión en cuanto se deja de usar.
Por qué
Este cambio permite usar varios contextos en el mismo ámbito TransactionScope . El comportamiento nuevo
también coincide con el de EF6.
Mitigaciones
Si la conexión debe permanecer abierta, una llamada explícita a OpenConnection() asegurará que EF Core no la
cierre de forma prematura:
using (new TransactionScope())

{
using (AdventureWorks context = new AdventureWorks())
{
context.Database.OpenConnection();
context.ProductCategories.Add(new ProductCategory());
var categories = context.ProductCategories().ToList();

context.Database.CloseConnection();
}
}
Cada propiedad usa la generación de claves enteras en memoria independiente

Antes de EF Core 3.0, se usaba un generador de valores compartidos para todas las propiedades de clave entera
en memoria.
A partir de EF Core 3.0, cada propiedad de clave entera obtiene su propio generador de valores cuando se usa la
base de datos en memoria. Además, si se elimina la base de datos, la generación de claves se restablece para
todas las tablas.
Por qué
Este cambio se ha realizado para alinear la generación de claves en memoria más estrechamente a la generación
de claves de base de datos reales y para mejorar la capacidad para aislar las pruebas entre sí cuando se usa la
base de datos en memoria.
Mitigaciones
Esto puede interrumpir una aplicación que se base en el establecimiento de valores de clave específicos en
memoria. En su lugar, considere la posibilidad de no depender de valores de clave específicos, o bien de actualizar
para que coincida con el comportamiento nuevo.
Los campos de respaldo se usan de forma predeterminada
Antes de la versión 3.0, incluso si se conocía el campo de respaldo de una propiedad, de forma predeterminada en
EF Core se leía y escribía el valor de propiedad mediante los métodos captadores y establecedores de
propiedades. La excepción era la ejecución de consultas, donde el campo de respaldo se establecía directamente si
se conocía.
A partir de EF Core 3.0, si se conoce el campo de respaldo para una propiedad, EF Core siempre la leerá y escribirá
mediante el campo de respaldo. Esto podría provocar una interrupción de la aplicación si depende de un
comportamiento adicional codificado en los métodos captadores o establecedores.
Por qué
Este cambio se ha realizado para evitar que EF Core desencadene erróneamente lógica de negocios de forma
predeterminada al realizar operaciones de base de datos que implican entidades.
Mitigaciones
El comportamiento anterior a la versión 3.0 se puede restaurar mediante la configuración del modo de acceso de
propiedad en ModelBuilder . Por ejemplo:
modelBuilder.UsePropertyAccessMode(PropertyAccessMode.PreferFieldDuringConstruction);
Inicio de excepciones si se encuentran varios campos de respaldo compatibles

Antes de EF Core 3.0, si varios campos coincidían con las reglas para buscar el campo de respaldo de una
propiedad, se elegía un campo según un orden de prioridad. Esto podía producir que, en caso de ambigüedad, se
usara el campo incorrecto.
A partir de EF Core 3.0, si varios campos coinciden con la misma propiedad, se inicia una excepción.
Por qué
Este cambio se ha realizado para evitar de forma silenciosa el uso de un campo con respecto a otro cuando solo
uno puede ser correcto.
Mitigaciones
En las propiedades con campos de respaldo ambiguos se debe especificar de forma explícita el campo que se va
usar. Por ejemplo, con la API fluida:
modelBuilder
.Entity<Blog>()
.HasField("_id");
Los nombres de propiedades de solo campo deben coincidir con el nombre del campo
Antes de EF Core 3.0, una propiedad podía especificarse con un valor de cadena y, si no había ninguna propiedad
con ese nombre en el tipo .NET, EF Core intentaba hacerla coincidir con un campo mediante reglas de convención.
private class Blog

{
private int _id;
public string Name { get; set; }
}
modelBuilder
.Entity<Blog>()
.Property("Id");

A partir de EF Core 3.0, una propiedad de solo campo debe coincidir exactamente con el nombre del campo.
modelBuilder
.Entity<Blog>()
.Property("_id");
Por qué
Este cambio se realizó para evitar el uso del mismo campo para dos propiedades con nombres similares. También
hace que las reglas de coincidencia para propiedades solo de campo sean las mismas que para las propiedades
asignadas a propiedades CLR.
Mitigaciones
Las propiedades solo de campo deberían tener el mismo nombre que el campo al que están asignadas. En una
próxima versión de EF Core 3.0 tenemos planeado volver a habilitar la configuración explícita de un nombre de
campo distinto al nombre de la propiedad (vea el problema n.° 15307):
modelBuilder
.Entity<Blog>()
.Property("Id")
.HasField("_id");
AddDbContext/AddDbContextPool ya no llaman a AddLogging ni a AddMemoryCache

Antes de EF Core 3.0, la llamada a AddDbContext o AddDbContextPool también podría registrar los servicios de
almacenamiento en caché y de registro con inserción de dependencias a través de llamadas a AddLogging y
AddMemoryCache.
A partir de EF Core 3.0, AddDbContext y AddDbContextPool ya no registrarán estos servicios con inserción de
dependencias (DI).
Por qué
EF Core 3.0 no requiere que estos servicios estén en el contenedor de inserción de dependencias de la aplicación.
Pero si ILoggerFactory se registra en el contenedor de DI de la aplicación, EF Core lo empezará a usar de todos
modos.
Mitigaciones
Si la aplicación necesita estos servicios, regístrelos de manera explícita con el contenedor de DI mediante
AddLogging o AddMemoryCache.
AddEntityFramework* agrega IMemoryCache con un límite de tamaño
Antes de EF Core 3.0, la llamada a los métodos AddEntityFramework* también registraba los servicios de
almacenamiento en caché de memoria con inserción de dependencias sin límite de tamaño.
A partir de EF Core 3.0, AddEntityFramework* registrará un servicio IMemoryCache con un límite de tamaño. Si
otros servicios agregados después dependen de IMemoryCache, pueden alcanzar rápidamente el límite
predeterminado y provocar excepciones o un rendimiento degradado.
Por qué
El uso de IMemoryCache sin un límite podría dar lugar a un uso de memoria no controlado si hay un error en la
lógica de almacenamiento en caché de las consultas o las consultas se generan de forma dinámica. Tener un límite
predeterminado mitiga un posible ataque DoS.
Mitigaciones
En la mayoría de los casos, no es necesario llamar a AddEntityFramework* si también se llama a AddDbContext o
AddDbContextPool . Por tanto, la mejor mitigación consiste en quitar la llamada a AddEntityFramework* .
Si la aplicación necesita estos servicios, registre de forma explícita una implementación de IMemoryCache con el
contenedor de DI por anticipado mediante AddMemoryCache.
Ahora DbContext.Entry realiza una operación DetectChanges local
Antes de EF Core 3.0, la llamada a DbContext.Entry provocaba que se detectaran cambios para todas las
entidades con seguimiento. Esto garantizaba que el estado expuesto en EntityEntry estuviera actualizado.
A partir de EF Core 3.0, ahora la llamada a DbContext.Entry solo intenta detectar cambios en la entidad dada y
cualquier entidad de seguridad relacionada con ella de la que se haya realizado el seguimiento. Esto significa que
es posible que la llamada a este método no haya detectado otros cambios, lo que podría tener implicaciones en el
estado de la aplicación.
Observe que si ChangeTracker.AutoDetectChangesEnabled se establece en false incluso esta detección de cambios
local se deshabilitará.
Otros métodos que provocan la detección de cambios (como ChangeTracker.Entries y SaveChanges ) siguen
provocando una acción DetectChanges completa de todas las entidades de las que se realiza el seguimiento.
Por qué
Este cambio se ha realizado para mejorar el rendimiento predeterminado del uso de context.Entry .
Mitigaciones
Llame a ChangeTracker.DetectChanges() de forma explícita antes de llamar a Entry para garantizar el
comportamiento anterior a la versión 3.0.
El cliente no genera las claves de matriz de cadena y byte de forma predeterminada
Antes de EF Core 3.0, se podían usar las propiedades de clave string y byte[] sin tener que establecer de forma
explícita un valor distinto de NULL. En ese caso, el valor de clave se generaba en el cliente como un GUID, que se
serializaba en bytes para byte[] .
A partir de EF Core 3.0, se iniciará una excepción en la que indica que no se ha establecido ningún valor de clave.
Por qué
Este cambio se ha realizado porque los valores string / byte[] generados por el cliente no suelen ser útiles, y el
comportamiento predeterminado dificultaba razonar sobre los valores de clave generados de una forma habitual.
Mitigaciones
Se puede obtener el comportamiento anterior a la versión 3.0 si se especifica de forma explícita que las
propiedades de clave deben usar los valores generados si no se establece ningún otro valor distinto de NULL. Por
ejemplo, con la API fluida:
modelBuilder
.Entity<Blog>()
.ValueGeneratedOnAdd();
O bien con anotaciones de datos:
[DatabaseGenerated(DatabaseGeneratedOption.Identity)]
Ahora ILoggerFactory es un servicio con ámbito

Antes de EF Core 3.0, ILoggerFactory se registraba como un servicio de singleton.
A partir de EF Core 3.0, ILoggerFactory ahora se registra como con ámbito.
Por qué
Este cambio se ha realizado para permitir la asociación de un registrador con una instancia de DbContext , lo que
habilita otras funciones y quita algunos casos de comportamiento patológico como un aumento vertiginoso de
los proveedores de servicios internos.
Mitigaciones
Este cambio no debería afectar al código de la aplicación a menos que registre y use servicios personalizados en
el proveedor de servicios internos de EF Core. Esto no es habitual. En estos casos, la mayoría de los elementos
seguirá funcionando, pero cualquier servicio de singleton que dependiera de ILoggerFactory tendrá que
cambiarse para obtener la interfaz ILoggerFactory de otra forma.
Si experimenta situaciones como esta, registre un problema en el rastreador de problemas de GitHub de EF Core
para hacernos saber cómo usa ILoggerFactory , para que podamos comprender mejor cómo evitar esta
interrupción en el futuro.
En los proxies de carga diferida ya no se supone que las propiedades de navegación están totalmente cargadas
Antes de EF Core 3.0, una vez que se eliminaba DbContext no había ninguna forma de saber si una determinada
propiedad de navegación de una entidad obtenida de ese contexto se había cargado completamente o no. En su
lugar, los proxies asumían que una navegación de referencia se cargaba si tenía un valor distinto de NULL, y que
una navegación de colección se cargaba si no estaba vacía. En estos casos, el intento de carga diferida era no
operativo.
A partir de EF Core 3.0, los proxies realizan el seguimiento de si una propiedad de navegación se carga o no. Esto
significa que el intento de acceder a una propiedad de navegación que se carga después de que se haya eliminado
el contexto siempre será no operativo, incluso cuando la navegación cargada está vacía o es NULL. Por el
contrario, el intento de acceder a una propiedad de navegación que no está cargada iniciará una excepción si el
contexto se ha eliminado, incluso si la propiedad de navegación es una colección no vacía. Si se produce esta
situación, significa que el código de aplicación está intentando usar la carga diferida en un momento no válido y
que se debe cambiar la aplicación para que lo no haga.
Por qué
Este cambio se ha realizado para que el comportamiento sea coherente y correcto cuando se intenta la carga
diferida de una instancia de DbContext eliminada.
Mitigaciones
Actualice el código de la aplicación para que no intente la carga diferida con un contexto eliminado, o bien
configúrelo para que sea no operativo, como se describe en el mensaje de la excepción.
La creación excesiva de proveedores de servicios internos ahora es un error de forma predeterminada
Antes de EF Core 3.0, se registraba una advertencia para una aplicación que creaba un número patológico de
proveedores de servicios internos.
A partir de EF Core 3.0, ahora esta advertencia se considera un error y se inicia una excepción.
Por qué
Este cambio se ha realizado para controlar mejor el código de la aplicación mediante la exposición de este caso
patológico de una forma más explícita.
Mitigaciones
Cuando se produce este error, la acción más adecuada consiste en comprender la causa raíz y detener la creación
de tantos proveedores de servicios internos. Pero el error se puede convertir en una advertencia (u omitirse)
mediante configuración en DbContextOptionsBuilder . Por ejemplo:

{
optionsBuilder
.ConfigureWarnings(w => w.Log(CoreEventId.ManyServiceProvidersCreatedWarning));
}
Comportamiento nuevo de HasOne/HasMany llamado con una sola cadena

Antes de EF Core 3.0, el código para llamar a HasOne o HasMany con una cadena se interpretaba de manera
confusa. Por ejemplo:
modelBuilder.Entity<Samurai>().HasOne("Entrance").WithOne();
El código parece relacionar Samurai con otro tipo de entidad mediante la propiedad de navegación Entrance ,
que puede ser privada.
En realidad, este código intenta crear una relación con algún tipo de entidad denominada Entrance sin ninguna
propiedad de navegación.
A partir de EF Core 3.0, el código anterior ahora hace lo que parecía que debía hacer antes.
Por qué
El comportamiento anterior era muy confuso, especialmente al leer el código de configuración y al buscar errores.
Mitigaciones
Esto solo interrumpirá las aplicaciones que configuran de manera explícita las relaciones con cadenas para
nombres de tipos y sin especificar explícitamente la propiedad de navegación. Esto no es habitual. El
comportamiento anterior se puede obtener al pasar de manera explícita null para el nombre de la propiedad de
navegación. Por ejemplo:
modelBuilder.Entity<Samurai>().HasOne("Some.Entity.Type.Name", null).WithOne();
El tipo de valor devuelto para varios métodos asincrónicos se ha cambiado de Task a ValueTask
Antes, los siguientes métodos asincrónicos devolvían Task<T> :
DbContext.FindAsync()
DbSet.FindAsync()
DbContext.AddAsync()
DbSet.AddAsync()
ValueGenerator.NextValueAsync() (y las clases derivadas)
Dichos métodos ahora devuelven ValueTask<T> durante el mismo T que antes.
Por qué
Este cambio reduce el número de asignaciones de montones que se producen al invocar estos métodos, lo que
mejora el rendimiento general.
Mitigaciones
Las aplicaciones que simplemente esperen las API anteriores solo necesitan recompilarse, sin que sea necesario
realizar cambios en el código fuente. Un uso más complejo (p. ej., pasar el valor Task devuelto a Task.WhenAny() )
normalmente requiere que el valor ValueTask<T> devuelto se convierta en Task<T> mediante una llamada a
AsTask() en él. Tenga en cuenta que esto niega la reducción de asignación que implica este cambio.
La anotación Relational:TypeMapping ahora es simplemente TypeMapping

El nombre de anotación para las anotaciones de asignación de tipos era "Relational:TypeMapping".
Ahora, el nombre de anotación para las anotaciones de asignación de tipos es "TypeMapping".
Por qué
Ahora, las asignaciones de tipos se usan para algo más que solo para proveedores de bases de datos relacionales.
Mitigaciones
Esto solo interrumpirá a las aplicaciones que acceden directamente a la asignación de tipos como una anotación,
lo que no es habitual. La acción más apropiada para corregir es usar la superficie de API para acceder a las
asignaciones de tipos en lugar de usar directamente la anotación.
ToTable en un tipo derivado inicia una excepción
Antes de EF Core 3.0, la llamada a ToTable() en un tipo derivado se omitía, ya que la única estrategia asignación
de herencia era TPH, lo que no es válido.
A partir de EF Core 3.0, y en preparación para agregar compatibilidad con TPT y TPC en una versión posterior,
ahora la llamada a ToTable() en un tipo derivado iniciará una excepción para evitar un cambio de asignación
inesperado en el futuro.
Por qué
En la actualidad no se considera válido asignar un tipo derivado a otra tabla. Este cambio evita interrupciones en
el futuro, cuando se convierta en una operación válida.
Mitigaciones
Quite todos los intentos de asignar tipos derivados a otras tablas.
ForSqlServerHasIndex se ha reemplazado por HasIndex
Antes de EF Core 3.0, ForSqlServerHasIndex().ForSqlServerInclude() proporcionaba una manera de configurar las
columnas que se usaban con INCLUDE .
A partir de EF Core 3.0, ya se admite el uso de Include en un índice en el nivel relacional. Mediante
HasIndex().ForSqlServerInclude() .
Por qué
Este cambio se ha realizado para consolidar la API para índices con Include en un mismo lugar para todos los
proveedores de base de datos.
Mitigaciones
Use la API nueva, como se ha mostrado anteriormente.
Cambios en la API de metadatos
Las siguientes propiedades se han convertido en métodos de extensión:
IEntityType.QueryFilter -> GetQueryFilter()
IEntityType.DefiningQuery -> GetDefiningQuery()
IProperty.IsShadowProperty -> IsShadowProperty()
IProperty.BeforeSaveBehavior -> GetBeforeSaveBehavior()
IProperty.AfterSaveBehavior -> GetAfterSaveBehavior()
Por qué
Este cambio simplifica la implementación de las interfaces mencionadas anteriormente.
Mitigaciones
Use los nuevos métodos de extensión.
Cambios en la API de metadatos específicos del proveedor
Los métodos de extensión específicos del proveedor se simplificarán:
IProperty.Relational().ColumnName -> IProperty.GetColumnName()
IEntityType.SqlServer().IsMemoryOptimized -> IEntityType.IsMemoryOptimized()
PropertyBuilder.UseSqlServerIdentityColumn() -> PropertyBuilder.UseIdentityColumn()
Por qué
Este cambio simplifica la implementación de los métodos de extensión mencionados anteriormente.
Mitigaciones
Use los nuevos métodos de extensión.
EF Core ya no envía pragma para el cumplimiento de SQLite FK
Antes de EF Core 3.0, EF Core enviaba PRAGMA foreign_keys = 1 cuando se abría una conexión con SQLite.
A partir de EF Core 3.0, EF Core ya no envía PRAGMA foreign_keys = 1 cuando se abre una conexión con SQLite.
Por qué
Este cambio se ha realizado porque en EF Core se usa SQLitePCLRaw.bundle_e_sqlite3 de forma predeterminada,
lo que a su vez significa que el cumplimiento de CD está activado de forma predeterminada y no es necesario
habilitarlo explícitamente cada vez que se abra una conexión.
Mitigaciones
Las claves externas se habilitan de forma predeterminada en SQLitePCLRaw.bundle_e_sqlite3, que en EF Core se
usa de forma predeterminada. Para otros casos, las claves externas se pueden habilitar mediante la especificación
de Foreign Keys=True en la cadena de conexión.
Microsoft.EntityFrameworkCore.Sqlite ahora depende de SQLitePCLRaw.bundle_e_sqlite3
Antes de EF Core 3.0, en EF Core se usaba SQLitePCLRaw.bundle_green .
A partir de EF Core 3.0, en EF Core se usa SQLitePCLRaw.bundle_e_sqlite3 .
Por qué
Este cambio se ha realizado para que la versión de SQLite que se usa en iOS sea coherente con otras plataformas.
Mitigaciones
Para usar la versión nativa de SQLite en iOS, configure Microsoft.Data.Sqlite para usar otra agrupación
SQLitePCLRaw .
Almacenamiento de valores GUID como TEXT en SQLite

Antes, los valores GUID se almacenaban como valores BLOB en SQLite.
Ahora, los valores GUID se almacenan como TEXT.
Por qué
El formato binario de los GUID no está normalizado. El almacenamiento de los valores como TEXT mejora la
compatibilidad de la base de datos con otras tecnologías.
Mitigaciones
Puede migrar las bases de datos existentes al nuevo formato ejecutando SQL de la siguiente forma.
UPDATE MyTable
SET GuidColumn = hex(substr(GuidColumn, 4, 1)) ||
hex(substr(GuidColumn, 3, 1)) ||
hex(substr(GuidColumn, 1, 1)) || '-' ||
hex(substr(GuidColumn, 11, 6))
WHERE typeof(GuidColumn) == 'blob';
En EF Core, también puede seguir usando el comportamiento anterior configurando un convertidor de valores en
estas propiedades.
modelBuilder
.Entity<MyEntity>()
.Property(e => e.GuidProperty)
.HasConversion(
g => g.ToByteArray(),
b => new Guid(b));
Microsoft.Data.Sqlite sigue siendo capaz de leer valores GUID de ambas columnas BLOB y TEXT. Sin embargo,
dado que el formato predeterminado de los parámetros y las constantes ha cambiado, seguramente deberá
realizar alguna acción en la mayoría de casos que impliquen el uso de valores GUID.
Ahora los valores char se almacenan como TEXT en SQLite
Anteriormente los valores char se almacenaban como valores INTEGER en SQLite. Por ejemplo, un valor char de A
se almacenaba como el valor entero 65.
Ahora, los valores char se almacenan como TEXT.
Por qué
El almacenamiento de valores como TEXT es más natural y mejora la compatibilidad de la base de datos con otras
tecnologías.
Mitigaciones
Puede migrar las bases de datos existentes al nuevo formato ejecutando SQL de la siguiente forma.
UPDATE MyTable
SET CharColumn = char(CharColumn)
WHERE typeof(CharColumn) = 'integer';
En EF Core, también puede seguir usando el comportamiento anterior configurando un convertidor de valores en
estas propiedades.
modelBuilder
.Entity<MyEntity>()
.Property(e => e.CharProperty)
.HasConversion(
c => (long)c,
i => (char)i);
Microsoft.Data.Sqlite también puede leer valores de caracteres tanto de columnas INTEGER como de columnas
TEXT, por lo que es posible que no deba hacer nada dependiendo de su caso.
Ahora los id. de migración se generan usando el calendario de la referencia cultural invariable
Los identificadores de migración se generaban de forma involuntaria con el calendario de la referencia cultural
actual.
Ahora los id. de migración siempre se generan usando el calendario de la referencia cultural invariable
(gregoriano).
Por qué
El orden de las migraciones es importante al actualizar la base de datos o al solucionar conflictos de combinación.
Al usar el calendario invariable, se evitan problemas de ordenación que pueden producirse si los miembros del
equipo tienen distintos calendarios del sistema.
Mitigaciones
Esta cambio afecta a todas las personas que usan un calendario no gregoriano en el que el año sea superior al del
calendario gregoriano (como el calendario budista tailandés). Los id. de migración existentes deberán actualizarse
para que las migraciones nuevas se ordenen después de las existentes.
Puede ver el id. de migración en el atributo Migration de los archivos de diseñador de la migración.
[DbContext(typeof(MyDbContext))]
-[Migration("25620318122820_MyMigration")]
+[Migration("20190318122820_MyMigration")]
partial class MyMigration
{
También debe actualizarse la tabla de historial de migraciones.
UPDATE __EFMigrationsHistory
SET MigrationId = CONCAT(LEFT(MigrationId, 4) - 543, SUBSTRING(MigrationId, 4, 150))
Se ha quitado el elemento UseRowNumberForPaging

Antes de EF Core 3.0, UseRowNumberForPaging se podía usar para generar SQL para la paginación de forma que
fuera compatible con SQL Server 2008.
A partir de EF Core 3.0, EF solo genera SQL para la paginación que únicamente es compatible con las versiones
posteriores de SQL Server.
Por qué
El motivo de este cambio es que SQL Server 2008 ya no se admite. Además, la actualización de esta característica
para que funcionase con los cambios en las consultas implementados en EF Core 3.0 llevaría mucho trabajo.
Mitigaciones
Se recomienda actualizar a una versión más reciente de SQL Server, o bien utilizar un nivel de compatibilidad
superior, de modo que el SQL que se genere se admita. Dicho esto, si no puede hacerlo, escriba un comentario en
el problema de seguimiento con los detalles al respecto. En función de los comentarios, es posible que volvamos a
valorar esta decisión.
La información o metadatos de la extensión se han quitado de IDbContextOptionsExtension
IDbContextOptionsExtension incluía métodos para proporcionar metadatos sobre la extensión.
Estos métodos se han movido a una nueva clase base abstracta DbContextOptionsExtensionInfo , que se devuelve
desde una nueva propiedad IDbContextOptionsExtension.Info .
Por qué
Al lanzarse las versiones 2.0 y 3.0, tuvimos que agregar o cambiar estos métodos varias veces. Su división en una
nueva clase base abstracta facilitará la realización de este tipo de cambios sin interrumpir las extensiones
existentes.
Mitigaciones
Actualice las extensiones para seguir el nuevo patrón. Encontrará ejemplos en las muchas implementaciones de
IDbContextOptionsExtension para los diferentes tipos de extensiones en el código fuente de EF Core.
Cambio de nombre de LogQueryPossibleExceptionWithAggregateOperator

Cambio
Se ha cambiado el nombre de RelationalEventId.LogQueryPossibleExceptionWithAggregateOperator a
RelationalEventId.LogQueryPossibleExceptionWithAggregateOperatorWarning .
Por qué
Conviene alinear el nombre de este evento de advertencia con el del resto de eventos de advertencia.
Mitigaciones
Use el nuevo nombre. (Tenga en cuenta que el número de id. evento sigue siendo el mismo).
Clarificación de la API para nombres de restricciones de claves externas
Antes de EF Core 3.0, se utilizaba simplemente el término "nombre" para hacer referencia a los nombres de las
restricciones de claves externas. Por ejemplo:
var constraintName = myForeignKey.Name;

A partir de EF Core 3.0, el término con el que se hace referencia a los nombres de las restricciones de claves
externas es "nombre de la restricción". Por ejemplo:
var constraintName = myForeignKey.ConstraintName;
Por qué
Este cambio permite mejorar la coherencia relativa a la nomenclatura en este aspecto y aclarar que se trata del
nombre de una restricción de clave externa, y no del de la columna o propiedad en la que está definida la clave
externa.
Mitigaciones
Use el nuevo nombre.
IRelationalDatabaseCreator.HasTables/HasTablesAsync se han hecho públicos
Antes de EF Core 3.0, estos métodos estaban protegidos.
Desde EF Core 3.0, estos métodos son públicos.
Por qué
EF usa estos métodos para determinar si se ha creado una base de datos, pero está vacía. Esto también puede
resultar útil fuera de EF al determinar si se deben aplicar migraciones o no.
Mitigaciones
Cambie la accesibilidad de cualquier invalidación.
Microsoft.EntityFrameworkCore.Design es ahora un paquete DevelopmentDependency
Antes de EF Core 3.0, Microsoft.EntityFrameworkCore.Design era un paquete NuGet regular con un ensamblado al
que podían hacer referencia los proyectos que dependían de él.
Desde EF Core 3.0, es un paquete DevelopmentDependency. Esto significa que la dependencia no fluirá de manera
transitiva en otros proyectos y que ya no puede, de forma predeterminada, hacer referencia a su ensamblado.
Por qué
Este paquete solo está destinado a usarse en tiempo de diseño. Las aplicaciones implementadas no deben hacer
referencia al mismo. Hacer que el paquete sea DevelopmentDependency refuerza esta recomendación.
Mitigaciones
Si tiene que hacer referencia a este paquete para invalidar el comportamiento en tiempo de diseño de EF Core,
puede actualizar los metadatos de elementos PackageReference del proyecto.
<PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="3.0.0">

<PrivateAssets>all</PrivateAssets>


</PackageReference>
Si se hace referencia al paquete de manera transitiva a través de Microsoft.EntityFrameworkCore.Tools, tendrá que

agregar una PackageReference explícita al paquete para cambiar sus metadatos. Este tipo de referencia explícita
debe agregarse a cualquier proyecto que requiera los tipos de paquete.
SQLitePCL.raw se ha actualizado a la versión 2.0.0
Microsoft.EntityFrameworkCore.Sqlite dependía anteriormente de la versión 1.1.12 de SQLitePCL.raw.
Hemos actualizado nuestro paquete para depender de la versión 2.0.0.
Por qué
La versión 2.0.0 de SQLitePCL.raw selecciona .NET Standard 2.0 como destino. Anteriormente seleccionaba .NET
Standard 1.1 como destino, que requería el cierre a gran escala de paquetes transitivos para su funcionamiento.
Mitigaciones
En la versión 2.0.0 de SQLitePCL.raw se incluyen algunos cambios importantes. Consulte las notas de la versión
para obtener detalles.
NetTopologySuite se actualizó a la versión 2.0.0
Los paquetes espaciales anteriormente dependían de la versión 1.15.1 de NetTopologySuite.
Hemos actualizado nuestro paquete para depender de la versión 2.0.0.
Por qué
La versión 2.0.0 de NetTopologySuite pretende resolver varios problemas de usabilidad que encontraron los
usuarios de EF Core.
Mitigaciones
En la versión 2.0.0 de NetTopologySuite se incluyen algunos cambios importantes. Consulte las notas de la
versión para obtener detalles.
Se usa Microsoft.Data.SqlClient en lugar de System.Data.SqlClient
Microsoft.EntityFrameworkCore.SqlServer dependía anteriormente de la versión System.Data.SqlClient.
Hemos actualizado nuestro paquete para que dependa de Microsoft.Data.SqlClient.
Por qué
A partir de ahora, Microsoft.Data.SqlClient es el controlador de acceso a datos insignia para SQL Server y
System.Data.SqlClient ya no es el centro de desarrollo. Algunas características importantes, como Always
Encrypted, solo están disponibles en Microsoft.Data.SqlClient.
Mitigaciones
Si el código toma una dependencia directa en System.Data.SqlClient, debe cambiarla para que haga referencia a
Microsoft.Data.SqlClient en su lugar. Dado que los dos paquetes mantienen un grado muy alto de compatibilidad
con la API, solo debería ser un paquete simple y un cambio de espacio de nombres.
Se deben configurar varias relaciones de referencia automática ambiguas
Un tipo de entidad con varias propiedades de navegación unidireccional de referencia automática y claves
externas coincidentes se configuró incorrectamente como una única relación. Por ejemplo:
public class User

{
public Guid Id { get; set; }
public User CreatedBy { get; set; }
public User UpdatedBy { get; set; }
public Guid CreatedById { get; set; }
public Guid? UpdatedById { get; set; }
}

Este escenario se detecta ahora en la generación del modelo y se produce una excepción que indica que el modelo
es ambiguo.
Por qué
El modelo resultante era ambiguo, y lo más probable es que sea incorrecto en este caso.
Mitigaciones
Utilice la configuración completa de la relación. Por ejemplo:
modelBuilder
.Entity<User>()
.HasOne(e => e.CreatedBy)
.WithMany();
modelBuilder
.Entity<User>()
.HasOne(e => e.UpdatedBy)
.WithMany();
DbFunction.Schema es NULL o la cadena vacía lo configura para estar en el esquema predeterminado del
modelo
Una función DbFunction configurada con el esquema como una cadena vacía se trataba como una función
integrada sin un esquema. Por ejemplo, el código siguiente asignará la función CLR DatePart a la función
integrada DATEPART en SqlServer.
[DbFunction("DATEPART", Schema = "")]

public static int? DatePart(string datePartArg, DateTime? date) => throw new Exception();

Todas las asignaciones de DbFunction se consideran asignadas a funciones definidas por el usuario. Por lo tanto, el
valor de cadena vacía colocaría la función dentro del esquema predeterminado del modelo, que podría ser el
esquema configurado de forma explícita mediante modelBuilder.HasDefaultSchema() de la API fluida o dbo en
caso contrario.
Por qué
Anteriormente, el esquema vacío era una manera de indicar que la función estaba integrada, pero esa lógica solo
es aplicable a SqlServer, donde las funciones integradas no pertenecen a ningún esquema.
Mitigaciones
Configure la traslación de DbFunction manualmente para asignarla a una función integrada.
modelBuilder
.HasDbFunction(typeof(MyContext).GetMethod(nameof(MyContext.DatePart)))
.HasTranslation(args => SqlFunctionExpression.Create("DatePart", args, typeof(int?), null));
Novedades de EF Core 2.2
Compatibilidad con datos espaciales

Los datos espaciales pueden usarse para representar la ubicación física y la forma de los objetos. Muchas bases de
datos pueden almacenar, indexar y consultar datos espaciales de forma nativa. Entre los escenarios habituales se
incluye la consulta de objetos dentro de una distancia determinada y la prueba de si un polígono contiene una
ubicación determinada. EF Core 2.2 ahora admite trabajar con datos espaciales de varias bases de datos utilizando
tipos de la biblioteca NetTopologySuite (NTS).
La compatibilidad con datos espaciales se implementa como una serie de paquetes de extensión específicos del
proveedor. Cada uno de estos paquetes contribuye a las asignaciones de tipos y métodos de NTS y los
correspondientes tipos espaciales y funciones en la base de datos. Estas extensiones de proveedor ahora están
disponibles para SQL Server, SQLite y PostgreSQL (del proyecto Npgsql). Los tipos espaciales pueden usarse
directamente con el proveedor en memoria de EF Core sin extensiones adicionales.
Una vez que se instala la extensión del proveedor, puede agregar propiedades de los tipos admitidos a las
entidades. Por ejemplo:
using NetTopologySuite.Geometries;
namespace MyApp
{
public class Friend
{
[Key]
[Required]
public Point Location { get; set; }
}
}
Luego puede guardar entidades con datos espaciales:
using (var context = new MyDbContext())

{
context.Add(
new Friend
{
Name = "Bill",
Location = new Point(-122.34877, 47.6233355) {SRID = 4326 }
});
}
Y puede ejecutar consultas de base de datos basadas en datos y operaciones espaciales:
var nearestFriends =
(from f in context.Friends
orderby f.Location.Distance(myLocation) descending
select f).Take(5).ToList();
Para obtener más información sobre esta característica, consulte la documentación sobre tipos espaciales.
Colecciones de entidades en propiedad

EF Core 2.0 agregó la capacidad de modelar la propiedad en asociaciones de uno a uno. EF Core 2.2 extiende la
capacidad de expresar la propiedad a asociaciones de uno a varios. La propiedad ayuda a restringir el modo en que
se usan las entidades.
Por ejemplo, las entidades en propiedad:
Solo pueden aparecer en las propiedades de navegación de otros tipos de entidad.
Se cargan automáticamente, y solo se puede hacer su seguimiento por un DbContext junto con su propietario.
En bases de datos relacionales, las colecciones en propiedad se asignan a tablas independientes del propietario, al
igual que las asociaciones regulares de uno a varios. Pero en las bases de datos orientadas a documentos, tenemos
previsto anidar entidades en propiedad (en colecciones o referencias en propiedad) dentro del mismo documento
que el propietario.
Puede usar la característica mediante una llamada a la nueva API OwnsMany():
modelBuilder.Entity<Customer>().OwnsMany(c => c.Addresses);
Para obtener más información, consulte la documentación actualizada de entidades en propiedad.
Esta característica simplifica la correlación de las consultas LINQ en el código con las consultas SQL generadas
capturadas en los registros.
Para aprovechar las ventajas de las etiquetas de consulta, anote una consulta LINQ mediante el nuevo método
TagWith(). Uso de la consulta espacial de un ejemplo anterior:
(from f in context.Friends.TagWith(@"This is my spatial query!")
Esta consulta LINQ producirá la siguiente salida SQL:
-- This is my spatial query!
SELECT TOP(@__p_1) [f].[Name], [f].[Location]

FROM [Friends] AS [f]
ORDER BY [f].[Location].STDistance(@__myLocation_0) DESC
Para obtener más información, vea la documentación de etiquetas de consulta.

Novedades de EF Core 2.1
Además de numerosas correcciones de errores y pequeñas mejoras funcionales y de rendimiento, EF Core 2.1
incluye algunas características nuevas muy atractivas:
Carga diferida
EF Core contiene ahora los bloques de creación necesarios para quienes quieran crear clases de entidad que
puedan cargar las propiedades de navegación a petición. También hemos creado otro paquete,
Microsoft.EntityFrameworkCore.Proxies, que aprovecha los bloques de creación para generar clases proxy de carga
diferida basadas en clases de entidad apenas modificadas (por ejemplo, clases con propiedades de navegación
virtual).
Consulte la sección sobre cargas diferidas para obtener más información sobre el tema.
Parámetros en constructores de entidad

Como uno de los bloques de creación necesarios para la carga diferida, se habilita la creación de entidades que
aceptan parámetros en sus constructores. Puede usar parámetros para insertar valores de propiedad, delegados de
carga diferida y servicios.
Consulte la sección sobre constructores de entidad con parámetros para obtener más información sobre el tema.
Hasta ahora, EF Core solo podía asignar propiedades de tipos admitidas de forma nativa por el proveedor de bases
de datos subyacente. Los valores se copiaban de un lado a otro entre las columnas y las propiedades sin ninguna
transformación. A partir de EF Core 2.1, pueden aplicarse conversiones de valores para transformar los valores
obtenidos en las columnas antes de que se apliquen a las propiedades, y viceversa. Tenemos varias conversiones
que pueden aplicarse por convención según sea necesario, así como una API de configuración explícita que permite
registrar conversiones personalizadas entre columnas y propiedades. Algunas de las aplicaciones de esta
característica son:
Almacenamiento de enumeraciones como cadenas
Asignación de enteros sin signo con SQL Server
Cifrado y descifrado automáticos de valores de propiedad
Consulte la sección sobre conversiones de valores para obtener más información sobre el tema.
Traslación de GroupBy de LINQ

Antes de la versión 2.1, el operador GroupBy de LINQ en EF Core siempre se evaluaba en la memoria. Ahora se
admite su traslación a la cláusula GROUP BY de SQL en los casos más comunes.
En este ejemplo se muestra una consulta con GroupBy utilizada para calcular diversas funciones de agregado:
var query = context.Orders
.GroupBy(o => new { o.CustomerId, o.EmployeeId })
.Select(g => new
{
g.Key.CustomerId,
g.Key.EmployeeId,
Sum = g.Sum(o => o.Amount),
Min = g.Min(o => o.Amount),
Max = g.Max(o => o.Amount),
Avg = g.Average(o => o.Amount)
});
La traslación correspondiente a SQL tiene este aspecto:
SELECT [o].[CustomerId], [o].[EmployeeId],

SUM([o].[Amount]), MIN([o].[Amount]), MAX([o].[Amount]), AVG([o].[Amount])
FROM [Orders] AS [o]
GROUP BY [o].[CustomerId], [o].[EmployeeId];
Con la nueva versión, será posible proporcionar datos iniciales para rellenar una base de datos. A diferencia de en
EF6, la propagación de datos está asociada a un tipo de entidad como parte de la configuración del modelo. Las
migraciones de EF Core pueden luego calcular automáticamente las operaciones de inserción, actualización y
eliminación que hay que aplicar al actualizar la base de datos a una nueva versión del modelo.
Por ejemplo, esto se puede usar para configurar los datos de inicialización de un método POST en OnModelCreating :
modelBuilder.Entity<Post>().HasData(new Post{ Id = 1, Text = "Hello World!" });
Consulte la sección sobre propagación de datos para obtener más información sobre el tema.
Tipos de consulta
Un modelo de EF Core ahora puede incluir tipos de consulta. A diferencia de los tipos de entidad, los tipos de
consulta no tienen claves definidas en ellos y no se pueden insertar, eliminar ni actualizar (es decir, son de solo
lectura), pero se pueden devolver directamente en las consultas. Algunos de los escenarios de uso para los tipos de
consulta son:
Asignar a vistas sin claves principales
Asignar a tablas sin claves principales
Asignar a consultas definidas en el modelo
Actuar como tipo de valor devuelto en consultas FromSql()
Consulte la sección sobre tipos de consulta para obtener más información sobre el tema.
Include en tipos derivados

Ahora será posible especificar propiedades de navegación definidas solo en tipos derivados al escribir expresiones
para el método Include . Para la versión fuertemente tipada de Include , se admite el uso de una conversión
explícita o el operador as . Ahora también se admite hacer referencia a los nombres de propiedad de navegación
definidos en tipos derivados en la versión de cadena de Include :
var option1 = context.People.Include(p => ((Student)p).School);
var option2 = context.People.Include(p => (p as Student).School);
var option3 = context.People.Include("School");
Consulte la sección sobre Include con tipos derivados para obtener más información sobre el tema.
System.Transactions
Se ha agregado la posibilidad de trabajar con características de System.Transactions tales como TransactionScope.
Esto funcionará en .NET Framework y en .NET Core cuando se usen proveedores de bases de datos que lo admitan.
Consulte la sección sobre System.Transactions para obtener más información sobre el tema.
Mejor ordenación de columnas en la migración inicial

En función de los comentarios de clientes, hemos actualizado las migraciones para que las columnas de tablas se
generen inicialmente en el mismo orden en que se declaran las propiedades en clases. Tenga en cuenta que EF Core
no puede cambiar el orden cuando se agregan nuevos miembros después de la creación de la tabla inicial.
Optimización de subconsultas correlacionadas

Se ha mejorado la traslación de consultas para evitar la ejecución de "N + 1" consultas SQL en muchos escenarios
comunes en los que el uso de una propiedad de navegación en la proyección conduce a unir los datos de la
consulta raíz con los datos de una subconsulta correlacionada. La optimización requiere el almacenamiento en
búfer de los resultados de la subconsulta, y hay que modificar la consulta para que participe en el nuevo
comportamiento.
Por ejemplo, la siguiente consulta normalmente se traslada a una consulta para clientes, más N consultas separadas
para pedidos (donde "N" corresponde al número de clientes devueltos):
var query = context.Customers.Select(

c => c.Orders.Where(o => o.Amount > 100).Select(o => o.Amount));
Al incluir ToList() en el lugar correcto, se indica que el almacenamiento en búfer es adecuado para los pedidos, lo
que permite la optimización:
var query = context.Customers.Select(

c => c.Orders.Where(o => o.Amount > 100).Select(o => o.Amount).ToList());
Tenga en cuenta que esta consulta solo se trasladará a dos consultas SQL: una para clientes y la siguiente para
pedidos.
Atributo [Owned]
Ahora es posible configurar tipos de entidad en propiedad anotando simplemente el tipo con [Owned] y
asegurándose luego de que la entidad de propietario se agrega al modelo:
[Owned]
public class StreetAddress
{
}
public class Order

{
public StreetAddress ShippingAddress { get; set; }
}
Herramienta de línea de comandos dotnet-ef incluida en el SDK de .NET

Core
Los comandos de dotnet-ef ahora forman parte del SDK de .NET Core, así que ya no es necesario usar
DotNetCliToolReference en el proyecto para poder usar migraciones o para aplicar la técnica scaffolding a
DbContext desde una base de datos existente.
Vea la sección sobre cómo instalar las herramientas para obtener más información sobre cómo habilitar
herramientas de línea de comandos para diferentes versiones del SDK de .NET Core y EF Core.
Paquete Microsoft.EntityFrameworkCore.Abstractions
El nuevo paquete contiene atributos e interfaces que puede usar en los proyectos para activar características de EF
Core sin depender de EF Core como un todo. Por ejemplo, el atributo [Owned] y la interfaz de ILazyLoader se
encuentran aquí.
Eventos de cambio de estado

Los nuevos eventos Tracked y StateChanged de ChangeTracker se pueden usar para escribir lógica que reaccione a
las entidades que entran en DbContext o que cambian su estado.
Analizador de parámetros de SQL sin formato

Un nuevo analizador de código se incluye en EF Core que detecta los usos potencialmente poco seguros de
nuestras API de SQL sin formato, como FromSql o ExecuteSqlCommand . Por ejemplo, para la consulta siguiente, verá
una advertencia porque minAge no tiene parámetros:
var sql = $"SELECT * FROM People WHERE Age > {minAge}";

var query = context.People.FromSql(sql);
Compatibilidad del proveedor de bases de datos

Se recomienda usar EF Core 2.1 con proveedores que se hayan actualizado o que al menos se haya comprobado
que funcionan con EF Core 2.1.
TIP
Si encuentra alguna incompatibilidad inesperada o algún problema en las nuevas características o si tiene comentarios sobre
ellas, notifíquelos mediante nuestro rastreador de problemas.
Nuevas características de EF Core 2.0
.NET Standard 2.0

EF Core tiene ahora como destino .NET Standard 2.0, lo que significa que puede trabajar con .NET Core 2.0, .NET
Framework 4.6.1 y otras bibliotecas que implementan .NET Standard 2.0. Vea Implementaciones de .NET
compatibles para obtener más detalles sobre lo que se admite.
Modelado
División de tablas
Ahora es posible asignar dos o más tipos de entidad a la misma tabla en la que se van a compartir las columnas de
clave principal y cada fila va a corresponder a dos o más entidades.
Para usar la división de tabla, debe configurarse una relación de identificación (donde las propiedades de clave
externa forman la clave principal) entre todos los tipos de entidad que comparten la tabla:
modelBuilder.Entity<Product>()
.HasOne(e => e.Details).WithOne(e => e.Product)
.HasForeignKey<ProductDetails>(e => e.Id);
modelBuilder.Entity<Product>().ToTable("Products");
modelBuilder.Entity<ProductDetails>().ToTable("Products");
Consulte la sección sobre la división de las tablas para obtener más información sobre esta característica.
Tipos de propiedad
Un tipo de entidad en propiedad puede compartir el mismo tipo .NET con otro tipo de entidad en propiedad, pero,
dado que no se puede identificar simplemente por el tipo .NET, debe haber una navegación a él desde otro tipo de
entidad. La entidad que contiene la navegación definitoria es el propietario. Al consultar al propietario, los tipos de
propiedad se incluyen de forma predeterminada.
Por convención, se crea una clave principal paralela para el tipo de propiedad y se asigna a la misma tabla que el
propietario mediante la división de tabla. Esto permite usar tipos de propiedad de forma similar al modo en que se
usan los tipos complejos en EF6:
modelBuilder.Entity<Order>().OwnsOne(p => p.OrderDetails, cb =>
{
cb.OwnsOne(c => c.BillingAddress);
cb.OwnsOne(c => c.ShippingAddress);
});
public class Order

{
public OrderDetails OrderDetails { get; set; }
}

{
public StreetAddress BillingAddress { get; set; }
}

{
}
Consulte la sección sobre tipos de entidad en propiedad para obtener más información sobre esta característica.
Filtros de consulta de nivel de modelo
EF Core 2.0 incluye una nueva característica que se denomina filtros de consulta de nivel de modelo. Esta
característica permite que los predicados de consulta LINQ (una expresión booleana que normalmente se pasa al
operador de consulta Where de LINQ) se definan directamente en tipos de entidad del modelo de metadatos
(normalmente en OnModelCreating). Estos filtros se aplican automáticamente a las consultas LINQ que implican a
esos tipos de entidad, incluidos aquellos a los que se hace referencia de forma indirecta, por ejemplo mediante el
uso de Include o de referencias de propiedad de navegación directas. Algunas aplicaciones comunes de esta
característica son:
Eliminación temporal: un tipo de entidad define una propiedad IsDeleted.
Servicios multiinquilino: un tipo de entidad define una propiedad TenantId.
Este es un ejemplo sencillo que muestra la característica para los dos escenarios mencionados arriba:

{
public int TenantId { get; set; }

{
modelBuilder.Entity<Post>().HasQueryFilter(
p => !p.IsDeleted
&& p.TenantId == this.TenantId);
}
}
Se define un filtro de nivel de modelo que implementa los servicios multiinquilino y la eliminación temporal para
instancias del tipo de entidad Post . Observe el uso de una propiedad de nivel de instancia DbContext : TenantId .
Los filtros de nivel de modelo usan el valor de la instancia de contexto correcta (es decir, la instancia de contexto
que está ejecutando la consulta).
Los filtros se pueden deshabilitar para consultas LINQ individuales mediante el operador IgnoreQueryFilters().
Limitaciones
No se permiten las referencias de navegación. Esta característica se puede agregar en función de los
comentarios.
Solo se pueden definir filtros en el tipo de entidad raíz de una jerarquía.
Asignación de función escalar de base de datos
EF Core 2.0 incluye una importante contribución de Paul Middleton que permite la asignación de funciones
escalares de base de datos a stubs de método para que puedan usarse en consultas LINQ y trasladarse a SQL.
Esta es una breve descripción de cómo se puede usar la característica:
Declare un método estático en DbContext y anótelo con DbFunctionAttribute :

{
[DbFunction]
public static int PostReadCount(int blogId)
{
throw new NotImplementedException();
}
}
Los métodos como este se registran automáticamente. Una vez registrados, las llamadas al método de una consulta
LINQ pueden trasladarse a llamadas a funciones de SQL:
var query =
from p in context.Posts
where BloggingContext.PostReadCount(p.Id) > 5
select p;
Puntos a tener en cuenta:

Por convención, el nombre del método se usa como nombre de una función (en este caso una función definida
por el usuario) al generar el código SQL, pero puede invalidar el nombre y el esquema durante el registro del
método.
Actualmente solo se admiten las funciones escalares.
Debe crear la función asignada en la base de datos. La migraciones de EF Core no se encargarán de crearla.
Configuración de tipo independiente para Code First
En EF6 era posible encapsular la configuración de Code First de un tipo de entidad concreto al derivarlo de
EntityTypeConfiguration. En EF Core 2.0 se vuelve a incluir este patrón:
class CustomerConfiguration : IEntityTypeConfiguration<Customer>

{
public void Configure(EntityTypeBuilder<Customer> builder)
{
builder.HasKey(c => c.AlternateKey);
builder.Property(c => c.Name).HasMaxLength(200);
}
}
...
// OnModelCreating
builder.ApplyConfiguration(new CustomerConfiguration());
Alto rendimiento
Agrupación de DbContext
El patrón básico para usar EF Core en una aplicación de ASP.NET Core normalmente implica el registro de un tipo
de DbContext personalizado en el sistema de inserción de dependencias y la posterior obtención de instancias de
ese tipo a través de los parámetros del constructor de los controladores. Esto significa que se crea una nueva
instancia de DbContext para cada solicitud.
En la versión 2.0 se incorpora una nueva manera de registrar tipos de DbContext personalizados en la inserción de
dependencias que presenta un grupo de instancias de DbContext reutilizables de forma transparente. Para usar la
agrupación de DbContext, use AddDbContextPool en lugar de AddDbContext durante el registro del servicio:
services.AddDbContextPool<BloggingContext>(
options => options.UseSqlServer(connectionString));
Si se usa este método, en el momento en que un controlador solicita una instancia de DbContext, primero se
comprueba si hay una disponible en el grupo. Una vez que termina el procesamiento de la solicitud, se restablece
cualquier estado en la instancia y la propia instancia se devuelve al grupo.
Esto es conceptualmente similar a la forma en que funciona la agrupación de conexiones en los proveedores de
ADO.NET y tiene la ventaja de ahorrar algunos de los costos de inicialización de la instancia de DbContext.
Limitaciones
El nuevo método presenta algunas limitaciones con respecto a lo que se puede hacer en el método
OnConfiguring() de DbContext.
WARNING
Evite el uso de la agrupación de DbContext si mantiene su propio estado (por ejemplo, campos privados) en la clase derivada
DbContext que no debe compartirse con otras solicitudes. EF Core solo restablece el estado del que es consciente antes de
agregar una instancia de DbContext al grupo.
Consultas compiladas de manera explícita

Esta es la segunda característica de rendimiento opcional diseñada para ofrecer ventajas en escenarios de gran
escala.
Las API de consulta compiladas de forma manual o explícita han estado disponibles en versiones anteriores de EF y
también en LINQ to SQL para permitir que las aplicaciones almacenen en caché la traducción de consultas de modo
que se puedan calcular una sola vez y ejecutarse muchas veces.
Aunque en general EF Core puede compilar y almacenar en caché automáticamente las consultas en función de una
representación con hash de las expresiones de consulta, este mecanismo puede usarse para obtener una pequeña
mejora de rendimiento al omitir el cálculo del hash y la búsqueda en caché, lo que permite que la aplicación use
una consulta ya compilada mediante la invocación de un delegado.
// Create an explicitly compiled query
private static Func<CustomerContext, int, Customer> _customerById =
EF.CompileQuery((CustomerContext db, int id) =>
db.Customers
.Include(c => c.Address)
.Single(c => c.Id == id));
// Use the compiled query by invoking it

using (var db = new CustomerContext())
{
var customer = _customerById(db, 147);
}
Seguimiento de cambios
La asociación permite realizar un seguimiento de un gráfico de entidades nuevas y existentes.
EF Core admite la generación automática de valores de clave a través de una serie de mecanismos. Al usar esta
característica, se genera un valor si la propiedad de clave es el valor predeterminado de CLR, normalmente cero o
null. Esto significa que se puede pasar un gráfico de entidades a DbContext.Attach o DbSet.Attach y que EF Core
marca aquellas entidades que tienen una clave ya establecida como Unchanged , mientras que las que no tienen
establecida una clave se marcan como Added . Esto facilita la tarea de asociar un gráfico de entidades mixtas nuevas
y existentes al usar claves generadas. DbContext.Update y DbSet.Update funcionan de la misma manera, salvo que
las entidades con una clave establecida se marcan como Modified en lugar de Unchanged .
Consultar
Traducción de LINQ mejorada
Permite que más consultas se ejecuten correctamente, con más lógica evaluada en la base de datos (en lugar de en
memoria) y menos datos innecesariamente recuperados de la base de datos.
Mejoras de GroupJoin
Este trabajo mejora el SQL que se genera para las combinaciones agrupadas. Las combinaciones agrupadas suelen
ser un resultado de subconsultas en propiedades de navegación opcionales.
Interpolación de cadenas en FromSql y ExecuteSqlCommand
C# 6 presentó la interpolación de cadenas, una característica que permite insertar expresiones de C# directamente
en literales de cadena, lo que proporciona una forma útil de compilar cadenas en tiempo de ejecución. En EF Core
2.0 se ha agregado compatibilidad especial con las cadenas interpoladas a las dos API principales que aceptan
cadenas SQL sin formato: FromSql y ExecuteSqlCommand . Esta nueva compatibilidad permite que la interpolación de
cadenas de C# se use de forma "segura". Es decir, de una forma que protege frente a errores de inserción de SQL
comunes que pueden producirse al crear SQL de forma dinámica en tiempo de ejecución.
Este es un ejemplo:
var city = "London";
var contactTitle = "Sales Representative";
using (var context = CreateContext())

{
context.Set<Customer>()
.FromSql($@"
SELECT *
FROM ""Customers""
WHERE ""City"" = {city} AND
""ContactTitle"" = {contactTitle}")
.ToArray();
}
En este ejemplo hay dos variables insertadas en la cadena de formato SQL. EF Core genera el SQL siguiente:
@p0='London' (Size = 4000)

@p1='Sales Representative' (Size = 4000)
SELECT *
FROM ""Customers""
WHERE ""City"" = @p0
AND ""ContactTitle"" = @p1
EF.Functions.Like ()
Se ha agregado la propiedad EF.Functions, que EF Core o los proveedores pueden usar para definir métodos que se
asignen a los operadores o a las funciones de base de datos de forma que se puedan invocar en consultas LINQ. El
primer ejemplo de este método es Like():
var aCustomers =
from c in context.Customers
where EF.Functions.Like(c.Name, "a%")
select c;
Observe que Like() incluye una implementación en memoria, lo que puede resultar útil al trabajar en una base de
datos en memoria o cuando es necesario evaluar el predicado en el lado cliente.
Administración de bases de datos

Enlace de pluralización para scaffolding de DbContext
EF Core 2.0 presenta un nuevo servicio IPluralizer que se usa para singularizar nombres de tipo de entidad y
pluralizar nombres DbSet. La implementación predeterminada no está operativa, por lo que simplemente se trata
de un enlace en el que los usuarios pueden conectar fácilmente su propio pluralizador.
Este es el aspecto del enlace de un desarrollador de su propio pluralizador:
public class MyDesignTimeServices : IDesignTimeServices
{
public void ConfigureDesignTimeServices(IServiceCollection services)
{
services.AddSingleton<IPluralizer, MyPluralizer>();
}
}
public class MyPluralizer : IPluralizer

{
public string Pluralize(string name)
{
return Inflector.Inflector.Pluralize(name) ?? name;
}
public string Singularize(string name)

{
return Inflector.Inflector.Singularize(name) ?? name;
}
}
Otros
Traslado del proveedor de SQLite de ADO.NET a SQLitePCL.raw
Esto proporciona una solución más robusta en Microsoft.Data.Sqlite para distribuir archivos binarios nativos de
SQLite en distintas plataformas.
Solo un proveedor por modelo
Mejora considerablemente la forma en que los proveedores pueden interactuar con el modelo y simplifica el
funcionamiento de las convenciones, las anotaciones y las API fluidas con distintos proveedores.
EF Core 2.0 ahora compila un elemento IModel diferente para cada proveedor que se va a usar. Esto suele ser
transparente para la aplicación. Esto ha permitido una simplificación de las API de metadatos de nivel inferior, de
modo que cualquier acceso a conceptos de metadatos relacionales comunes siempre se realiza mediante una
llamada a .Relational en lugar de a .SqlServer , .Sqlite , etc.
Registro y diagnóstico consolidados
Los mecanismos de registro (basados en ILogger) y diagnóstico (basados en DiagnosticSource) ahora comparten
más código.
Los identificadores de evento de los mensajes enviados a un elemento ILogger han cambiado en 2.0. Los
identificadores de evento ahora son únicos en el código de EF Core. Ahora, estos mensajes también siguen el
patrón estándar de registro estructurado que usa, por ejemplo, MVC.
Las categorías de registrador también han cambiado. Ahora hay un conjunto conocido de categorías a las que se
accede a través de DbLoggerCategory.
Los eventos de DiagnosticSource ahora usan los mismos nombres de identificador de evento que los mensajes de
ILogger correspondientes.
Características nuevas en EF Core 1.1
Modelado
Asignación de campos
Permite configurar un campo de respaldo para una propiedad. Puede resultar útil en las propiedades de solo
lectura o en los datos que tienen métodos Get/Set en lugar de una propiedad.
Asignación a tablas optimizadas para memoria en SQL Server
Puede especificar que la tabla a la que está asignada una entidad está optimizada para memoria. Cuando use EF
Core para crear y mantener una base de datos basada en el modelo (ya sea con migraciones o
Database.EnsureCreated() ), se creará una tabla optimizada para memoria para estas entidades.
API adicionales de seguimiento de cambios de EF6
Como Reload , GetModifiedProperties , GetDatabaseValues etc.
Consultar
Carga explícita
Permite desencadenar el rellenado de una propiedad de navegación o una entidad que se cargó anteriormente a
partir de la base de datos.
DbSet.Find
Proporciona una manera sencilla de capturar una entidad en función de su valor de clave principal.
Otros
Reintenta automáticamente los comandos de base de datos erróneos. Esto resulta especialmente útil cuando se
realizan conexiones a SQL Azure, donde los errores transitorios son comunes.
Reemplazo de servicio simplificado
Facilita el reemplazo de servicios internos que EF usa.
Características incluidas en EF Core 1.0
Plataformas
.NET Framework 4.5.1
Incluye la consola, WPF, WinForms, ASP.NET 4, etc.
.NET Standard 1.3
Incluye ASP.NET Core que tiene como destino tanto .NET Framework como .NET Core en Windows, OSX y Linux.
Modelado
Modelado básico
Según las entidades POCO con las propiedades get/set de tipos escalares comunes ( int , string , etc.).
Relaciones y propiedades de navegación
Las relaciones uno a varios y uno a cero se pueden especificar en el modelo en función de una clave externa. Las
propiedades de navegación de tipos de referencia o colección simple se pueden asociar con estas relaciones.
Construyen un modelo inicial en función de la forma de las clases de entidad.
API fluida
Permite reemplazar el método OnModelCreating en el contexto para seguir configurando el modelo que la
convención detectó.
Son atributos que se pueden agregar a las propiedades o clases de entidad y que influyen en el modelo de EF. Por
ejemplo, al agregar [Required] se indica a EF que una propiedad es obligatoria.
Asignación de tabla relacional
Permite asignar las entidades a tablas o columnas.
Generación de valor de clave
Incluye la generación de bases de datos y la generación del lado cliente.
Valores generados por la base de datos
Permite que la base de datos genere los valores en la inserción (valores predeterminados) o la actualización
(columnas calculadas).
Secuencias en SQL Server
Permite definir los objetos de secuencia en el modelo.
Restricciones únicas
Permite la definición de las claves alternativas y la capacidad de definir las relaciones que se dirigen a esa clave.
Índices
La definición de índices en el modelo introduce automáticamente índices en la base de datos. También se admiten
los índices únicos.
Propiedades de estado reemplazadas
Permite que las propiedades que se definen en el modelo no se declaren ni almacenen en la clase .NET, pero EF
Core sí puede hacer un seguimiento de ellas y actualizarlas. Suele usarse para las propiedades de clave externa
cuando no se desea exponerlas en el objeto.
Patrón de herencia de tabla por jerarquía
Permite que las entidades de una jerarquía de herencia se guarde en una sola tabla a través de una columna de
discriminador para identificar el tipo de entidad de un registro determinado en la base de datos.
Validación de modelos
Detecta los patrones no válidos del modelo y proporciona mensajes de error útiles.
Seguimiento de cambios de instantánea
Permite detectar automáticamente los cambios en las entidades a través de la comparación del estado actual con
una copia (instantánea) del estado original.
Seguimiento de cambios de notificación
Permite que las entidades notifiquen a la herramienta de seguimiento de cambios cuando se modifiquen los
valores de propiedad.
Acceso al estado con seguimiento
A través de DbContext.Entry y DbContext.ChangeTracker .
Adjuntar grafos o entidades desasociados
La nueva API DbContext.AttachGraph ayuda a volver a adjuntar entidades a un contexto para guardar las entidades
nuevas o modificadas.
Guardar datos
Funcionalidad básica de guardado
Permite que los cambios en las instancias de la entidad se conserven en la base de datos.
Simultaneidad optimista
Impide sobrescribir los cambios realizados por otro usuario desde que se capturaron de la base de datos.
Característica SaveChanges asincrónica
Puede liberar el subproceso actual para que procese otras solicitudes mientras la base de datos procesa los
comandos que se emiten desde SaveChanges .
Transacciones de bases de datos
Es decir, SaveChanges siempre es atómica (lo que significa que siempre se completa correctamente o que no se
realiza ningún cambio en la base de datos). También hay API relacionadas con transacciones que permiten
compartir las transacciones entre las instancias de contexto, etc.
Relacional: procesamiento de instrucciones por lotes
Proporciona un mejor rendimiento mediante el procesamiento por lotes de varios comandos
INSERT/UPDATE/DELETE en un solo ciclo de ida y vuelta a la base de datos.
Consultar
Compatibilidad básica con LINQ
Proporciona la capacidad de usar LINQ para recuperar datos de la base de datos.
Evaluación combinada de cliente/servidor
Permite que las consultas contengan una lógica que no se puede evaluar en la base de datos y, por lo tanto, se debe
evaluar después de que los datos se recuperan en la memoria.
NoTracking
Las consultas permiten ejecutar más rápido las consultas cuando el contexto no necesita supervisar los cambios
realizados en las instancias de entidad (esto es útil si los resultados son de solo lectura).
Carga diligente
Proporciona los métodos Include y ThenInclude para identificar los datos relacionados que se deben capturar
cuando se realizan las consultas.
Consulta asincrónica
Puede liberar el subproceso actual (y los recursos asociados) para que procese otras solicitudes mientras la base de
datos procesa la consulta.
Proporciona el método DbSet.FromSql para usar consultas SQL sin procesar para capturar datos. Estas consultas
también se pueden componer mediante LINQ.
Administración de esquemas de la base de datos

API de creación o eliminación de la base de datos
Diseñadas principalmente para realizar pruebas en las que desea crear o eliminar rápidamente la base de datos sin
usar migraciones.
Migraciones de la base de datos relacional
Permiten que un esquema de la base de datos relacional evolucione en el tiempo a medida que cambia el modelo.
Ingeniería inversa desde la base de datos
Aplica scaffolding a un modelo de EF en función de un esquema de la base de datos relacional.

SQL Server
Se conecta a Microsoft SQL Server 2008 y versiones posteriores.
SQLite
Se conecta a una base de datos SQLite 3.
En memoria
Diseñado para habilitar fácilmente la realización de pruebas sin conectarse a una base de datos real.
Proveedores de terceros
Existen varios proveedores disponibles para otros motores de base de datos. Para una lista completa, consulte
Proveedores de bases de datos.
Actualización de EF Core 1,0 RC1 a 1,0 RC2
En este artículo se proporcionan instrucciones para mover una aplicación compilada con paquetes RC1 a RC2.
Nombres y versiones de los paquetes

Entre RC1 y RC2, cambiamos de "Entity Framework 7" a "Entity Framework Core". Puede leer más sobre los
motivos del cambio en esta publicación de Scott Hanselman. Debido a este cambio, los nombres de los paquetes
cambiaron de EntityFramework.* a Microsoft.EntityFrameworkCore.* y nuestras versiones de 7.0.0-rc1-final a
1.0.0-rc2-final (o 1.0.0-preview1-final para las herramientas).
Tendrá que quitar por completo los paquetes RC1 y, a continuación, instalar los RC2. Esta es la
asignación para algunos paquetes comunes.
PA Q UET E RC 1 EQ UIVA L EN T ES DE RC 2
EntityFramework. MicrosoftSqlServer 7.0.0-RC1-final Microsoft. EntityFrameworkCore. SqlServer 1.0.0-RC2-final
EntityFramework. SQLite 7.0.0-RC1-final Microsoft. EntityFrameworkCore. SQLite 1.0.0-RC2-final
EntityFramework7. Npgsql 3.1.0-RC1-3 NpgSql. EntityFrameworkCore. Postgres
EntityFramework. SqlServerCompact35 7.0.0-RC1-final EntityFrameworkCore. SqlServerCompact35 1.0.0-RC2-final
EntityFramework. SqlServerCompact40 7.0.0-RC1-final EntityFrameworkCore. SqlServerCompact40 1.0.0-RC2-final
EntityFramework. inmemory 7.0.0-RC1-final Microsoft. EntityFrameworkCore. inmemory 1.0.0-RC2-final
EntityFramework. IBMDataServer 7.0.0-beta1 Todavía no está disponible para RC2
EntityFramework. Commands 7.0.0-RC1-final Microsoft. EntityFrameworkCore. Tools 1.0.0-preview1-final
EntityFramework. MicrosoftSqlServer. Design 7.0.0-RC1-final Microsoft. EntityFrameworkCore. SqlServer. Design 1.0.0-RC2-

final
Espacios de nombres
Junto con los nombres de paquete, los espacios de nombres cambiaron de Microsoft.Data.Entity.* a
Microsoft.EntityFrameworkCore.* . Puede controlar este cambio con una búsqueda/reemplazo de
using Microsoft.Data.Entity con using Microsoft.EntityFrameworkCore .
Cambios en la Convención de nomenclatura de tablas

Un cambio funcional significativo que se llevó a cabo en RC2 era usar el nombre de la propiedad DbSet<TEntity>
de una entidad determinada como el nombre de tabla al que se asigna, en lugar de simplemente el nombre de
clase. Puede leer más sobre este cambio en el problema del anuncio relacionado.
En el caso de las aplicaciones RC1 existentes, se recomienda agregar el código siguiente al principio del método
OnModelCreating para mantener la estrategia de nomenclatura RC1:
foreach (var entity in modelBuilder.Model.GetEntityTypes())
{
entity.Relational().TableName = entity.DisplayName();
}
Si desea adoptar la nueva estrategia de nomenclatura, se recomienda completar correctamente el resto de los
pasos de actualización y, a continuación, quitar el código y crear una migración para aplicar el cambio de nombre
de la tabla.
AddDbContext/Startup.cs cambia (solo proyectos de ASP.NET Core)

En RC1, tenía que agregar Entity Framework servicios al proveedor de servicios de la aplicación
Startup.ConfigureServices(...) :
services.AddEntityFramework()
.AddSqlServer()
.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(Configuration["ConnectionStrings:DefaultConnection"]));
En RC2, puede quitar las llamadas a AddEntityFramework() , AddSqlServer() , etc.:
services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(Configuration["ConnectionStrings:DefaultConnection"]));
También debe agregar un constructor, al contexto derivado, que toma las opciones de contexto y las pasa al
constructor base. Esto es necesario porque hemos quitado algunas de las ideas mágicas que snuck en segundo
plano:
public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options)

: base(options)
{
}
Pasar un IServiceProvider
Si tiene código RC1 que pasa un IServiceProvider al contexto, ahora se mueve a DbContextOptions , en lugar de ser
un parámetro de constructor independiente. Utilice DbContextOptionsBuilder.UseInternalServiceProvider(...) para
establecer el proveedor de servicios.
Prueba
El escenario más común para hacerlo era controlar el ámbito de una base de datos inmemory al realizar las
pruebas. Vea el artículo sobre las pruebas actualizadas para obtener un ejemplo de cómo hacerlo con RC2.
Resolver servicios internos desde el proveedor de servicios de aplicación (solo proyectos de ASP.NET Core )
Si tiene una aplicación ASP.NET Core y desea que EF resuelva los servicios internos del proveedor de servicios de
aplicación, hay una sobrecarga de AddDbContext que le permite configurar lo siguiente:
services.AddEntityFrameworkSqlServer()
.AddDbContext<ApplicationDbContext>((serviceProvider, options) =>
options.UseSqlServer(Configuration["ConnectionStrings:DefaultConnection"])
.UseInternalServiceProvider(serviceProvider));
WARNING
Se recomienda permitir que EF administre internamente sus propios servicios, a menos que tenga un motivo para combinar
los servicios de EF internos en el proveedor de servicios de aplicación. La razón principal por la que puede querer hacer esto
es usar el proveedor de servicios de aplicación para reemplazar los servicios que EF usa internamente
Comandos de DNX = CLI de .NET > (solo para proyectos de ASP.NET

Core)
Si anteriormente usó los comandos dnx ef para proyectos de ASP.NET 5, ahora se han pasado a dotnet ef
comandos. Todavía se aplica la misma sintaxis de comando. Puede usar dotnet ef --help para obtener
información sobre la sintaxis.
La forma en que se registran los comandos ha cambiado en RC2, debido a que DNX se ha reemplazado por la CLI
de .NET. Los comandos se registran ahora en una sección tools en project.json :
"tools": {
"Microsoft.EntityFrameworkCore.Tools": {
"version": "1.0.0-preview1-final",
"imports": [
"portable-net45+win8+dnxcore50",
"portable-net45+win8"
]
}
}
TIP
Si usa Visual Studio, ahora puede usar la consola del administrador de paquetes para ejecutar comandos EF para proyectos de
ASP.NET Core (esto no se admitía en RC1). Todavía tiene que registrar los comandos en la sección tools de project.json
para hacerlo.
Los comandos del administrador de paquetes requieren PowerShell 5

Si usa los comandos Entity Framework en la consola del administrador de paquetes en Visual Studio, tendrá que
asegurarse de que tiene PowerShell 5 instalado. Se trata de un requisito temporal que se quitará en la siguiente
versión (consulte el problema #5327 para obtener más detalles).
Usar "Imports" en Project. JSON

Algunas de las dependencias de EF Core no admiten aún .NET Standard. EF Core en .NET Standard y los proyectos
de .NET Core pueden requerir la adición de "Imports" a Project. JSON como una solución temporal.
Al agregar EF, la restauración de NuGet mostrará este mensaje de error:
Package Ix-Async 1.2.5 is not compatible with netcoreapp1.0 (.NETCoreApp,Version=v1.0). Package Ix-Async 1.2.5
supports:
- net40 (.NETFramework,Version=v4.0)
- portable-net45+win8+wp8 (.NETPortable,Version=v0.0,Profile=Profile78)
Package Remotion.Linq 2.0.2 is not compatible with netcoreapp1.0 (.NETCoreApp,Version=v1.0). Package
Remotion.Linq 2.0.2 supports:
- portable-net45+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=Profile259)
La solución consiste en importar manualmente el perfil portátil "portable-net451 + win8". Esto obliga a NuGet a
tratar estos binarios que coinciden con este proporcionado como un marco compatible con .NET Standard, aunque
no lo sean. Aunque "portable-net451 + win8" no es 100% compatible con .NET Standard, es lo suficientemente
compatible para la transición de PCL a .NET Standard. Las importaciones se pueden quitar cuando las dependencias
de EF finalmente se actualizan a .NET Standard.
Se pueden agregar varios marcos a "Imports" en la sintaxis de la matriz. Otras importaciones pueden ser
necesarias si agrega bibliotecas adicionales al proyecto.
{
"frameworks": {
"netcoreapp1.0": {
"imports": ["dnxcore50", "portable-net451+win8"]
}
}
}
Vea el problema #5176.

Actualización de EF Core 1,0 RC2 a RTM
En este artículo se proporcionan instrucciones para mover una aplicación compilada con los paquetes de RC2 a
1.0.0 RTM.
Versiones de paquetes
Los nombres de los paquetes de nivel superior que se instalarían normalmente en una aplicación no cambiaban
entre RC2 y RTM.
Debe actualizar los paquetes instalados a las versiones de RTM:
Los paquetes en tiempo de ejecución (por ejemplo, Microsoft.EntityFrameworkCore.SqlServer ) cambiaron de
1.0.0-rc2-final a 1.0.0 .
El paquete de Microsoft.EntityFrameworkCore.Tools ha cambiado de 1.0.0-preview1-final a

1.0.0-preview2-final . Tenga en cuenta que las herramientas siguen siendo versiones preliminares.
Es posible que las migraciones existentes necesiten maxLength

agregadas
En RC2, la definición de columna en una migración se parece a table.Column<string>(nullable: true) y la longitud
de la columna se buscó en algunos metadatos que almacenamos en el código subyacente a la migración. En RTM,
la longitud se incluye ahora en el código con scaffolding table.Column<string>(maxLength: 450, nullable: true) .
Las migraciones existentes con scaffolding antes de usar RTM no tendrán el argumento maxLength especificado.
Esto significa que se utilizará la longitud máxima admitida por la base de datos ( nvarchar(max) en SQL Server).
Esto puede ser adecuado para algunas columnas, pero las columnas que forman parte de una clave, clave externa o
índice deben actualizarse para incluir una longitud máxima. Por Convención, 450 es la longitud máxima utilizada
para las claves, las claves externas y las columnas indizadas. Si ha configurado explícitamente una longitud en el
modelo, debe utilizar esa longitud en su lugar.
ASP.NET Identity
Este cambio afecta a los proyectos que usan ASP.NET Identity y que se crearon a partir de una plantilla de proyecto
anterior a RTM. La plantilla de proyecto incluye una migración que se usa para crear la base de datos. Esta
migración se debe editar para especificar una longitud máxima de 256 para las columnas siguientes.
AspNetRoles
Nombre
NormalizedName
AspNetUsers
Email
NormalizedEmail
NormalizedUserName
UserName
Si no se realiza este cambio, se producirá la siguiente excepción cuando la migración inicial se aplique a una base
de datos.
System.Data.SqlClient.SqlException (0x80131904): Column 'NormalizedName' in table 'AspNetRoles' is of a type
that is invalid for use as a key column in an index.
.NET Core: Quite "Imports" en Project. JSON

Si el destino era .NET Core con RC2, necesitaba agregar imports a Project. JSON como una solución temporal para
algunas de las dependencias de EF Core que no admiten .NET Standard. Ahora se pueden quitar.
{
"frameworks": {
"netcoreapp1.0": {
"imports": ["dnxcore50", "portable-net451+win8"]
}
}
}
NOTE
A partir de la versión 1,0 RTM, el SDK de .net Core ya no admite project.json ni desarrollar aplicaciones de .net Core con
Visual Studio 2015. Se recomienda migrar de project.json a csproj. Si usa Visual Studio, se recomienda que actualice a visual
studio 2017.
UWP: agregar redirecciones de enlace

Al intentar ejecutar los comandos EF en los proyectos de Plataforma universal de Windows (UWP) se produce el
siguiente error:
System.IO.FileLoadException: Could not load file or assembly 'System.IO.FileSystem.Primitives, Version=4.0.0.0,

Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest
definition does not match the assembly reference.
Debe agregar manualmente redirecciones de enlace al proyecto de UWP. Cree un archivo denominado App.config
en la carpeta raíz del proyecto y agregue redireccionamientos a las versiones de ensamblado correctas.
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.IO.FileSystem.Primitives"
publicKeyToken="b03f5f7f11d50a3a"
culture="neutral" />
<bindingRedirect oldVersion="4.0.0.0"
newVersion="4.0.1.0"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Threading.Overlapped"
publicKeyToken="b03f5f7f11d50a3a"
culture="neutral" />
<bindingRedirect oldVersion="4.0.0.0"
newVersion="4.0.1.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
Actualización de las aplicaciones de las versiones
anteriores a EF Core 2,0
Hemos aprovechado la oportunidad de refinar significativamente las API y los comportamientos existentes en 2,0.
Hay algunas mejoras que pueden requerir la modificación del código de aplicación existente, aunque creemos que,
para la mayoría de las aplicaciones, el impacto será bajo, en la mayoría de los casos solo requiere volver a compilar
y cambios guiados mínimos para reemplazar las API obsoletas.
La actualización de una aplicación existente a EF Core 2,0 puede requerir:
1. Actualización de la implementación de .NET de destino de la aplicación a una que admite .NET Standard 2,0.
Vea implementaciones de .net compatibles para obtener más detalles.
2. Identifique un proveedor para la base de datos de destino que sea compatible con EF Core 2,0. Consulte EF
Core 2,0 requiere un proveedor de base de datos 2,0 .
3. Actualizar todos los paquetes de EF Core (tiempo de ejecución y herramientas) a 2,0. Consulte instalación de
EF Core para obtener más detalles.
4. Realice los cambios de código necesarios para compensar los cambios importantes descritos en el resto de
este documento.
ASP.NET Core ahora incluye EF Core

Las aplicaciones para ASP.NET Core 2.0 pueden usar EF Core 2.0 sin dependencias adicionales además de
proveedores de bases de datos de terceros. Sin embargo, las aplicaciones que tienen como destino versiones
anteriores de ASP.NET Core deben actualizar a ASP.NET Core 2,0 para poder usar EF Core 2,0. Para obtener más
información sobre la actualización de aplicaciones ASP.NET Core a 2,0, consulte la documentación de ASP.net Core
sobre el tema.
Nueva forma de obtener servicios de aplicación en ASP.NET Core

El patrón recomendado para las aplicaciones Web de ASP.NET Core se ha actualizado para 2,0 de forma que se
interrumpió la lógica en tiempo de diseño EF Core utiliza en 1. x. Anteriormente, en tiempo de diseño, EF Core
intentaría invocar Startup.ConfigureServices directamente para tener acceso al proveedor de servicios de la
aplicación. En ASP.NET Core 2,0, la configuración se inicializa fuera de la clase Startup . Las aplicaciones que usan
EF Core normalmente acceden a su cadena de conexión desde la configuración, por lo que Startup por sí misma
ya no es suficiente. Si actualiza una aplicación ASP.NET Core 1. x, es posible que reciba el siguiente error al usar las
herramientas de EF Core.
No se encontró ningún constructor sin parámetros en ' ApplicationContext '. Agregue un constructor sin
parámetros a ' ApplicationContext ' o agregue una implementación de '
IDesignTimeDbContextFactory<ApplicationContext>' en el mismo ensamblado que ' ApplicationContext '
Se ha agregado un nuevo enlace en tiempo de diseño a la plantilla predeterminada de ASP.NET Core 2.0. El método
Program.BuildWebHost estático permite a EF Core tener acceso al proveedor de servicios de la aplicación en tiempo
de diseño. Si está actualizando una aplicación ASP.NET Core 1. x, deberá actualizar la clase Program para que se
parezca a lo siguiente.
using Microsoft.AspNetCore;
using Microsoft.AspNetCore.Hosting;
namespace AspNetCoreDotNetCore2._0App
{
public class Program
{
public static void Main(string[] args)
{
BuildWebHost(args).Run();
}
public static IWebHost BuildWebHost(string[] args) =>

WebHost.CreateDefaultBuilder(args)
.UseStartup<Startup>()
.Build();
}
}
La adopción de este nuevo patrón al actualizar las aplicaciones a 2,0 es muy recomendable y es necesaria para que
funcionen las características del producto, como Entity Framework Core las migraciones. La otra alternativa común
es implementar IDesignTimeDbContextFactory<TContext > .
IDbContextFactory cambiado
Con el fin de admitir diversos patrones de aplicación y proporcionar a los usuarios un mayor control sobre cómo se
utiliza su DbContext en tiempo de diseño, en el pasado, siempre se ofrecía la interfaz IDbContextFactory<TContext> .
En tiempo de diseño, las herramientas de EF Core detectarán las implementaciones de esta interfaz en el proyecto y
la usarán para crear objetos DbContext .
Esta interfaz tenía un nombre muy general que engaña a algunos usuarios para intentar volver a usarlo para otros
escenarios de creación de DbContext . No estaban protegidos cuando las herramientas de EF intentaban usar su
implementación en tiempo de diseño y provocaban que se produjera un error en los comandos como
Update-Database o dotnet ef database update .
Con el fin de comunicar la semántica sólida en tiempo de diseño de esta interfaz, se le ha cambiado el nombre a
IDesignTimeDbContextFactory<TContext> .
En la versión 2,0, el IDbContextFactory<TContext> todavía existe pero está marcado como obsoleto.
DbContextFactoryOptions quitado
Debido a los cambios ASP.NET Core 2,0 descritos anteriormente, encontramos que DbContextFactoryOptions ya no
era necesario en la nueva interfaz de IDesignTimeDbContextFactory<TContext> . Estas son las alternativas que debe
usar en su lugar.
DB C O N T EXT FA C TO RY O P T IO N S A LT ERN AT IVA
ApplicationBasePath AppContext. BaseDirectory
ContentRootPath Directorio. GetCurrentDirectory ()
EnvironmentName Environment. GetEnvironmentVariable

("ASPNETCORE_ENVIRONMENT")
Directorio de trabajo en tiempo de diseño cambiado

Los cambios ASP.NET Core 2,0 también requerían el directorio de trabajo que usa dotnet ef para alinearse con el
directorio de trabajo que usa Visual Studio cuando se ejecuta la aplicación. Un efecto lateral observable de esto es
que los nombres de archivo de SQLite ahora son relativos al directorio del proyecto y no al directorio de salida
como se solían usar.
EF Core 2,0 requiere un proveedor de base de datos 2,0

Por EF Core 2,0 hemos realizado muchas simplificaciones y mejoras en la forma en que funcionan los proveedores
de bases de datos. Esto significa que los proveedores 1.0. x y 1.1. x no funcionarán con EF Core 2,0.
El equipo de EF envía los proveedores de SQL Server y SQLite, y las versiones 2,0 estarán disponibles como parte
de la versión 2,0. Los proveedores de terceros de código abierto para SQL Compact, PostgreSQLy MySQL se están
actualizando para 2,0. Para todos los demás proveedores, póngase en contacto con el escritor del proveedor.
Los eventos de diagnóstico y registro han cambiado

Nota: estos cambios no deben afectar a la mayoría del código de aplicación.
Los identificadores de eventos de los mensajes enviados a un ILogger han cambiado en 2,0. Los identificadores de
evento ahora son únicos en el código de EF Core. Ahora, estos mensajes también siguen el patrón estándar de
registro estructurado que usa, por ejemplo, MVC.
Las categorías de registrador también han cambiado. Ahora hay un conjunto conocido de categorías a las que se
accede a través de DbLoggerCategory.
Los eventos de DiagnosticSource ahora usan los mismos nombres de ID. de evento que los mensajes de ILogger
correspondientes. Las cargas de evento son tipos nominales derivados de EventData.
Los identificadores de eventos, tipos de carga y categorías se documentan en las clases CoreEventId y
RelationalEventId .
Los identificadores también se han pasado de Microsoft. EntityFrameworkCore. Infrastructure al nuevo espacio de
nombres Microsoft. EntityFrameworkCore. Diagnostics.
Cambios de la API de metadatos relacionales EF Core

EF Core 2.0 ahora compila un elemento IModel diferente para cada proveedor que se va a usar. Esto suele ser
transparente para la aplicación. Esto ha facilitado la simplificación de las API de metadatos de nivel inferior, de
modo que cualquier acceso a conceptos de metadatos relacionales comunes siempre se realiza a través de una
llamada a .Relational en lugar de .SqlServer , .Sqlite , etc. Por ejemplo, 1.1. x código similar al siguiente:
var tableName = context.Model.FindEntityType(typeof(User)).SqlServer().TableName;
Ahora debe escribirse de la siguiente manera:
var tableName = context.Model.FindEntityType(typeof(User)).Relational().TableName;
En lugar de utilizar métodos como ForSqlServerToTable , los métodos de extensión ahora están disponibles para
escribir código condicional basado en el proveedor actual en uso. Por ejemplo:
modelBuilder.Entity<User>().ToTable(
Database.IsSqlServer() ? "SqlServerName" : "OtherName");
Tenga en cuenta que este cambio solo se aplica a las API/metadatos que se definen para todos los proveedores
relacionales. La API y los metadatos siguen siendo los mismos cuando son específicos de un solo proveedor. Por
ejemplo, los índices clúster son específicos de SQL Server, por lo que se deben seguir ForSqlServerIsClustered y
.SqlServer().IsClustered() .
No tomar el control del proveedor de servicios de EF

EF Core usa una IServiceProvider interna (un contenedor de inserción de dependencias) para su implementación
interna. Las aplicaciones deben permitir que EF Core crear y administrar este proveedor, excepto en casos
especiales. Considere la posibilidad de quitar todas las llamadas a UseInternalServiceProvider . Si una aplicación
necesita llamar a UseInternalServiceProvider , considere la posibilidad de presentar un problema para que
podamos investigar otras maneras de controlar su escenario.
El código de aplicación no requiere la llamada a AddEntityFramework , AddEntityFrameworkSqlServer , etc. a menos
que se llame también a UseInternalServiceProvider . Quite todas las llamadas existentes a AddEntityFramework o
AddEntityFrameworkSqlServer , etc. AddDbContext debe seguir utilizándose de la misma manera que antes.
Las bases de datos en memoria deben tener nombre

La base de datos en memoria global sin nombre se ha quitado y, en su lugar, todas las bases de datos en memoria
deben tener nombre. Por ejemplo:
optionsBuilder.UseInMemoryDatabase("MyDatabase");
Esto crea o usa una base de datos con el nombre "base de datos". Si se llama de nuevo a UseInMemoryDatabase con
el mismo nombre, se usará la misma base de datos en memoria, lo que permite que varias instancias de contexto lo
compartan.
Cambios de la API de solo lectura

IsReadOnlyBeforeSave , IsReadOnlyAfterSave y IsStoreGeneratedAlways han quedado obsoletos y se han
reemplazado por BeforeSaveBehavior y AfterSaveBehavior. Estos comportamientos se aplican a cualquier
propiedad (no solo a las propiedades generadas por el almacén) y determinan cómo se debe usar el valor de la
propiedad al insertar en una fila de base de datos ( BeforeSaveBehavior ) o al actualizar una fila de base de datos
existente ( AfterSaveBehavior ).
Las propiedades marcadas como ValueGenerated. OnAddOrUpdate (por ejemplo, para las columnas calculadas)
omitirán de forma predeterminada cualquier valor establecido actualmente en la propiedad. Esto significa que
siempre se obtendrá un valor generado por el almacén independientemente de si se ha establecido o modificado
algún valor en la entidad a la que se realiza el seguimiento. Esto se puede cambiar estableciendo un
Before\AfterSaveBehavior diferente.
Nuevo comportamiento de eliminación de ClientSetNull

En versiones anteriores, DeleteBehavior. Restrict tenía un comportamiento para las entidades a las que realiza un
seguimiento el contexto que mejoró la semántica de SetNull coincidentes. En EF Core 2,0, se ha introducido un
nuevo comportamiento de ClientSetNull como valor predeterminado para las relaciones opcionales. Este
comportamiento tiene SetNull semántica para las entidades sometidas a seguimiento y el comportamiento de
Restrict para las bases de datos creadas mediante EF Core. En nuestra experiencia, estos son los
comportamientos más previstos y útiles para las entidades de las que se realiza un seguimiento y la base de datos.
ahora se respeta DeleteBehavior.Restrict para las entidades de las que se ha realizado un seguimiento cuando se
establece para relaciones opcionales.
Paquetes en tiempo de diseño del proveedor quitados
Se ha quitado el paquete de Microsoft.EntityFrameworkCore.Relational.Design. Su contenido se consolida en
Microsoft.EntityFrameworkCore.Relational y Microsoft.EntityFrameworkCore.Design .
Esto se propaga a los paquetes en tiempo de diseño del proveedor. Los paquetes (
Microsoft.EntityFrameworkCore.Sqlite.Design , Microsoft.EntityFrameworkCore.SqlServer.Design , etc.) se han quitado
y su contenido se ha consolidado en los paquetes principales del proveedor.
Para habilitar Scaffold-DbContext o dotnet ef dbcontext scaffold en EF Core 2,0, solo tiene que hacer referencia al
paquete de proveedor único:
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer"
Version="2.0.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools"
Version="2.0.0"
PrivateAssets="All" />
<DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet"
Version="2.0.0" />
Introducción a EF Core
En este tutorial se crea una aplicación de consola de .NET Core que realiza el acceso a datos en una base de datos
SQLite mediante Entity Framework Core.
Puede seguir el tutorial con Visual Studio en Windows o mediante la CLI de .NET Core en Windows, macOS o
Linux.
Vea un ejemplo de este artículo en GitHub.
Requisitos previos
Instale el software siguiente:
CLI de .NET Core
Visual Studio
SDK de .NET Core.
Crear un proyecto nuevo

CLI de .NET Core
Visual Studio
dotnet new console -o EFGetStarted

cd EFGetStarted
Instalación de Entity Framework Core

Para instalar EF Core, instale el paquete de los proveedores de bases de datos de EF Core que quiera establecer
como destino. Este tutorial usa SQLite porque se ejecuta en todas las plataformas compatibles con .NET Core. Para
obtener una lista de proveedores disponibles, vea Proveedores de bases de datos.
CLI de .NET Core
Visual Studio
dotnet add package Microsoft.EntityFrameworkCore.Sqlite
Creación del modelo

Defina una clase de contexto y clases de entidad que conformen el modelo.
CLI de .NET Core
Visual Studio
En el directorio del proyecto, cree Model.cs con el código siguiente.
namespace EFGetStarted
{
{
protected override void OnConfiguring(DbContextOptionsBuilder options)

=> options.UseSqlite("Data Source=blogging.db");
}
public class Blog

{
public List<Post> Posts { get; } = new List<Post>();

}
public class Post

{

}
}
EF Core también puede aplicar ingeniería inversa en un modelo desde una base de datos existente.
Sugerencia: En una aplicación real, lo habitual sería colocar cada clase en un archivo independiente y la cadena de
conexión, en un archivo de configuración o una variable de entorno. Para que el tutorial sea sencillo, todo está
incluido en un archivo.
Creación de la base de datos

Los pasos siguientes usan migraciones para crear una base de datos.
CLI de .NET Core
Visual Studio
Ejecute los comandos siguientes:
dotnet tool install --global dotnet-ef

dotnet add package Microsoft.EntityFrameworkCore.Design
dotnet ef migrations add InitialCreate
dotnet ef database update
Esto instala dotnet ef y el paquete de diseño necesario para ejecutar el comando en un proyecto. El
comando migrations aplica la técnica scaffolding a una migración para crear el conjunto inicial de tablas
para el modelo. El comando database update crea la base de datos y le aplica la nueva migración.
Creación, lectura, actualización y eliminación

Abra Program.cs y reemplace el contenido por el código siguiente:
using System;
using System.Linq;
namespace EFGetStarted
{
class Program
{
static void Main()
{
{
// Create
Console.WriteLine("Inserting a new blog");
db.Add(new Blog { Url = "http://blogs.msdn.com/adonet" });
db.SaveChanges();
// Read
Console.WriteLine("Querying for a blog");
var blog = db.Blogs
.OrderBy(b => b.BlogId)
.First();
// Update
Console.WriteLine("Updating the blog and adding a post");
blog.Url = "https://devblogs.microsoft.com/dotnet";
blog.Posts.Add(
new Post
{
Title = "Hello World",
Content = "I wrote an app using EF Core!"
});
db.SaveChanges();
// Delete
Console.WriteLine("Delete the blog");
db.Remove(blog);
db.SaveChanges();
}
}
}
}
Ejecutar la aplicación
CLI de .NET Core
Visual Studio
dotnet run
Pasos siguientes
Siga el tutorial de ASP.NET Core para usar EF Core en una aplicación web.
Obtenga más información sobre las expresiones de consulta LINQ.
Configure su modelo para especificar aspectos como requerido y longitud máxima.
Use Migraciones para actualizar el esquema de la base de datos después de cambiar el modelo.
Instalación de Entity Framework Core
Prerequisites
EF Core es una biblioteca de .NET Standard 2.0. Por este motivo, EF Core requiere una implementación de
.NET que admita .NET Standard 2.0 para poder ejecutarse. Otras bibliotecas de .NET Standard 2.0 también
pueden hacer referencia a EF Core.
Por ejemplo, puede usar EF Core para desarrollar aplicaciones que tengan como destino .NET Core. La
compilación de aplicaciones de .NET Core requiere el SDK de .NET Core. También puede usar un entorno de
desarrollo como Visual Studio, Visual Studio para Mac o Visual Studio Code. Para obtener más información,
vea Introducción a .NET Core.
Puede usar EF Core para desarrollar aplicaciones en Windows con Visual Studio. Se recomienda usar la
última versión de Visual Studio.
EF Core puede ejecutarse en otras implementaciones de .NET, como Xamarin y .NET Native. Pero en la
práctica, estas implementaciones tienen limitaciones de runtime que podrían afectar el rendimiento de EF
Core en su aplicación. Para obtener más información, vea Implementaciones de .NET compatibles con EF
Core.
Por último, los diferentes proveedores de bases de datos pueden requerir versiones de motores de bases de
datos, implementaciones de .NET o sistemas operativos específicas. Asegúrese de que esté disponible un
proveedor de bases de datos de EF Core que admita el entorno adecuado para su aplicación.
Obtención del runtime de Entity Framework Core

Para agregar EF Core a una aplicación, instale el paquete NuGet para el proveedor de bases de datos que quiera
usar.
Si está desarrollando una aplicación de ASP.NET Core, no tendrá que instalar los proveedores en memoria ni de
SQL Server. Estos proveedores están incluidos en las versiones actuales de ASP.NET Core, junto al runtime de EF
Core.
Para instalar o actualizar paquetes NuGet, puede usar la interfaz de la línea de comandos (CLI) de .NET Core, o bien
el cuadro de diálogo o la consola del Administrador de paquetes de Visual Studio.
CLI de .NET Core
Use el comando de la CLI de .NET Core en la línea de comandos del sistema operativo para instalar o
actualizar el proveedor de SQL Server de EF Core:
dotnet add package Microsoft.EntityFrameworkCore.SqlServer
Puede indicar una versión específica en el comando dotnet add package usando el modificador -v . Por
ejemplo, para instalar paquetes de EF Core 2.2.0, anexe -v 2.2.0 al comando.
Para obtener más información, vea Herramientas de la interfaz de la línea de comandos (CLI) de .NET Core.
Cuadro de diálogo Administrador de paquetes NuGet en Visual Studio
En el menú de Visual Studio, seleccione Proyecto > Administrar paquetes NuGet
Haga clic en la pestaña Examinar o Actualizaciones
Para instalar o actualizar el proveedor de SQL Server, seleccione el paquete
Microsoft.EntityFrameworkCore.SqlServer y confirme la acción.
Para obtener más información, vea Diálogo del Administrador de paquetes NuGet.
Consola del Administrador de paquetes NuGet de Visual Studio
En el menú de Visual Studio, seleccione Herramientas > Administrador de paquetes NuGet >
Consola del Administrador de paquetes .
Para instalar el proveedor de SQL Server, ejecute el comando siguiente en la consola del Administrador de
paquetes:
Install-Package Microsoft.EntityFrameworkCore.SqlServer
Para actualizar el proveedor, use el comando Update-Package .

Para especificar una versión, use el modificador -Version . Por ejemplo, para instalar paquetes de EF Core
2.2.0, anexe -Version 2.2.0 a los comandos.
Para obtener más información, vea Consola del Administrador de paquetes.
Obtención de las herramientas de Entity Framework Core

Puede instalar herramientas para llevar a cabo tareas relacionadas con EF Core en el proyecto, como crear y aplicar
las migraciones de bases de datos o crear un modelo de EF Core basado en una base de datos existente.
Existen dos conjuntos de herramientas:
Las herramientas de la interfaz de la línea de comandos (CLI) de .NET Core pueden usarse en Windows,
Linux y macOS. Estos comandos comienzan por dotnet ef .
Las herramientas de la consola del Administrador de paquetes (PMC) se ejecutan en Visual Studio
(Windows). Estos comandos empiezan por un verbo. Por ejemplo: Add-Migration , Update-Database .
Aunque puede usar los comandos de dotnet ef desde la consola del Administrador de paquetes, le
recomendamos que use las herramientas de la consola del Administrador de paquetes en Visual Studio:
Trabajan automáticamente con el proyecto actual seleccionado en la PMC de Visual Studio sin necesidad de
cambiar manualmente entre directorios.
Abren automáticamente los archivos generados por los comandos de Visual Studio una vez completado el
comando.
Obtención de las herramientas de la CLI de .NET Core
Las herramientas de la CLI de .NET Core requieren el SDK de .NET Core, tal como se indica en Requisitos previos.
Los comandos de dotnet ef están incluidos en las versiones actuales del SDK de .NET Core, pero es necesario
instalar el paquete Microsoft.EntityFrameworkCore.Design para habilitarlos en un proyecto específico:

IMPORTANT
Use siempre la versión del paquete de herramientas que coincida con la versión principal de los paquetes en tiempo de
ejecución.
Obtención de las herramientas de la consola del Administrador de paquetes

Para obtener las herramientas de la consola del Administrador de paquetes para EF Core, instale el paquete
Microsoft.EntityFrameworkCore.Tools . Por ejemplo, en Visual Studio:
Install-Package Microsoft.EntityFrameworkCore.Tools
Para las aplicaciones de ASP.NET Core, este paquete se incluye automáticamente.
Actualización a la versión más reciente de EF Core

Cuando publicamos una nueva versión de EF Core, también publicamos una nueva versión de los
proveedores que forman parte del proyecto de EF Core, como, por ejemplo:
Microsoft.EntityFrameworkCore.SqlServer, Microsoft.EntityFrameworkCore.Sqlite y
Microsoft.EntityFrameworkCore.InMemory. Para obtener todas las mejoras, solo tiene que actualizar a la
nueva versión del proveedor.
EF Core y los proveedores de SQL Server y en memoria están incluidos en las versiones actuales de ASP.NET
Core. Para actualizar una aplicación de ASP.NET Core existente a una versión más reciente de EF Core,
actualice siempre la versión de ASP.NET Core.
Si necesita actualizar una aplicación que usa un proveedor de base de datos de terceros, busque siempre
una actualización del proveedor que sea compatible con la versión de EF Core que quiere usar. Por ejemplo,
los proveedores de bases de datos de las versiones anteriores no son compatibles con la versión 2.0 del
runtime de EF Core.
Los proveedores de terceros de EF Core no suelen publicar versiones de revisión junto al runtime de EF
Core. Para actualizar una aplicación que use un proveedor de terceros a una versión de revisión de EF Core,
puede que deba agregar una referencia directa a determinados componentes de runtime de EF Core, como
Microsoft.EntityFrameworkCore o Microsoft.EntityFrameworkCore.Relational.
Si va a actualizar una aplicación existente a la última versión de EF Core, es posible que algunas referencias
a los paquetes más antiguos de EF Core tengan que quitarse manualmente:
Los paquetes en tiempo de diseño del proveedor de base de datos, como
Microsoft.EntityFrameworkCore.SqlServer.Design , ya no son necesarios ni se admiten en EF Core 2.0 y
versiones posteriores, pero no se quitan automáticamente al actualizar los demás paquetes.
Las herramientas de la CLI de .NET están incluidas en el SDK de .NET desde la versión 2.1, por lo que
se puede quitar la referencia a ese paquete desde el archivo del proyecto:
<DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="2.0.0" />

La mayoría de los proveedores de bases de datos requieren algún tipo de cadena de conexión para conectarse a la
base de datos. A veces, esta cadena de conexión contiene información confidencial que debe protegerse. También
es posible que necesite cambiar la cadena de conexión a medida que mueva la aplicación entre entornos, como
desarrollo, pruebas y producción.
Aplicaciones de WinForms & WPF

Las aplicaciones WinForms, WPF y ASP.NET 4 tienen un patrón de cadena de conexión probado y probado. La
cadena de conexión debe agregarse al archivo app. config de la aplicación (Web. config si usa ASP.NET). Si la
cadena de conexión contiene información confidencial, como el nombre de usuario y la contraseña, puede
proteger el contenido del archivo de configuración mediante la herramienta Administrador de secretos.
<?xml version="1.0" encoding="utf-8"?>

<configuration>
<connectionStrings>
<add name="BloggingDatabase"
connectionString="Server=(localdb)\mssqllocaldb;Database=Blogging;Trusted_Connection=True;" />
</connectionStrings>
</configuration>
TIP
El valor providerName no es necesario EF Core en las cadenas de conexión almacenadas en el archivo app. config porque el
proveedor de base de datos se configura mediante código.
Después, puede leer la cadena de conexión mediante el ConfigurationManager API en el método de OnConfiguring
del contexto. Es posible que tenga que agregar una referencia al ensamblado de System.Configuration Framework
para poder usar esta API.

{

{
optionsBuilder.UseSqlServer(ConfigurationManager.ConnectionStrings["BloggingDatabase"].ConnectionString);
}
}
Plataforma universal de Windows (UWP)

Las cadenas de conexión en una aplicación de UWP suelen ser una conexión de SQLite que solo especifica un
nombre de archivo local. Normalmente no contienen información confidencial y no es necesario cambiarla a
medida que se implementa una aplicación. Por lo tanto, estas cadenas de conexión suelen funcionar correctamente
al dejarse en el código, como se muestra a continuación. Si quiere moverlos fuera del código, UWP admite el
concepto de configuración, consulte la sección configuración de la aplicación de la documentación de UWP para
obtener más información.

{

{
optionsBuilder.UseSqlite("Data Source=blogging.db");
}
}
ASP.NET Core
En ASP.NET Core el sistema de configuración es muy flexible y la cadena de conexión puede almacenarse en
appsettings.json , una variable de entorno, el almacén de secretos de usuario u otro origen de configuración.
Consulte la sección configuración de la documentación de ASP.net Core para obtener más detalles. En el ejemplo
siguiente se muestra la cadena de conexión almacenada en appsettings.json .
{
"ConnectionStrings": {
"BloggingDatabase": "Server=
(localdb)\\mssqllocaldb;Database=EFGetStarted.ConsoleApp.NewDb;Trusted_Connection=True;"
},
}
Normalmente, el contexto se configura en Startup.cs con la cadena de conexión que se lee de la configuración.
Tenga en cuenta que el método GetConnectionString() busca un valor de configuración cuya clave sea
ConnectionStrings:<connection string name> . Debe importar el espacio de nombres Microsoft. Extensions.
Configuration para usar este método de extensión.
public void ConfigureServices(IServiceCollection services)

{
services.AddDbContext<BloggingContext>(options =>
options.UseSqlServer(Configuration.GetConnectionString("BloggingDatabase")));
}
Registro
TIP
Puede ver un ejemplo de este artículo en GitHub.
Aplicaciones de ASP.NET Core

EF Core se integra automáticamente con los mecanismos de registro de ASP.NET Core cada vez que se utiliza
AddDbContext o AddDbContextPool . Por lo tanto, al usar ASP.NET Core, el registro debe configurarse tal y como se
describe en la documentación de ASP.net Core.
Otras aplicaciones
El registro de EF Core requiere un ILoggerFactory que se configura a su vez con uno o más proveedores de
registro. Los proveedores comunes se incluyen en los siguientes paquetes:
Microsoft. Extensions. Logging. Console: un registrador de consola simple.
Microsoft. Extensions. Logging. AzureAppServices: admite las características ' registros de diagnóstico ' y ' flujo
de registro ' de los servicios de App de Azure.
Microsoft. Extensions. Logging. Debug: inicia sesión en un monitor de depurador con System. Diagnostics.
Debug. WriteLine ().
Microsoft. Extensions. Logging. EventLog: registra en el registro de eventos de Windows.
Microsoft. Extensions. Logging. EventSource: admite EventSource/EventListener.
Microsoft. Extensions. Logging. TraceSource: registra en un agente de escucha de seguimiento mediante
System.Diagnostics.TraceSource.TraceEvent() .
Después de instalar los paquetes adecuados, la aplicación debe crear una instancia singleton/global de un
LoggerFactory. Por ejemplo, mediante el registrador de consola:
Versión 3.x
Versión 2.x
public static readonly ILoggerFactory MyLoggerFactory

= LoggerFactory.Create(builder => { builder.AddConsole(); });
Esta instancia singleton/global se debe registrar con EF Core en el DbContextOptionsBuilder . Por ejemplo:

=> optionsBuilder
.UseLoggerFactory(MyLoggerFactory) // Warning: Do not create a new ILoggerFactory instance each time
.UseSqlServer(
@"Server=(localdb)\mssqllocaldb;Database=EFLogging;Trusted_Connection=True;ConnectRetryCount=0");
WARNING
Es muy importante que las aplicaciones no creen una nueva instancia de ILoggerFactory para cada instancia de contexto. Si lo
hace, se producirá una fuga de memoria y un rendimiento deficiente.
Filtrar lo que se registra

La aplicación puede controlar lo que se registra mediante la configuración de un filtro en el ILoggerProvider. Por
ejemplo:
Versión 3.x
Versión 2.x
public static readonly ILoggerFactory MyLoggerFactory

= LoggerFactory.Create(builder =>
{
builder
.AddFilter((category, level) =>
category == DbLoggerCategory.Database.Command.Name
&& level == LogLevel.Information)
.AddConsole();
});
En este ejemplo, el registro se filtra para que solo se devuelvan mensajes:

en la categoría "Microsoft. EntityFrameworkCore. Database. Command"
en el nivel de "información"
Por EF Core, las categorías del registrador se definen en la clase DbLoggerCategory para que sea más fácil encontrar
categorías, pero estas se resuelven en cadenas simples.
Puede encontrar más detalles sobre la infraestructura de registro subyacente en la documentación de registro de
ASP.net Core.
Resistencia de conexión
La resistencia de conexión reintenta automáticamente los comandos de base de datos con errores. La característica
se puede usar con cualquier base de datos proporcionando una "estrategia de ejecución", que encapsula la lógica
necesaria para detectar errores y volver a ejecutar los comandos. Los proveedores de EF Core pueden proporcionar
estrategias de ejecución adaptadas a sus condiciones de error de base de datos específica y las directivas de
reintento óptima.
Como ejemplo, el proveedor de SQL Server incluye una estrategia de ejecución que se adapta específicamente a
SQL Server (incluido SQL Azure). Es consciente de los tipos de excepción que se pueden reintentar y tienen valores
predeterminados razonables para el número máximo de reintentos, el retraso entre reintentos, etc.
Cuando se configuran las opciones para el contexto, se especifica una estrategia de ejecución. Normalmente, se
encuentra en el método OnConfiguring del contexto derivado:

{
optionsBuilder
.UseSqlServer(
@"Server=
(localdb)\mssqllocaldb;Database=EFMiscellanous.ConnectionResiliency;Trusted_Connection=True;ConnectRetryCount=0
",
options => options.EnableRetryOnFailure());
}
o en Startup.cs para una aplicación ASP.NET Core:

{
services.AddDbContext<PicnicContext>(
options => options.UseSqlServer(
"<connection string>",
providerOptions => providerOptions.EnableRetryOnFailure()));
}
Estrategia de ejecución personalizada

Existe un mecanismo para registrar una estrategia de ejecución personalizada propia si desea cambiar cualquiera
de los valores predeterminados.

{
optionsBuilder
.UseMyProvider(
"<connection string>",
options => options.ExecutionStrategy(...));
}
Estrategias de ejecución y transacciones

Una estrategia de ejecución que reintenta automáticamente los errores debe ser capaz de reproducir cada
operación en un bloque de reintentos en el que se produce un error. Cuando se habilitan los reintentos, cada
operación que se realiza a través de EF Core se convierte en su propia operación admite reintentos. Es decir, cada
consulta y cada llamada a SaveChanges() se reintentará como una unidad si se produce un error transitorio.
Sin embargo, si el código inicia una transacción mediante BeginTransaction() está definiendo su propio grupo de
operaciones que deben tratarse como una unidad, y todo lo que haya dentro de la transacción tendría que volver a
reproducirse en caso de que se produzca un error. Recibirá una excepción similar a la siguiente si intenta hacerlo al
usar una estrategia de ejecución:
InvalidOperationException: la estrategia de ejecución configurada ' SqlServerRetryingExecutionStrategy ' no

admite transacciones iniciadas por el usuario. Use la estrategia de ejecución que devuelve
"DbContext.Database.CreateExecutionStrategy()" para ejecutar todas las operaciones en la transacción como
una unidad que se puede reintentar.
La solución consiste en invocar manualmente la estrategia de ejecución con un delegado que representa todo lo
que se debe ejecutar. Si se produce un error transitorio, la estrategia de ejecución invoca al delegado de nuevo.

{
var strategy = db.Database.CreateExecutionStrategy();
strategy.Execute(() =>
{
using (var context = new BloggingContext())
{
using (var transaction = context.Database.BeginTransaction())
{
context.Blogs.Add(new Blog {Url = "http://blogs.msdn.com/dotnet"});
context.Blogs.Add(new Blog {Url = "http://blogs.msdn.com/visualstudio"});

transaction.Commit();
}
}
});
}
Este enfoque también se puede usar con transacciones de ambiente.

using (var context1 = new BloggingContext())
{
context1.Blogs.Add(new Blog { Url = "http://blogs.msdn.com/visualstudio" });
var strategy = context1.Database.CreateExecutionStrategy();
strategy.Execute(() =>
{
{
using (var transaction = new TransactionScope())
{
context2.Blogs.Add(new Blog { Url = "http://blogs.msdn.com/dotnet" });
context2.SaveChanges();
transaction.Complete();
}
}
});
}
Error de confirmación de la transacción y el problema Idempotencia

En general, cuando se produce un error de conexión, se revierte la transacción actual. Sin embargo, si se quita la
conexión mientras se confirma la transacción, se desconoce el estado resultante de la transacción.
De forma predeterminada, la estrategia de ejecución reintentará la operación como si la transacción se revirtió,
pero si no es así, se producirá una excepción si el nuevo estado de la base de datos es incompatible o podría
provocar daños en los datos si la operación no se basa en un estado determinado, por ejemplo, al insertar una
nueva fila con valores de clave generados automáticamente.
Hay varias maneras de solucionar este error.
Opción 1: hacer (casi) nada
La probabilidad de que se produzca un error de conexión durante la confirmación de la transacción es baja, por lo
que puede ser aceptable que la aplicación no funcione correctamente si esta condición se produce realmente.
Sin embargo, debe evitar el uso de claves generadas por el almacén para asegurarse de que se produce una
excepción en lugar de agregar una fila duplicada. Considere la posibilidad de usar un valor GUID generado por el
cliente o un generador de valores del lado cliente.
Opción 2: recompilar el estado de la aplicación
1. Descartar el DbContext actual.
2. Cree una nueva DbContext y restaure el estado de la aplicación desde la base de datos.
3. Informe al usuario de que es posible que la última operación no se haya completado correctamente.
Opción 3: agregar comprobación de estado
Para la mayoría de las operaciones que cambian el estado de la base de datos es posible agregar código que
comprueba si se ha realizado correctamente. EF proporciona un método de extensión para facilitar esta
IExecutionStrategy.ExecuteInTransaction .
Este método inicia y confirma una transacción y también acepta una función en el parámetro verifySucceeded que
se invoca cuando se produce un error transitorio durante la confirmación de la transacción.
{
var blogToAdd = new Blog {Url = "http://blogs.msdn.com/dotnet"};

db.Blogs.Add(blogToAdd);
strategy.ExecuteInTransaction(db,
operation: context =>
{
context.SaveChanges(acceptAllChangesOnSuccess: false);
},
verifySucceeded: context => context.Blogs.AsNoTracking().Any(b => b.BlogId == blogToAdd.BlogId));
db.ChangeTracker.AcceptAllChanges();
}
NOTE
Aquí SaveChanges se invoca con acceptAllChangesOnSuccess establecido en false para evitar cambiar el estado de la
entidad Blog a Unchanged si SaveChanges se realiza correctamente. Esto permite volver a intentar la misma operación si
se produce un error en la confirmación y se revierte la transacción.
Opción 4: realizar un seguimiento manual de la transacción

Si necesita usar claves generadas por el almacén o necesita una manera genérica de controlar los errores de
confirmación que no dependen de la operación realizada, se podría asignar a cada transacción un identificador que
se comprueba cuando se produce un error en la confirmación.
1. Agregue una tabla a la base de datos utilizada para realizar el seguimiento del estado de las transacciones.
2. Inserte una fila en la tabla al principio de cada transacción.
3. Si se produce un error en la conexión durante la confirmación, Compruebe la presencia de la fila
correspondiente en la base de datos.
4. Si la confirmación se realiza correctamente, elimine la fila correspondiente para evitar el crecimiento de la tabla.

{
db.Blogs.Add(new Blog { Url = "http://blogs.msdn.com/dotnet" });
var transaction = new TransactionRow {Id = Guid.NewGuid()};

db.Transactions.Add(transaction);
strategy.ExecuteInTransaction(db,
operation: context =>
{
context.SaveChanges(acceptAllChangesOnSuccess: false);
},
verifySucceeded: context => context.Transactions.AsNoTracking().Any(t => t.Id == transaction.Id));
db.ChangeTracker.AcceptAllChanges();
db.Transactions.Remove(transaction);
db.SaveChanges();
}
NOTE
Asegúrese de que el contexto utilizado para la comprobación tenga definida una estrategia de ejecución, ya que es probable
que se produzca un error en la conexión durante la comprobación si se produjo un error durante la confirmación de la
transacción.
Pruebas de código que usa EF Core
Para probar el código que accede a una base de datos, es necesario:

Ejecutar consultas y actualizaciones en el mismo sistema de base de datos que se usa en producción.
Ejecutar consultas y actualizaciones en algún otro sistema de base de datos más fácil de administrar.
Usar dobles de prueba o algún otro mecanismo para evitar por completo el uso de una base de datos.
En este documento se describen las ventajas e inconvenientes de cada una de estas opciones y se muestra cómo
usar EF Core con cada método.
Todos los proveedores de bases de datos no son iguales

Es muy importante entender que EF Core no está diseñado para extraer cada aspecto del sistema de base de datos
subyacente. EF Core es un conjunto común de patrones y conceptos que se pueden usar con cualquier sistema de
base de datos. Así, los proveedores de bases de datos de EF Core basan el comportamiento y la funcionalidad
específicos de base de datos en este marco común. Esto permite a cada sistema de base de datos hacer lo que
mejor se le da, a la vez que mantiene la homogeneidad, si fuera necesario, con otros sistemas de base de datos.
Básicamente, esto significa que al cambiar de proveedor de base de datos, cambia el comportamiento de EF Core y
no se puede esperar que la aplicación funcione correctamente a menos que tenga en cuenta de forma explícita
todas las diferencias de comportamiento. Dicho esto, en muchos casos esto funciona, ya que hay un alto grado de
homogeneidad entre bases de datos relacionales. Esto es bueno y malo. Es bueno porque el cambio entre bases de
datos puede ser relativamente fácil. Es malo porque puede dar una falsa sensación de seguridad si la aplicación no
se prueba por completo en el nuevo sistema de base de datos.
Enfoque 1: Sistema de base de datos de producción

Como se ha explicado en la sección anterior, la única manera de asegurarse de que se está probando lo que se
ejecuta en producción es usar el mismo sistema de base de datos. Por ejemplo, si la aplicación implementada usa
SQL Azure, las pruebas también deben realizarse en SQL Azure.
Pero que cada desarrollador ejecute pruebas en SQL Azure mientras trabaja activamente en el código es lento y
costoso. Esto muestra la principal contrapartida de estos métodos: ¿cuándo resulta adecuado desviarse del
sistema de base de datos de producción para mejorar la eficacia de las pruebas?
Afortunadamente, en este caso, la respuesta es bastante fácil: use la instancia local de SQL Server para las pruebas
de desarrollador. SQL Azure y SQL Server son muy similares, por lo que realizar las pruebas en SQL Server suele
ser una contrapartida razonable. Dicho esto, sigue siendo aconsejable ejecutar las pruebas en SQL Azure antes de
pasar a producción.
LocalDb
Todos los principales sistemas de base de datos tienen alguna forma de "edición para desarrolladores" para las
pruebas locales. SQL Server también tiene una característica denominada LocalDb. La principal ventaja de LocalDb
es que inicia la instancia de base de datos a petición. Esto evita que haya un servicio de base de datos
ejecutándose en el equipo aunque no se estén ejecutando pruebas.
Pero LocalDb también plantea problemas:
No admite todo lo que SQL Server Developer Edition.
No está disponible en Linux.
Puede producir un retraso en la primera serie de pruebas cuando se inicia el servicio.
Personalmente, nunca me ha parecido un problema que haya un servicio de base de datos ejecutándose en el
equipo de desarrollo y, en general, recomendaría usar Developer Edition. Pero puede ser adecuado para algunas
personas, especialmente en equipos de desarrollo menos potentes.
Enfoque 2: SQLite
EF Core prueba el proveedor de SQL Server principalmente mediante su ejecución en una instancia local de SQL
Server. Estas pruebas ejecutan decenas de miles de consultas en un par de minutos en un equipo rápido. Esto
muestra que el uso del sistema de base de datos real puede ser una solución eficiente. Es un mito que el uso de
una base de datos más ligera sea la única manera de ejecutar pruebas rápidamente.
Dicho esto, ¿qué ocurre si, por cualquier motivo, no se pueden ejecutar pruebas en algo cercano al sistema de base
de datos de producción? La siguiente mejor opción es usar algo con funcionalidad similar. Esto suele significar otra
base de datos relacional, para lo que SQLite es la opción obvia.
SQLite es una buena opción porque:
Se ejecuta en proceso con la aplicación y, por tanto, tiene poca sobrecarga.
Usa archivos simples creados automáticamente para bases de datos, por lo que no requiere administración de
bases de datos.
Tiene un modo en memoria que evita incluso la creación de archivos.
Pero recuerde que:
SQLite inevitablemente no admite todo lo que el sistema de base de datos de producción.
SQLite se comporta de forma diferente al sistema de base de datos de producción para algunas consultas.
Por lo tanto, si usa SQLite para algunas pruebas, asegúrese de probar también en el sistema de base de datos real.
Vea Pruebas con SQLite para obtener instrucciones específicas de EF Core.
Método 3: Base de datos en memoria de EF Core

EF Core incluye una base de datos en memoria que se usa para las pruebas internas del propio EF Core. Esta base
de datos en general no es adecuada como sustituto para probar las aplicaciones que usan EF Core . De
manera específica:
No es una base de datos relacional
No admite transacciones
No está optimizada para el rendimiento
Nada de esto es muy importante a la hora de probar elementos internos de EF Core, ya que se usa
específicamente donde la base de datos es irrelevante para la prueba. Por otro lado, estos aspectos tienden a ser
muy importantes al probar una aplicación que usa EF Core.
Pruebas unitarias
Imagine que va a probar una parte de la lógica de negocio que pueda necesitar usar algunos datos de una base de
datos, pero que no supone probar propiamente las interacciones de la base de datos. Una opción es usar un doble
de prueba como simulacro o imitación.
Los dobles de prueba se usan para las pruebas internas de EF Core. Pero nunca se intentan simular DbContext o
IQueryable. Hacerlo es difícil, engorroso y delicado. No lo haga.
En su lugar, se usa la base de datos en memoria siempre que se realizan pruebas unitarias de algo que usa
DbContext. En este caso, el uso de la base de datos en memoria es adecuado porque la prueba no depende del
comportamiento de la base de datos. Pero no lo haga para probar consultas o actualizaciones reales de la base de
datos.
Vea Pruebas con InMemory para obtener instrucciones específicas de EF Core sobre el uso de la base de datos en
memoria para las pruebas unitarias.
Pruebas con SQLite
SQLite tiene un modo en memoria que le permite usar SQLite para escribir pruebas en una base de datos
relacional, sin la sobrecarga de las operaciones de base de datos reales.
TIP
Puede ver el ejemplo de este artículo en github
Escenario de prueba de ejemplo

Considere el siguiente servicio que permite al código de la aplicación realizar algunas operaciones relacionadas
con blogs. Utiliza internamente un DbContext que se conecta a una base de datos SQL Server. Sería útil
intercambiar este contexto para conectarse a una base de datos de SQLite en memoria, de modo que podamos
escribir pruebas eficaces para este servicio sin tener que modificar el código o hacer mucho trabajo para crear un
doble de prueba del contexto.
using System.Linq;
namespace BusinessLogic
{
public class BlogService
{
private BloggingContext _context;
public BlogService(BloggingContext context)

{
_context = context;
}
public void Add(string url)

{
var blog = new Blog { Url = url };
_context.Blogs.Add(blog);
_context.SaveChanges();
}
public IEnumerable<Blog> Find(string term)

{
return _context.Blogs
.Where(b => b.Url.Contains(term))
.ToList();
}
}
}
Preparar el contexto
Evite configurar dos proveedores de bases de datos
En las pruebas, va a configurar externamente el contexto para usar el proveedor de inmemory. Si está
configurando un proveedor de base de datos invalidando OnConfiguring en el contexto, deberá agregar código
condicional para asegurarse de que solo se configura el proveedor de base de datos si aún no se ha configurado
ninguno.
TIP
Si usa ASP.NET Core, no necesitará este código, ya que el proveedor de la base de datos se configura fuera del contexto (en
Startup.cs).

{
if (!optionsBuilder.IsConfigured)
{
optionsBuilder.UseSqlServer(@"Server=
(localdb)\mssqllocaldb;Database=EFProviders.InMemory;Trusted_Connection=True;ConnectRetryCount=0");
}
}
Agregar un constructor para las pruebas

La manera más sencilla de habilitar las pruebas en una base de datos diferente es modificar el contexto para
exponer un constructor que acepta un DbContextOptions<TContext> .

{
public BloggingContext()
{ }
public BloggingContext(DbContextOptions<BloggingContext> options)

: base(options)
{ }
TIP
DbContextOptions<TContext> indica al contexto toda su configuración, como la base de datos a la que se va a conectar.
Este es el mismo objeto que se genera al ejecutar el método de configuración en el contexto.
Escribir pruebas
La clave para realizar pruebas con este proveedor es la posibilidad de indicar al contexto que use SQLite y
controlar el ámbito de la base de datos en memoria. El ámbito de la base de datos se controla mediante la
apertura y el cierre de la conexión. La base de datos está en el ámbito de la duración de la conexión abierta.
Normalmente, desea una base de datos limpia para cada método de prueba.
TIP
Para usar SqliteConnection() y el método de extensión .UseSqlite() , haga referencia al paquete NuGet Microsoft.
EntityFrameworkCore. SQLite.
using BusinessLogic;
using Microsoft.Data.Sqlite;
using System.Linq;
using Xunit;
namespace EFTesting.TestProject.SQLite
{
{
public class BlogServiceTests
{
[Fact]
public void Add_writes_to_database()
{
// In-memory database only exists while the connection is open
var connection = new SqliteConnection("DataSource=:memory:");
connection.Open();
try
{
var options = new DbContextOptionsBuilder<BloggingContext>()
.UseSqlite(connection)
.Options;
// Create the schema in the database

using (var context = new BloggingContext(options))
{
context.Database.EnsureCreated();
}
// Run the test against one instance of the context

{
var service = new BlogService(context);
service.Add("https://example.com");
}
// Use a separate instance of the context to verify correct data was saved to database
{
Assert.Equal(1, context.Blogs.Count());
Assert.Equal("https://example.com", context.Blogs.Single().Url);
}
}
finally
{
connection.Close();
}
}
[Fact]
public void Find_searches_url()
{
// In-memory database only exists while the connection is open
var connection = new SqliteConnection("DataSource=:memory:");
connection.Open();
try
{
.UseSqlite(connection)
.Options;
// Create the schema in the database

{
}
// Insert seed data into the database using one instance of the context
{
context.Blogs.Add(new Blog { Url = "https://example.com/cats" });
context.Blogs.Add(new Blog { Url = "https://example.com/catfish" });
context.Blogs.Add(new Blog { Url = "https://example.com/dogs" });
}
// Use a clean instance of the context to run the test

{
var result = service.Find("cat");
Assert.Equal(2, result.Count());
}
}
finally
{
connection.Close();
}
}
}
}
El proveedor de inmemory es útil cuando se desea probar los componentes mediante algo que se aproxima a la
conexión a la base de datos real, sin la sobrecarga de las operaciones de base de datos reales.
TIP
La inmemory no es una base de datos relacional

EF Core proveedores de bases de datos no tienen que ser bases de datos relacionales. La inmemory está diseñada
para ser una base de datos de uso general para las pruebas y no está diseñada para imitar una base de datos
relacional.
Algunos ejemplos de esto son:
La inmemory le permitirá guardar datos que infrinjan las restricciones de integridad referencial en una base de
datos relacional.
Si usa DefaultValueSql (String) para una propiedad en el modelo, se trata de una API de base de datos
relacional y no tendrá ningún efecto cuando se ejecute en inmemory.
No se admite la simultaneidad mediante la versión de marca de tiempo o fila ( [Timestamp] o IsRowVersion ).
No se producirá DbUpdateConcurrencyException si se realiza una actualización mediante un token de
simultaneidad antiguo.
TIP
Para muchos propósitos de prueba, estas diferencias no serán importantes. Sin embargo, si desea probar algo que se
comporta más como una verdadera base de datos relacional, considere el uso del modo en memoria de SQLite.
Escenario de prueba de ejemplo

Considere el siguiente servicio que permite al código de la aplicación realizar algunas operaciones relacionadas
con blogs. Utiliza internamente un DbContext que se conecta a una base de datos SQL Server. Sería útil
intercambiar este contexto para conectarse a una base de datos inmemory de modo que podamos escribir
pruebas eficaces para este servicio sin tener que modificar el código, o hacer mucho trabajo para crear un doble
de prueba del contexto.
using System.Linq;
namespace BusinessLogic
{
{

{
_context = context;
}
public void Add(string url)

{
}
public IEnumerable<Blog> Find(string term)

{
return _context.Blogs
.Where(b => b.Url.Contains(term))
.ToList();
}
}
}
Preparar el contexto
Evite configurar dos proveedores de bases de datos
En las pruebas, va a configurar externamente el contexto para usar el proveedor de inmemory. Si está
configurando un proveedor de base de datos invalidando OnConfiguring en el contexto, deberá agregar código
condicional para asegurarse de que solo se configura el proveedor de base de datos si aún no se ha configurado
ninguno.

{
if (!optionsBuilder.IsConfigured)
{
optionsBuilder.UseSqlServer(@"Server=
(localdb)\mssqllocaldb;Database=EFProviders.InMemory;Trusted_Connection=True;ConnectRetryCount=0");
}
}
TIP
Si usa ASP.NET Core, no necesitará este código ya que el proveedor de base de datos ya está configurado fuera del contexto
(en Startup.cs).
Agregar un constructor para las pruebas

La manera más sencilla de habilitar las pruebas en una base de datos diferente es modificar el contexto para
exponer un constructor que acepta un DbContextOptions<TContext> .
{
{ }

: base(options)
{ }
TIP
DbContextOptions<TContext> indica al contexto toda su configuración, como la base de datos a la que se va a conectar.
Este es el mismo objeto que se genera al ejecutar el método de configuración en el contexto.
Escribir pruebas
La clave para probar con este proveedor es la capacidad de indicar al contexto que use el proveedor de inmemory
y controlar el ámbito de la base de datos en memoria. Normalmente, desea una base de datos limpia para cada
método de prueba.
Este es un ejemplo de una clase de prueba que usa la base de datos inmemory. Cada método de prueba especifica
un nombre de base de datos único, lo que significa que cada método tiene su propia base de datos inmemory.
TIP
Para usar el método de extensión .UseInMemoryDatabase() , haga referencia al paquete NuGet Microsoft.
EntityFrameworkCore. inmemory.
using BusinessLogic;
using System.Linq;
using Xunit;
namespace EFTesting.TestProject.InMemory
{
public class BlogServiceTests
{
[Fact]
public void Add_writes_to_database()
{
.UseInMemoryDatabase(databaseName: "Add_writes_to_database")
.Options;
// Run the test against one instance of the context

{
service.Add("https://example.com");
}
// Use a separate instance of the context to verify correct data was saved to database
{
Assert.Equal(1, context.Blogs.Count());
Assert.Equal("https://example.com", context.Blogs.Single().Url);
}
}
[Fact]
public void Find_searches_url()
{
.UseInMemoryDatabase(databaseName: "Find_searches_url")
.Options;
// Insert seed data into the database using one instance of the context
{
context.Blogs.Add(new Blog { Url = "https://example.com/cats" });
context.Blogs.Add(new Blog { Url = "https://example.com/catfish" });
context.Blogs.Add(new Blog { Url = "https://example.com/dogs" });
}
// Use a clean instance of the context to run the test

{
var result = service.Find("cat");
Assert.Equal(2, result.Count());
}
}
}
}
Configuración de un DbContext
En este artículo se muestran los patrones básicos para configurar un DbContext a través de un DbContextOptions
para conectarse a una base de datos mediante un proveedor de EF Core específico y comportamientos opcionales.
Configuración de DbContext en tiempo de diseño

EF Core herramientas en tiempo de diseño como las migraciones deben ser capaces de detectar y crear una
instancia de trabajo de un tipo de DbContext para recopilar detalles sobre los tipos de entidad de la aplicación y
cómo se asignan a un esquema de base de datos. Este proceso puede ser automático siempre y cuando la
herramienta pueda crear fácilmente el DbContext de manera que se configurará de forma similar a como se
configuraría en tiempo de ejecución.
Aunque cualquier patrón que proporcione la información de configuración necesaria para el DbContext puede
funcionar en tiempo de ejecución, las herramientas que requieren el uso de un DbContext en tiempo de diseño
solo pueden funcionar con un número limitado de patrones. Estos se describen con más detalle en la sección
creación de contexto en tiempo de diseño .
Configuración de DbContextOptions
DbContext debe tener una instancia de DbContextOptions para poder realizar cualquier trabajo. La instancia de
DbContextOptions contiene información de configuración como:
Proveedor de base de datos que se va a usar, normalmente seleccionado mediante la invocación de un método
como UseSqlServer o UseSqlite . Estos métodos de extensión requieren el paquete de proveedor
correspondiente, como Microsoft.EntityFrameworkCore.SqlServer o Microsoft.EntityFrameworkCore.Sqlite . Los
métodos se definen en el espacio de nombres Microsoft.EntityFrameworkCore .
Cualquier cadena de conexión o identificador de la instancia de base de datos que sea necesario, normalmente
se pasa como argumento al método de selección de proveedor mencionado anteriormente
Cualquier selector de comportamiento opcional de nivel de proveedor, normalmente también encadenado
dentro de la llamada al método de selección de proveedor.
Los selectores de comportamiento de EF Core general, normalmente encadenados después o antes del método
de selector de proveedor
En el ejemplo siguiente se configura el DbContextOptions para utilizar el proveedor de SQL Server, una conexión
contenida en la variable connectionString , un tiempo de espera de comando de nivel de proveedor y un selector
de comportamiento de EF Core que hace que todas las consultas ejecutadas en el DbContext sin seguimiento de
forma predeterminada:
optionsBuilder
.UseSqlServer(connectionString, providerOptions=>providerOptions.CommandTimeout(60))
.UseQueryTrackingBehavior(QueryTrackingBehavior.NoTracking);
NOTE
Los métodos de selector de proveedor y otros métodos de selector de comportamiento mencionados anteriormente son
métodos de extensión en DbContextOptions o clases de opciones específicas del proveedor. Para tener acceso a estos
métodos de extensión, puede que necesite tener un espacio de nombres (normalmente Microsoft.EntityFrameworkCore )
en el ámbito e incluir dependencias de paquetes adicionales en el proyecto.
El DbContextOptions se puede proporcionar al DbContext invalidando el método de OnConfiguring o externamente

a través de un argumento de constructor.
Si se usan ambos, OnConfiguring se aplica en último lugar y puede sobrescribir las opciones proporcionadas al
argumento del constructor.
Argumento de constructor
El constructor simplemente puede aceptar un DbContextOptions como se indica a continuación:

{
: base(options)
{ }

}
TIP
El constructor base de DbContext también acepta la versión no genérica de DbContextOptions , pero no se recomienda usar
la versión no genérica para las aplicaciones con varios tipos de contexto.
Ahora la aplicación puede pasar el DbContextOptions al crear una instancia de un contexto, como se indica a
continuación:
var optionsBuilder = new DbContextOptionsBuilder<BloggingContext>();

optionsBuilder.UseSqlite("Data Source=blog.db");
using (var context = new BloggingContext(optionsBuilder.Options))

{
// do stuff
}
Configuración
También puede inicializar la DbContextOptions dentro del propio contexto. Aunque puede usar esta técnica para la
configuración básica, normalmente tendrá que obtener determinados detalles de configuración del exterior, por
ejemplo, una cadena de conexión de base de datos. Esto puede hacerse con una API de configuración o con
cualquier otro medio.
Para inicializar DbContextOptions dentro del contexto, invalide el método OnConfiguring y llame a los métodos en
el DbContextOptionsBuilder proporcionado:
{

{
}
}
Una aplicación simplemente puede crear una instancia de este tipo de contexto sin pasar nada a su constructor:

{
// do stuff
}
TIP
Este enfoque no se presta a las pruebas, a menos que las pruebas tengan como destino la base de datos completa.
Usar DbContext con la inserción de dependencias

EF Core admite el uso de DbContext con un contenedor de inserción de dependencias. El tipo DbContext se puede
Agregar al contenedor de servicio mediante el método AddDbContext<TContext> .
AddDbContext<TContext> hará que el tipo DbContext, el TContext y el DbContextOptions<TContext> correspondiente
estén disponibles para la inserción desde el contenedor de servicios.
Vea más información a continuación para obtener más información sobre la inserción de dependencias.
Agregar el DbContext a la inserción de dependencias:

{
services.AddDbContext<BloggingContext>(options => options.UseSqlite("Data Source=blog.db"));
}
Esto requiere agregar un argumento de constructor al tipo DbContext que acepte DbContextOptions<TContext> .
Código de contexto:

{
:base(options)
{ }

}
Código de la aplicación (en ASP.NET Core):

public class MyController
{
private readonly BloggingContext _context;
public MyController(BloggingContext context)

{
_context = context;
}
...
}
Código de aplicación (mediante ServiceProvider directamente, menos común):
using (var context = serviceProvider.GetService<BloggingContext>())

{
// do stuff
}
var options = serviceProvider.GetService<DbContextOptions<BloggingContext>>();
Evitar problemas de subprocesos DbContext

Entity Framework Core no admite varias operaciones paralelas que se ejecutan en la misma instancia de
DbContext . Esto incluye la ejecución paralela de consultas asincrónicas y cualquier uso simultáneo explícito de
varios subprocesos. Por lo tanto, siempre await llamadas asincrónicas inmediatamente, o bien usar instancias de
DbContext independientes para las operaciones que se ejecutan en paralelo.
Cuando EF Core detecta un intento de usar una instancia de DbContext simultáneamente, verá un
InvalidOperationException con un mensaje similar al siguiente:
Se inició una segunda operación en este contexto antes de que se completara una operación anterior. Esto se
debe normalmente a distintos subprocesos que usan la misma instancia de DbContext; sin embargo, no se
garantiza que los miembros de instancia sean seguros para subprocesos.
Cuando el acceso simultáneo no se detecta, puede dar lugar a un comportamiento indefinido, a bloqueos de la
aplicación y a daños en los datos.
Hay errores comunes que pueden provocar involuntariamente el acceso simultáneo en la misma instancia de
DbContext :
Se olvida esperar la finalización de una operación asincrónica antes de iniciar cualquier otra operación en el
mismo DbContext
Los métodos asincrónicos permiten a EF Core iniciar las operaciones que tienen acceso a la base de datos sin
bloqueos. Pero si el autor de la llamada no espera la finalización de uno de estos métodos y continúa realizando
otras operaciones en el DbContext , el estado de la DbContext puede ser (y probablemente estará) dañado.
Esperar siempre EF Core métodos asincrónicos inmediatamente.
Compartir instancias de DbContext implícitamente entre varios subprocesos mediante la inserción de
dependencias
El método de extensión AddDbContext registra los tipos de DbContext con una duración de ámbito de forma
predeterminada.
Esto es seguro frente a problemas de acceso simultáneos en la mayoría de las aplicaciones ASP.NET Core porque
solo hay un subproceso que ejecuta cada solicitud de cliente en un momento dado, y dado que cada solicitud
obtiene un ámbito de inyección de dependencia independiente (y, por tanto, una instancia de DbContext
independiente). Para el modelo de hospedaje de servidor increíble, se usa una solicitud lógica para mantener el
circuito de usuario increíble y, por lo tanto, solo hay una instancia de DbContext con ámbito disponible por circuito
de usuario si se usa el ámbito de inyección predeterminado.
Cualquier código que ejecute explícitamente varios subprocesos en paralelo debe asegurarse de que no se tiene
acceso a las instancias de DbContext simultáneamente.
Mediante la inserción de dependencias, esto se puede lograr registrando el contexto como ámbito y creando
ámbitos (mediante IServiceScopeFactory ) para cada subproceso, o registrando el DbContext como transitorio
(mediante la sobrecarga de AddDbContext que toma un parámetro ServiceLifetime ).
Más lecturas
Lea inserción de dependencias para obtener más información sobre el uso de di.
Lea pruebas para obtener más información.
Trabajar con tipos de referencia que aceptan valores
NULL
C#8 presentó una nueva característica denominada tipos de referencia que aceptan valores NULL, lo que permite
anotar tipos de referencia, lo que indica si es válido que contengan null o not. Si no está familiarizado con esta
característica, se recomienda que se familiarice con ella leyendo los C# documentos.
En esta página se presenta la compatibilidad de EF Core con tipos de referencia que aceptan valores NULL y se
describen los procedimientos recomendados para trabajar con ellos.
Propiedades obligatorias y opcionales

La documentación principal sobre las propiedades obligatorias y opcionales y su interacción con tipos de
referencia que aceptan valores NULL es la página de propiedades obligatoria y opcional . Se recomienda comenzar
leyendo primero esa página.
NOTE
Tenga cuidado al habilitar los tipos de referencia que aceptan valores NULL en un proyecto existente: las propiedades de tipo
de referencia que se configuraron anteriormente como opcional ahora se configurarán según sea necesario, a menos que se
anoten explícitamente para que acepten valores NULL. Al administrar un esquema de base de datos relacional, esto puede
provocar que se generen migraciones que modifiquen la nulabilidad de la columna de la base de datos.
DbContext y DbSet
Cuando se habilitan los tipos de referencia que C# aceptan valores NULL, el compilador emite advertencias para
cualquier propiedad no inicializada que no acepte valores NULL, ya que estos contendrían el valor null. Como
resultado, la práctica común de definir un DbSet que no acepta valores NULL en un contexto generará ahora una
advertencia. Sin embargo, EF Core siempre inicializa todas las propiedades DbSet en tipos derivados de
DbContext, por lo que se garantiza que nunca serán null, incluso si el compilador no es consciente de esto. Por lo
tanto, se recomienda mantener las propiedades de DbSet que no admitan valores NULL, lo que le permite tener
acceso a ellas sin comprobaciones nulas, y para silenciar las advertencias del compilador estableciéndolo
explícitamente en NULL con la ayuda del operador null-permisivo (!):
public class NullableReferenceTypesContext : DbContext

{
public DbSet<Customer> Customers { get; set; } = null!;
public DbSet<Order> Orders { get; set; } = null!;

=> optionsBuilder
.UseSqlServer(@"Server=
(localdb)\mssqllocaldb;Database=EFNullableReferenceTypes;Trusted_Connection=True;ConnectRetryCount=0");
}
Propiedades y inicialización que no aceptan valores NULL

Las advertencias del compilador para los tipos de referencia no inicializados que no aceptan valores null también
son un problema para las propiedades normales en los tipos de entidad. En el ejemplo anterior, se han evitado
estas advertencias mediante el enlace de constructor, una característica que funciona perfectamente con
propiedades que no aceptan valores NULL, lo que garantiza que siempre se inicializan. Sin embargo, en algunos
escenarios, el enlace del constructor no es una opción: las propiedades de navegación, por ejemplo, no se pueden
inicializar de esta manera.
Las propiedades de navegación requeridas presentan una dificultad adicional: aunque un dependiente siempre
existirá para una entidad de seguridad determinada, se puede cargar o no mediante una consulta determinada,
dependiendo de las necesidades en ese punto del programa (vea los distintos patrones para cargar datos). Al
mismo tiempo, no es deseable que estas propiedades acepten valores NULL, ya que esto obligaría a tener acceso a
ellas para comprobar si son NULL, incluso aunque se requieran.
Una manera de tratar estos escenarios consiste en tener una propiedad que no acepte valores NULL con un campo
de respaldoque acepte valores NULL:
private Address? _shippingAddress;
public Address ShippingAddress

{
set => _shippingAddress = value;
get => _shippingAddress
?? throw new InvalidOperationException("Uninitialized property: " + nameof(ShippingAddress));
}
Dado que la propiedad de navegación no admite valores NULL, se configura una navegación necesaria. y, siempre
y cuando la navegación se haya cargado correctamente, se podrá acceder al dependiente a través de la propiedad.
Sin embargo, si se tiene acceso a la propiedad sin cargar primero la entidad relacionada correctamente, se inicia
una excepción InvalidOperationException, ya que el contrato de la API se ha utilizado incorrectamente. Tenga en
cuenta que EF debe configurarse para tener acceso siempre al campo de respaldo y no a la propiedad, ya que se
basa en poder leer el valor aunque no se haya establecido. Consulte la documentación sobre los campos de
respaldo para ver cómo hacerlo y considere la posibilidad de especificar PropertyAccessMode.Field para
asegurarse de que la configuración es correcta.
Como alternativa de terser, es posible simplemente inicializar la propiedad en NULL con la ayuda del operador
null-permisivo (!):
public Product Product { get; set; } = null!;
Nunca se observará un valor nulo real excepto como resultado de un error de programación, por ejemplo, el
acceso a la propiedad de navegación sin cargar correctamente la entidad relacionada.
NOTE
Las navegaciones de colección, que contienen referencias a varias entidades relacionadas, siempre deben ser no NULL. Una
colección vacía significa que no existe ninguna entidad relacionada, pero la propia lista nunca debe ser null.
Navegar y incluir relaciones que aceptan valores NULL

Cuando se trabaja con relaciones opcionales, es posible encontrar advertencias del compilador en las que una
excepción de referencia nula real sería imposible. Cuando se traducen y ejecutan las consultas LINQ, EF Core
garantiza que si no existe una entidad relacionada opcional, cualquier navegación a ella simplemente se omitirá,
en lugar de producirse. Sin embargo, el compilador no es consciente de esta garantía EF Core y genera
advertencias como si la consulta LINQ se ejecutara en memoria, con LINQ to Objects. Como resultado, es
necesario usar el operador null-permisivo (!) para notificar al compilador que no es posible un valor null real:
Console.WriteLine(order.OptionalInfo!.ExtraAdditionalInfo!.SomeExtraAdditionalInfo);
Se produce un problema similar al incluir varios niveles de relaciones entre las navegaciones opcionales:
var order = context.Orders

.Include(o => o.OptionalInfo!)
.ThenInclude(op => op.ExtraAdditionalInfo)
.Single();
Si tiene que hacer esto mucho y los tipos de entidad en cuestión son principalmente (o exclusivamente) usados en
consultas de EF Core, considere la posibilidad de hacer que las propiedades de navegación no acepten valores
NULL y configurarlas como opcionales a través de la API fluida o las anotaciones de datos. Esto quitará todas las
advertencias del compilador manteniendo la relación opcional; sin embargo, si las entidades se recorren fuera de
EF Core, puede observar valores NULL, aunque las propiedades se anotan como que no aceptan valores NULL.
Limitaciones
La ingeniería inversa no admite C# C# actualmente 8 tipos de referencia que aceptan valores NULL (NRTs): EF
Core siempre genera código que supone que la característica está desactivada. Por ejemplo, las columnas de
texto que aceptan valores NULL se scaffolding como una propiedad con el tipo string , no string? , con la API
fluida o las anotaciones de datos que se usan para configurar si una propiedad es obligatoria o no. Puede editar
el código con scaffolding y reemplazarlo con anotaciones de C# nulabilidad. El seguimiento de la
compatibilidad con scaffolding para tipos de referencia que aceptan valores NULL se realiza mediante el
problema #15520.
La superficie de la API pública de EF Core todavía no se ha anotado para la nulabilidad (la API pública es "null-
desconocen"), lo que a veces es difícil de usar cuando la característica NRT está activada. Esto incluye
principalmente los operadores Async LINQ expuestos por EF Core, como FirstOrDefaultAsync. Tenemos
previsto abordar esto para la versión 5,0.
Creación y configuración de un modelo
Entity Framework usa un conjunto de convenciones para compilar un modelo basado en la forma de las clases de
entidad. Puede especificar una configuración adicional para complementar o reemplazar lo que se ha detectado
por convención.
Este artículo trata de la configuración que se puede aplicar a un modelo para cualquier almacén de datos y que se
puede aplicar al elegir como destino cualquier base de datos relacional. Los proveedores también pueden habilitar
la configuración específica de un almacén de datos determinado. Para obtener documentación sobre la
configuración específica del proveedor, vea la sección Proveedores de bases de datos .
TIP
Uso de la API fluida para configurar un modelo

Puede reemplazar el método OnModelCreating del contexto derivado y usar ModelBuilder API para configurar el
modelo. Este es el método más eficaz de configuración y permite especificar la configuración sin modificar las
clases de entidad. La configuración de API fluida tiene la prioridad más alta y reemplaza las anotaciones de datos y
las convenciones.
namespace EFModeling.FluentAPI.Required
{
class MyContext : DbContext
{
#region Required
{
modelBuilder.Entity<Blog>()
.Property(b => b.Url)
.IsRequired();
}
#endregion
}
public class Blog

{
}
}
Uso de anotaciones de datos para configurar un modelo

También puede aplicar atributos (conocidos como anotaciones de datos) a las clases y las propiedades. Las
anotaciones de datos reemplazarán a las convenciones, pero la configuración de la API fluida también las
reemplazará.
using System.ComponentModel.DataAnnotations;
namespace EFModeling.DataAnnotations.Required
{
{
}
#region Required
public class Blog
{
[Required]
}
#endregion
}
Tipos de entidad
La inclusión de un DbSet de un tipo en el contexto significa que se incluye en el modelo de EF Core. normalmente
hacemos referencia a este tipo como una entidad. EF Core puede leer y escribir instancias de entidad desde y hacia
la base de datos, y si está utilizando una base de datos relacional, EF Core puede crear tablas para las entidades a
través de migraciones.
Incluir tipos en el modelo

Por Convención, los tipos que se exponen en las propiedades de DbSet en el contexto se incluyen en el modelo
como entidades. También se incluyen los tipos de entidad que se especifican en el método OnModelCreating , al igual
que los tipos que se encuentran al explorar de forma recursiva las propiedades de navegación de otros tipos de
entidades detectadas.
En el ejemplo de código siguiente, se incluyen todos los tipos:
Blog se incluye porque se expone en una propiedad DbSet en el contexto.
Post se incluye porque se detecta a través de la propiedad de navegación Blog.Posts .
AuditEntry porque se especifica en OnModelCreating .

{

{
modelBuilder.Entity<AuditEntry>();
}
}
public class Blog

{

}
public class Post

{

}
public class AuditEntry

{
public int AuditEntryId { get; set; }
public string Username { get; set; }
public string Action { get; set; }
}
Excluir tipos del modelo
Si no desea incluir un tipo en el modelo, puede excluirlo:
API fluida
[NotMapped]
public class BlogMetadata
{
public DateTime LoadedFromDatabase { get; set; }
}
Nombre de la tabla
Por Convención, cada tipo de entidad se configurará para asignarse a una tabla de base de datos con el mismo
nombre que la propiedad DbSet que expone la entidad. Si no existe ningún DbSet para la entidad especificada, se
utiliza el nombre de clase.
Puede configurar manualmente el nombre de la tabla:
API fluida
[Table("blogs")]
public class Blog
{
}
Esquema de tabla
Al utilizar una base de datos relacional, las tablas se crean por Convención en el esquema predeterminado de la
base de datos. Por ejemplo, Microsoft SQL Server usará el esquema de dbo (SQLite no admite esquemas).
Puede configurar las tablas que se van a crear en un esquema específico de la siguiente manera:
API fluida
[Table("blogs", Schema = "blogging")]

public class Blog
{
}
En lugar de especificar el esquema de cada tabla, también puede definir el esquema predeterminado en el nivel de
modelo con la API fluida:

{
modelBuilder.HasDefaultSchema("blogging");
}
Tenga en cuenta que al establecer el esquema predeterminado también se verán afectados otros objetos de base de
datos, como las secuencias.
Propiedades de entidad
Cada tipo de entidad del modelo tiene un conjunto de propiedades, que EF Core leerán y escribirán en la base de
datos. Si utiliza una base de datos relacional, las propiedades de entidad se asignan a las columnas de la tabla.
Propiedades incluidas y excluidas

Por Convención, todas las propiedades públicas con un captador y un establecedor se incluirán en el modelo.
Las propiedades específicas se pueden excluir de la manera siguiente:
API fluida
public class Blog

{
[NotMapped]
public DateTime LoadedFromDatabase { get; set; }
}
Nombres de columna
Por Convención, cuando se utiliza una base de datos relacional, las propiedades de entidad se asignan a las
columnas de la tabla que tienen el mismo nombre que la propiedad.
Si prefiere configurar las columnas con nombres diferentes, puede hacerlo de la siguiente manera:
API fluida
public class Blog

{
[Column("blog_id")]
}
Tipos de datos de columna

Al utilizar una base de datos relacional, el proveedor de base de datos selecciona un tipo de datos basado en el tipo
.NET de la propiedad. También tiene en cuenta otros metadatos, como la longitud máximaconfigurada, si la
propiedad forma parte de una clave principal, etc.
Por ejemplo, SQL Server asigna propiedades de DateTime a columnas de datetime2(7) y string propiedades a
nvarchar(max) columnas (o a nvarchar(450) para propiedades que se utilizan como clave).
También puede configurar las columnas para especificar un tipo de datos exacto para una columna. Por ejemplo, el
código siguiente configura Url como una cadena no Unicode con una longitud máxima de 200 y Rating como
decimal con precisión de 5 y la escala de 2 :
API fluida
public class Blog

{
[Column(TypeName = "varchar(200)")]
[Column(TypeName = "decimal(5, 2)")]
public decimal Rating { get; set; }
}
Longitud máxima
La configuración de una longitud máxima proporciona una sugerencia al proveedor de base de datos sobre el tipo
de datos de columna adecuado que se debe elegir para una propiedad determinada. La longitud máxima solo se
aplica a los tipos de datos de matriz, como string y byte[] .
NOTE
Entity Framework no realiza ninguna validación de la longitud máxima antes de pasar datos al proveedor. Depende del
proveedor o del almacén de datos que se valide si es necesario. Por ejemplo, cuando el destino es SQL Server, si se supera la
longitud máxima, se producirá una excepción, ya que el tipo de datos de la columna subyacente no permitirá que se
almacenen los datos sobrantes.
En el ejemplo siguiente, la configuración de una longitud máxima de 500 hará que se cree una columna de tipo
nvarchar(500) en SQL Server:
API fluida
public class Blog

{
[MaxLength(500)]
}
Propiedades obligatorias y opcionales

Una propiedad se considera opcional si es válida para que contenga null . Si null no es un valor válido que se va
a asignar a una propiedad, se considera que es una propiedad obligatoria. Al asignar a un esquema de base de
datos relacional, las propiedades requeridas se crean como columnas que no aceptan valores NULL y las
propiedades opcionales se crean como columnas que aceptan valores NULL.
Convenciones
Por Convención, una propiedad cuyo tipo .NET pueda contener NULL se configurará como opcional, mientras que
las propiedades cuyo tipo .NET no puede contener valores NULL se configurarán según sea necesario. Por ejemplo,
todas las propiedades con tipos de valor .NET ( int , decimal , bool , etc.) se configuran según sea necesario y
todas las propiedades con tipos de valor .NET que aceptan valores NULL ( int? , decimal? , bool? , etc.) se
configuran como opcionales.
C#8 presentó una nueva característica denominada tipos de referencia que aceptan valores NULL, que permite
anotar tipos de referencia, lo que indica si es válido para que contengan null o not. Esta característica está
deshabilitada de forma predeterminada y, si está habilitada, modifica el comportamiento de EF Core de la siguiente
manera:
Si los tipos de referencia que aceptan valores NULL están deshabilitados (el valor predeterminado), todas las
propiedades con tipos de referencia de .NET se configuran como opcionales por Convención (por ejemplo,
string ).
Si los tipos de referencia que aceptan valores NULL están habilitados, las propiedades C# se configurarán en
función de la nulabilidad de su tipo .net: string? se configurarán como opcionales, mientras que string se
configurarán según sea necesario.
En el ejemplo siguiente se muestra un tipo de entidad con propiedades obligatorias y opcionales, con la
característica de referencia que acepta valores NULL deshabilitada (valor predeterminado) y habilitada:
Sin tipos de referencia que aceptan valores NULL (valor predeterminado)
Con tipos de referencia que aceptan valores NULL
public class CustomerWithoutNullableReferenceTypes

{
[Required] // Data annotations needed to configure as required
[Required]
public string LastName { get; set; } // Data annotations needed to configure as required
public string MiddleName { get; set; } // Optional by convention
}
Se recomienda el uso de tipos de referencia que aceptan valores NULL, ya que C# fluye la nulabilidad expresada en
el código para EF Core modelo y en la base de datos, e obvia el uso de las anotaciones de datos o la API fluida para
expresar el mismo concepto dos veces.
NOTE
Tenga cuidado al habilitar los tipos de referencia que aceptan valores NULL en un proyecto existente: las propiedades de tipo
de referencia que se configuraron anteriormente como opcional ahora se configurarán según sea necesario, a menos que se
anoten explícitamente para que acepten valores NULL. Al administrar un esquema de base de datos relacional, esto puede
provocar que se generen migraciones que modifiquen la nulabilidad de la columna de la base de datos.
Para obtener más información sobre los tipos de referencia que aceptan valores NULL y cómo usarlos con EF Core,
consulte la página de documentación dedicada para esta característica.
Configuración explícita
Una propiedad que sería opcional por Convención se puede configurar para que sea necesaria de la siguiente
manera:
API fluida
public class Blog

{
[Required]
}
Claves
Una clave actúa como identificador único para cada instancia de la entidad. La mayoría de las entidades de EF
tienen una sola clave, que se asigna al concepto de una clave principal en las bases de datos relacionales (para
entidades sin claves, vea entidadessin clave). Las entidades pueden tener claves adicionales más allá de la clave
principal (consulte claves alternativas para obtener más información).
Por Convención, una propiedad denominada Id o <type name>Id se configurará como la clave principal de una
entidad.
class Car
{
public string Make { get; set; }

public string Model { get; set; }
}
class Truck
{
public string TruckId { get; set; }

}
NOTE
Los tipos de entidad de propiedad usan reglas diferentes para definir claves.
Puede configurar una única propiedad para que sea la clave principal de una entidad, como se indica a
continuación:
API fluida
class Car
{
[Key]
public string LicensePlate { get; set; }

}
También puede configurar varias propiedades para que sean la clave de una entidad, lo que se conoce como clave
compuesta. Las claves compuestas solo se pueden configurar mediante la API fluida; las convenciones nunca
configurarán una clave compuesta y no se pueden usar anotaciones de datos para configurar una.
{
modelBuilder.Entity<Car>()
.HasKey(c => new { c.State, c.LicensePlate });
}
Nombre de clave principal

Por Convención, en las bases de datos relacionales se crean claves principales con el nombre PK_<type name> .
Puede configurar el nombre de la restricción Primary Key de la manera siguiente:

{
.HasKey(b => b.BlogId)
.HasName("PrimaryKey_BlogId");
}
Tipos de clave y valores

Aunque EF Core admite el uso de propiedades de cualquier tipo primitivo como clave principal, incluidos string ,
Guid , byte[] y otros, no todas las bases de datos admiten todos los tipos como claves. En algunos casos, los
valores de clave se pueden convertir automáticamente a un tipo compatible, de lo contrario, la conversión se debe
especificar manualmente.
Las propiedades de clave deben tener siempre un valor no predeterminado al agregar una nueva entidad al
contexto, pero la base de datos generaráalgunos tipos. En ese caso, EF intentará generar un valor temporal cuando
la entidad se agregue con fines de seguimiento. Después de llamar a SaveChanges , el valor temporal se
reemplazará por el valor generado por la base de datos.
IMPORTANT
Si una propiedad de clave tiene su valor generado por la base de datos y se especifica un valor no predeterminado al agregar
una entidad, EF asumirá que la entidad ya existe en la base de datos e intentará actualizarla en lugar de insertar una nueva.
Para evitar esto, desactive la generación de valores o vea Cómo especificar valores explícitos para las propiedades generadas.
Claves alternativas
Una clave alternativa actúa como identificador único alternativo para cada instancia de entidad además de la clave
principal; se puede usar como destino de una relación. Al utilizar una base de datos relacional, se asigna al concepto
de un índice o una restricción únicos en las columnas de clave alternativas y una o varias restricciones de clave
externa que hacen referencia a las columnas.
TIP
Si solo desea exigir la unicidad en una columna, defina un índice único en lugar de una clave alternativa (consulte índices). En
EF, las claves alternativas son de solo lectura y proporcionan una semántica adicional sobre índices únicos, ya que se pueden
usar como destino de una clave externa.
Normalmente, se introducen claves alternativas cuando sea necesario y no es necesario configurarlas

manualmente. Por Convención, se introduce una clave alternativa cuando se identifica una propiedad que no es la
clave principal como destino de una relación.
{

{
modelBuilder.Entity<Post>()
.HasOne(p => p.Blog)
.WithMany(b => b.Posts)
.HasForeignKey(p => p.BlogUrl)
.HasPrincipalKey(b => b.Url);
}
}
public class Blog

{

}
public class Post

{
public string BlogUrl { get; set; }

}
También puede configurar una sola propiedad para que sea una clave alternativa:

{
.HasAlternateKey(c => c.LicensePlate);
}
También puede configurar varias propiedades para que sean una clave alternativa (conocida como clave alternativa
compuesta):

{
.HasAlternateKey(c => new { c.State, c.LicensePlate });
}
Por último, por Convención, el índice y la restricción que se introducen para una clave alternativa se denominarán
AK_<type name>_<property name> (para las claves alternativas compuestas <property name> se convierte en una lista
de nombres de propiedad separados por un carácter de subrayado). Puede configurar el nombre del índice de la
clave alternativa y la restricción UNIQUE:
{
.HasAlternateKey(c => c.LicensePlate)
.HasName("AlternateKey_LicensePlate");
}
Valores generados
Patrones de generación de valores

Hay tres patrones de generación de valores que se pueden usar para las propiedades:
Sin generación de valores
Valor generado al agregar
Valor generado al agregar o actualizar
Ninguna generación de valores significa que siempre se proporcionará un valor válido que se va a guardar en la
base de datos. Este valor válido se debe asignar a las nuevas entidades antes de que se agreguen al contexto.
El valor generado al agregar significa que se genera un valor para las nuevas entidades.
Dependiendo del proveedor de base de datos que se use, es posible que se generen valores de cliente en EF o en
la base de datos. Si la base de datos genera el valor, EF puede asignar un valor temporal al agregar la entidad al
contexto. Este valor temporal se reemplazará por el valor generado por la base de datos durante la SaveChanges() .
Si agrega una entidad al contexto que tiene un valor asignado a la propiedad, EF intentará insertar ese valor en
lugar de generar uno nuevo. Se considera que una propiedad tiene un valor asignado si no se le asigna el valor
predeterminado de CLR ( null para string , 0 para int , Guid.Empty para Guid , etc.). Para obtener más
información, vea valores explícitos para las propiedades generadas.
WARNING
La forma en que se genera el valor para las entidades agregadas dependerá del proveedor de base de datos que se use. Los
proveedores de bases de datos pueden configurar automáticamente la generación de valores para algunos tipos de
propiedad, pero otros pueden requerir que se configure manualmente cómo se genera el valor.
Por ejemplo, al usar SQL Server, se generarán automáticamente valores para las propiedades de GUID (mediante el
algoritmo GUID secuencial SQL Server). Sin embargo, si especifica que se genere una propiedad DateTime en Add, debe
configurar una manera de que se generen los valores. Una manera de hacerlo es configurar un valor predeterminado de
GETDATE() , vea valores predeterminados.

El valor generado al agregar o actualizar significa que se genera un nuevo valor cada vez que se guarda el registro
(Insert o Update).
Como value generated on add , si especifica un valor para la propiedad en una instancia recién agregada de una
entidad, se insertará ese valor en lugar de un valor que se va a generar. También es posible establecer un valor
explícito al actualizar. Para obtener más información, vea valores explícitos para las propiedades generadas.
WARNING
La forma en que se genera el valor para las entidades agregadas y actualizadas dependerá del proveedor de base de datos
que se use. Los proveedores de bases de datos pueden configurar automáticamente la generación de valores para algunos
tipos de propiedades, mientras que otros requerirán que se configure manualmente cómo se genera el valor.
Por ejemplo, al usar SQL Server, byte[] propiedades que se establecen como se generan al agregar o actualizar y
marcadas como tokens de simultaneidad, se configurarán con el tipo de datos rowversion , de modo que los valores se
generarán en la base de datos. Sin embargo, si especifica que se genere una propiedad DateTime en Add o Update, debe
configurar una manera de que se generen los valores. Una forma de hacerlo consiste en configurar un valor predeterminado
de GETDATE() (vea valores predeterminados) para generar valores para las nuevas filas. Después, puede usar un
desencadenador de base de datos para generar valores durante las actualizaciones (como el siguiente desencadenador de
ejemplo).
CREATE TRIGGER [dbo].[Blogs_UPDATE] ON [dbo].[Blogs]

AFTER UPDATE
AS
BEGIN
SET NOCOUNT ON;
IF ((SELECT TRIGGER_NESTLEVEL()) > 1) RETURN;
DECLARE @Id INT
SELECT @Id = INSERTED.BlogId

FROM INSERTED
UPDATE dbo.Blogs
SET LastUpdated = GETDATE()
WHERE BlogId = @Id
END

Por Convención, las claves principales no compuestas de tipo Short, int, Long o GUID están configuradas para que
tengan valores generados para las entidades insertadas, si la aplicación no proporciona un valor. Normalmente, el
proveedor de base de datos se encarga de la configuración necesaria. por ejemplo, una clave principal numérica
en SQL Server se configura automáticamente para que sea una columna de identidad.
Puede configurar cualquier propiedad para que se genere su valor para las entidades insertadas como se indica a
continuación:
API fluida
public class Blog

{
[DatabaseGenerated(DatabaseGeneratedOption.Identity)]
public DateTime Inserted { get; set; }
}
WARNING
Esto solo permite que EF sepa que los valores se generan para las entidades agregadas, no garantiza que EF configurará el
mecanismo real para generar valores. Vea la sección valor generado al agregar para obtener más detalles.
Valores predeterminados
En las bases de datos relacionales, una columna se puede configurar con un valor predeterminado. Si se inserta
una fila sin un valor para esa columna, se usará el valor predeterminado.
Puede configurar un valor predeterminado en una propiedad:

{
.Property(b => b.Rating)
.HasDefaultValue(3);
}
También puede especificar un fragmento de SQL que se usa para calcular el valor predeterminado:

{
.Property(b => b.Created)
.HasDefaultValueSql("getdate()");
}
Si se especifica un valor predeterminado, se configurará implícitamente la propiedad como valor generado al

agregar.

API fluida
public class Blog

{
[DatabaseGenerated(DatabaseGeneratedOption.Computed)]
public DateTime LastUpdated { get; set; }
}
WARNING
Esto solo permite que EF sepa que se generan valores para entidades agregadas o actualizadas, no garantiza que EF
configure el mecanismo real para generar valores. Vea la sección valor generado al agregar o actualizar para obtener más
detalles.
Columnas calculadas
En algunas bases de datos relacionales, una columna se puede configurar para que se calcule su valor en la base
de datos, normalmente con una expresión que haga referencia a otras columnas:

{
modelBuilder.Entity<Person>()
.Property(p => p.DisplayName)
.HasComputedColumnSql("[LastName] + ', ' + [FirstName]");
}
NOTE
En algunos casos, el valor de la columna se calcula cada vez que se captura (a veces denominado columnas virtuales ) y en
otros se calcula en cada actualización de la fila y se almacena (a veces denominada columnas almacenadas o persistentes ).
Esto varía en los proveedores de bases de datos.

Normalmente, es necesario deshabilitar la generación de valores en una propiedad si una Convención la configura
para la generación de valores. Por ejemplo, si tiene una clave principal de tipo int, se establecerá implícitamente
configurada como valor generado al agregar; puede deshabilitarlo a través de lo siguiente:
API fluida
public class Blog

{
[DatabaseGenerated(DatabaseGeneratedOption.None)]
}
NOTE
En esta página se documenta cómo configurar los tokens de simultaneidad. Vea controlar los conflictos de simultaneidad
para obtener una explicación detallada de cómo funciona el control de simultaneidad en EF Core y ejemplos de cómo
controlar los conflictos de simultaneidad en la aplicación.
Las propiedades configuradas como tokens de simultaneidad se usan para implementar el control de
simultaneidad optimista.
Configuración
API fluida
public class Person

{
public int PersonId { get; set; }
[ConcurrencyCheck]

}
Marca de tiempo/rowversion
Timestamp/rowversion es una propiedad para la cual la base de datos genera automáticamente un nuevo valor
cada vez que se inserta o se actualiza una fila. La propiedad también se trata como un token de simultaneidad, lo
que garantiza que se obtiene una excepción si una fila que se está actualizando ha cambiado desde que se realizó
la consulta. Los detalles precisos dependen del proveedor de base de datos utilizado; por SQL Server, normalmente
se utiliza una propiedad Byte [] , que se configurará como una columna ROWVERSION en la base de datos.
Puede configurar una propiedad para que sea una marca de tiempo o rowversion como se indica a continuación:
API fluida
public class Blog

{
[Timestamp]
public byte[] Timestamp { get; set; }
}
Propiedades reemplazadas
Las propiedades de sombra son propiedades que no están definidas en la clase de entidad de .NET pero que se
definen para ese tipo de entidad en el modelo de EF Core. El valor y el estado de estas propiedades se mantienen
únicamente en el seguimiento de cambios. Las propiedades Shadow son útiles cuando hay datos en la base de
datos que no se deben exponer en los tipos de entidad asignados.
Propiedades de sombra de clave externa

Las propiedades de sombra se utilizan con más frecuencia para las propiedades de clave externa, donde la
relación entre dos entidades se representa mediante un valor de clave externa en la base de datos, pero la
relación se administra en los tipos de entidad mediante las propiedades de navegación entre la entidad. distintos.
Por Convención, EF introducirá una propiedad Shadow cuando se detecte una relación, pero no se encuentra
ninguna propiedad de clave externa en la clase de entidad dependiente.
La propiedad se denominará <navigation property name><principal key property name> (la navegación en la
entidad dependiente, que apunta a la entidad principal, se usa para la nomenclatura). Si el nombre de la
propiedad de clave principal incluye el nombre de la propiedad de navegación, el nombre simplemente se
<principal key property name> . Si no hay ninguna propiedad de navegación en la entidad dependiente, el
nombre del tipo de entidad de seguridad se usa en su lugar.
Por ejemplo, la siguiente lista de código dará como resultado la inclusión de una BlogId propiedad Shadow en la
entidad Post :

{
}
public class Blog

{

}
public class Post

{
// Since there is no CLR property which holds the foreign

// key for this relationship, a shadow property is created.
}
Configurar propiedades de instantáneas

Puede usar la API fluida para configurar las propiedades de las instantáneas. Una vez que haya llamado a la
sobrecarga de la cadena de Property , puede encadenar cualquiera de las llamadas de configuración que desee
para otras propiedades. En el ejemplo siguiente, puesto que Blog no tiene ninguna propiedad CLR denominada
LastUpdated , se crea una propiedad Shadow:

{

{
.Property<DateTime>("LastUpdated");
}
}
public class Blog

{
}
Si el nombre proporcionado al método Property coincide con el nombre de una propiedad existente (una
propiedad Shadow o una definida en la clase de entidad), el código configurará esa propiedad existente en lugar
de introducir una nueva propiedad Shadow.
Obtener acceso a las propiedades de sombra

Los valores de las propiedades Shadow se pueden obtener y cambiar a través de la API de ChangeTracker :
context.Entry(myBlog).Property("LastUpdated").CurrentValue = DateTime.Now;
Se puede hacer referencia a las propiedades Shadow en consultas LINQ a través del método estático
EF.Property :
var blogs = context.Blogs

.OrderBy(b => EF.Property<DateTime>(b, "LastUpdated"));
Relaciones
Una relación define el modo en que dos entidades se relacionan entre sí. En una base de datos relacional, se
representa mediante una restricción FOREIGN KEY.
NOTE
La mayoría de los ejemplos de este artículo usan una relación de uno a varios para demostrar los conceptos. Para obtener
ejemplos de relaciones de uno a uno y de varios a varios, consulte la sección otros patrones de relación al final del artículo.
Definición de términos
Hay una serie de términos que se usan para describir las relaciones
Entidad dependiente: Esta es la entidad que contiene las propiedades de clave externa. A veces se conoce
como "secundario" de la relación.
Entidad de entidad de seguridad: Esta es la entidad que contiene las propiedades de clave
principal/alternativa. A veces se denomina "primario" de la relación.
Clave principal: Propiedades que identifican de forma única la entidad principal. Puede ser la clave
principal o una clave alternativa.
Clave externa: Propiedades de la entidad dependiente que se usan para almacenar los valores de clave
principal para la entidad relacionada.
Propiedad de navegación: Propiedad definida en la entidad principal o dependiente que hace referencia a
la entidad relacionada.
Propiedad de navegación de colección: Propiedad de navegación que contiene referencias a
muchas entidades relacionadas.
Propiedad de navegación de referencia: Propiedad de navegación que contiene una referencia a
una sola entidad relacionada.
Propiedad de navegación inversa: Al discutir una propiedad de navegación determinada, este
término hace referencia a la propiedad de navegación en el otro extremo de la relación.
Relación que hace referencia a sí misma: Una relación en la que los tipos de entidad dependiente y
principal son iguales.
En el código siguiente se muestra una relación de uno a varios entre Blog y Post
public class Blog
{

}
public class Post

{

}
Post es la entidad dependiente

Blog es la entidad principal
Blog.BlogId es la clave principal (en este caso, es una clave principal en lugar de una clave alternativa)
Post.BlogId es la clave externa
Post.Blog es una propiedad de navegación de referencia
Blog.Posts es una propiedad de navegación de colección
Post.Blog es la propiedad de navegación inversa de Blog.Posts (y viceversa)
Convenciones
De forma predeterminada, se creará una relación cuando se detecte una propiedad de navegación en un tipo. Una
propiedad se considera una propiedad de navegación si el tipo al que señala no se puede asignar como un tipo
escalar por el proveedor de base de datos actual.
NOTE
Las relaciones detectadas por la Convención siempre tendrán como destino la clave principal de la entidad principal. Para
elegir como destino una clave alternativa, se debe realizar una configuración adicional mediante la API fluida.
Relaciones totalmente definidas

El patrón más común para las relaciones es tener propiedades de navegación definidas en ambos extremos de la
relación y una propiedad de clave externa definida en la clase de entidad dependiente.
Si se encuentra un par de propiedades de navegación entre dos tipos, se configurarán como propiedades de
navegación inversa de la misma relación.
Si la entidad dependiente contiene una propiedad con un nombre que coincide con uno de estos patrones,
se configurará como la clave externa:
<navigation property name><principal key property name>
<navigation property name>Id
<principal entity name><principal key property name>
<principal entity name>Id
public class Blog
{

}
public class Post

{

}
En este ejemplo, las propiedades resaltadas se usarán para configurar la relación.
NOTE
Si la propiedad es la clave principal o es de un tipo no compatible con la clave principal, no se configurará como clave externa.
NOTE
Antes de EF Core 3,0 la propiedad denominada exactamente igual que la propiedad de clave principal también coincidía con la
clave externa .
No hay propiedad de clave externa

Aunque se recomienda tener una propiedad de clave externa definida en la clase de entidad dependiente, no es
necesario. Si no se encuentra ninguna propiedad de clave externa, se introducirá una propiedad de clave externa de
sombra con el nombre <navigation property name><principal key property name> o
<principal entity name><principal key property name> si no hay ninguna navegación presente en el tipo
dependiente.
public class Blog

{

}
public class Post

{

}
En este ejemplo, la clave externa de la sombra se BlogId porque, si se antepone el nombre de navegación, sería
redundante.
NOTE
Si ya existe una propiedad con el mismo nombre, el nombre de la propiedad Shadow tendrá como sufijo un número.
Propiedad de navegación única

Incluir solo una propiedad de navegación (sin navegación inversa y sin propiedad de clave externa) es suficiente
para tener una relación definida por Convención. También puede tener una propiedad de navegación única y una
propiedad de clave externa.
public class Blog

{

}
public class Post

{
}
Limitaciones
Cuando hay varias propiedades de navegación definidas entre dos tipos (es decir, más de un par de navegaciones
que apuntan entre sí), las relaciones representadas por las propiedades de navegación son ambiguas. Tendrá que
configurarlos manualmente para resolver la ambigüedad.
Por Convención, la eliminación en cascada se establecerá en Cascade para las relaciones necesarias y ClientSetNull
para las relaciones opcionales. Cascade significa que las entidades dependientes también se eliminan. ClientSetNull
significa que las entidades dependientes que no se cargan en la memoria permanecerán sin cambios y deben
eliminarse manualmente o actualizarse para que apunten a una entidad principal válida. En el caso de las entidades
que se cargan en memoria, EF Core intentará establecer las propiedades de clave externa en NULL.
Vea la sección relaciones obligatorias y opcionales para ver la diferencia entre las relaciones obligatorias y
opcionales.
Consulte eliminación en cascada para obtener más detalles sobre los distintos comportamientos de eliminación y
los valores predeterminados que usa la Convención.
Configuración manual
API fluida
Para configurar una relación en la API fluida, empiece por identificar las propiedades de navegación que componen
la relación. HasOne o HasMany identifica la propiedad de navegación en el tipo de entidad en el que se está
iniciando la configuración. A continuación, encadenar una llamada a WithOne o WithMany para identificar la
navegación inversa. HasOne / WithOne se utilizan para las propiedades de navegación de referencia y HasMany /
WithMany se utilizan para las propiedades de navegación de la colección.
{

{
.WithMany(b => b.Posts);
}
}
public class Blog

{

}
public class Post

{

}
Propiedad de navegación única

Si solo tiene una propiedad de navegación, hay sobrecargas sin parámetros de WithOne y WithMany . Esto indica
que hay conceptualmente una referencia o una colección en el otro extremo de la relación, pero no hay ninguna
propiedad de navegación incluida en la clase de entidad.

{

{
.HasMany(b => b.Posts)
.WithOne();
}
}
public class Blog

{

}
public class Post

{
}
Clave externa
API fluida (clave simple)
API fluida (clave compuesta)
Anotaciones de datos (clave simple)
Puede usar la API fluida para configurar qué propiedad se debe usar como la propiedad de clave externa para una
relación determinada:

{

{
.HasForeignKey(p => p.BlogForeignKey);
}
}
public class Blog

{

}
public class Post

{
public int BlogForeignKey { get; set; }

}
Clave externa de sombra

Puede usar la sobrecarga de cadena de HasForeignKey(...) para configurar una propiedad Shadow como clave
externa (consulte propiedades de sombra para obtener más información). Se recomienda agregar explícitamente la
propiedad Shadow al modelo antes de usarla como clave externa (como se muestra a continuación).
{

{
// Add the shadow property to the model
.Property<int>("BlogForeignKey");
// Use the shadow property as a foreign key

.HasForeignKey("BlogForeignKey");
}
}
public class Blog

{

}
public class Post

{

}
Nombre de restricción de clave externa

Por Convención, cuando el destino es una base de datos relacional, las restricciones Foreign Key se denominan FK_ .
En el caso de las claves externas compuestas se convierte en una lista de nombres de propiedades de clave externa
separadas por guiones bajos.
También puede configurar el nombre de la restricción de la siguiente manera:

{
.HasForeignKey(p => p.BlogId)
.HasConstraintName("ForeignKey_Post_Blog");
}
Sin propiedad de navegación

No es necesario proporcionar una propiedad de navegación. Simplemente puede proporcionar una clave externa
en un lado de la relación.
{

{
.HasOne<Blog>()
.WithMany()
.HasForeignKey(p => p.BlogId);
}
}
public class Blog

{
}
public class Post

{

}
Clave principal
Si desea que la clave externa haga referencia a una propiedad que no sea la clave principal, puede usar la API fluida
para configurar la propiedad de clave principal de la relación. La propiedad que se configura como clave principal
se configurará automáticamente como una clave alternativa.
Clave simple
Clave compuesta
{
public DbSet<Car> Cars { get; set; }

{
modelBuilder.Entity<RecordOfSale>()
.HasOne(s => s.Car)
.WithMany(c => c.SaleHistory)
.HasForeignKey(s => s.CarLicensePlate)
.HasPrincipalKey(c => c.LicensePlate);
}
}
public class Car

{
public int CarId { get; set; }
public string LicensePlate { get; set; }
public List<RecordOfSale> SaleHistory { get; set; }

}
public class RecordOfSale

{
public int RecordOfSaleId { get; set; }
public DateTime DateSold { get; set; }
public decimal Price { get; set; }
public string CarLicensePlate { get; set; }

public Car Car { get; set; }
}
Relaciones obligatorias y opcionales

Puede usar la API fluida para configurar si la relación es obligatoria u opcional. En última instancia, controla si la
propiedad de clave externa es obligatoria u opcional. Esto es muy útil cuando se usa una clave externa de estado de
sombra. Si tiene una propiedad de clave externa en la clase de entidad, la necesidad de la relación se determina en
función de si la propiedad de clave externa es necesaria u opcional (vea propiedades obligatorias y opcionales para
obtener más información).

{
.IsRequired();
}
NOTE
La llamada a IsRequired(false) también hace que la propiedad de clave externa sea opcional a menos que esté
configurada de otro modo.
Puede usar la API fluida para configurar explícitamente el comportamiento de eliminación en cascada para una
relación determinada.
Consulte la eliminación en cascada para obtener una explicación detallada de cada opción.
{
.OnDelete(DeleteBehavior.Cascade);
}
Otros patrones de relación

Uno a uno
Una relación de uno a uno tiene una propiedad de navegación de referencia en ambos lados. Siguen las mismas
convenciones que las relaciones uno a varios, pero se incluye un índice único en la propiedad de clave externa para
asegurarse de que solo un dependiente esté relacionado con cada entidad de seguridad.
public class Blog

{
public BlogImage BlogImage { get; set; }

}
public class BlogImage

{
public int BlogImageId { get; set; }
public byte[] Image { get; set; }
public string Caption { get; set; }

}
NOTE
EF elegirá una de las entidades como dependiente en función de su capacidad para detectar una propiedad de clave externa.
Si se elige la entidad equivocada como dependiente, puede usar la API fluida para corregir este problema.
Al configurar la relación con la API fluida, se usan los métodos HasOne y WithOne .
Al configurar la clave externa, debe especificar el tipo de entidad dependiente: Observe que el parámetro genérico
proporcionado a HasForeignKey en la siguiente lista. En una relación uno a varios, es evidente que la entidad con la
navegación de referencia es el dependiente y el que tiene la colección es la entidad de seguridad. Pero esto no es
así en una relación uno a uno; por lo tanto, la necesidad de definirla explícitamente.
{
public DbSet<BlogImage> BlogImages { get; set; }

{
.HasOne(b => b.BlogImage)
.WithOne(i => i.Blog)
.HasForeignKey<BlogImage>(b => b.BlogForeignKey);
}
}
public class Blog

{
public BlogImage BlogImage { get; set; }

}
public class BlogImage

{
public int BlogImageId { get; set; }
public byte[] Image { get; set; }
public string Caption { get; set; }
public int BlogForeignKey { get; set; }

}
Varios a varios
Todavía no se admiten las relaciones de varios a varios sin una clase de entidad para representar la tabla de
combinación. Sin embargo, puede representar una relación de varios a varios incluyendo una clase de entidad para
la tabla de combinación y asignando dos relaciones uno a varios independientes.
{
public DbSet<Tag> Tags { get; set; }

{
modelBuilder.Entity<PostTag>()
.HasKey(t => new { t.PostId, t.TagId });
.HasOne(pt => pt.Post)
.WithMany(p => p.PostTags)
.HasForeignKey(pt => pt.PostId);
.HasOne(pt => pt.Tag)
.WithMany(t => t.PostTags)
.HasForeignKey(pt => pt.TagId);
}
}
public class Post

{
public List<PostTag> PostTags { get; set; }

}
public class Tag

{
public string TagId { get; set; }
public List<PostTag> PostTags { get; set; }

}
public class PostTag

{
public Post Post { get; set; }
public string TagId { get; set; }

public Tag Tag { get; set; }
}
Índices
Los índices son un concepto común en muchos almacenes de datos. Aunque su implementación en el almacén de
datos puede variar, se usan para realizar búsquedas basadas en una columna (o conjunto de columnas) más
eficaces.
Los índices no se pueden crear con anotaciones de datos. Puede usar la API fluida para especificar un índice en una
sola columna de la siguiente manera:

{
.HasIndex(b => b.Url);
}
También puede especificar un índice en más de una columna:

{
modelBuilder.Entity<Person>()
.HasIndex(p => new { p.FirstName, p.LastName });
}
NOTE
Por Convención, se crea un índice en cada propiedad (o conjunto de propiedades) que se usa como clave externa.
EF Core solo admite un índice por conjunto de propiedades distinto. Si usa la API fluida para configurar un índice en un
conjunto de propiedades que ya tiene definido un índice, ya sea por Convención o por configuración anterior, cambiará la
definición de ese índice. Esto resulta útil si desea seguir configurando un índice creado por la Convención.
Unicidad del índice

De forma predeterminada, los índices no son únicos: se permite que varias filas tengan los mismos valores para el
conjunto de columnas del índice. Puede crear un índice único como se indica a continuación:

{
.HasIndex(b => b.Url)
.IsUnique();
}
Si se intenta insertar más de una entidad con los mismos valores para el conjunto de columnas del índice, se
producirá una excepción.
Nombre del índice

Por Convención, los índices creados en una base de datos relacional se denominan
IX_<type name>_<property name> . En el caso de los índices compuestos, <property name> se convierte en una lista
de nombres de propiedad separados por guiones bajos.
Puede usar la API fluida para establecer el nombre del índice creado en la base de datos:

{
.HasName("Index_Url");
}
Filtro de índice
Algunas bases de datos relacionales permiten especificar un índice parcial o filtrado. Esto permite indizar solo un
subconjunto de los valores de una columna, reduciendo el tamaño del índice y mejorando el rendimiento y el uso
del espacio en disco. Para obtener más información sobre SQL Server los índices filtrados, vea la
documentaciónde.
Puede usar la API fluida para especificar un filtro en un índice, proporcionado como una expresión SQL:

{
.HasFilter("[Url] IS NOT NULL");
}
Al usar el proveedor de SQL Server EF agrega un filtro de 'IS NOT NULL' para todas las columnas que aceptan
valores NULL que forman parte de un índice único. Para invalidar esta Convención, puede proporcionar un valor
null .

{
.IsUnique()
.HasFilter(null);
}
Columnas incluidas
Algunas bases de datos relacionales permiten configurar un conjunto de columnas que se incluyen en el índice,
pero que no forman parte de su "clave". Esto puede mejorar significativamente el rendimiento de las consultas
cuando todas las columnas de la consulta se incluyen en el índice como columnas de clave o sin clave, ya que no es
necesario tener acceso a la tabla en sí. Para obtener más información sobre SQL Server columnas incluidas, vea la
documentaciónde.
En el ejemplo siguiente, la columna Url forma parte de la clave de índice, por lo que cualquier filtrado de
consultas en esa columna puede utilizar el índice. Pero además, las consultas que solo tienen acceso a las columnas
Title y PublishedOn no tendrán que acceder a la tabla y se ejecutarán de forma más eficaz:
{
.HasIndex(p => p.Url)
.IncludeProperties(p => new
{
p.Title,
p.PublishedOn
});
}
Herencia
EF puede asignar una jerarquía de tipos .NET a una base de datos. Esto le permite escribir las entidades .NET en el
código como de costumbre, con los tipos base y derivados, y hacer que EF cree sin problemas el esquema de base
de datos adecuado, las consultas de problemas, etc. Los detalles reales de cómo se asigna una jerarquía de tipos
dependen del proveedor; en esta página se describe la compatibilidad de herencia en el contexto de una base de
datos relacional.
En este momento, EF Core solo admite el patrón de tabla por jerarquía (TPH). TPH usa una sola tabla para
almacenar los datos de todos los tipos de la jerarquía y se usa una columna de discriminador para identificar qué
tipo representa cada fila.
NOTE
Los EF Core no admiten la tabla por tipo (TPT) y la tabla por tipo específico (TPC), que son compatibles con EF6. TPT es una
característica importante planeada para EF Core 5,0.
Asignación de jerarquía de tipos de entidad

Por Convención, EF solo configurará la herencia si dos o más tipos heredados se incluyen explícitamente en el
modelo. EF no buscará automáticamente tipos base o derivados que no se incluyan en el modelo de otra forma.
Puede incluir tipos en el modelo exponiendo un DbSet para cada tipo en la jerarquía de herencia:

{
public DbSet<RssBlog> RssBlogs { get; set; }
}
public class Blog

{
}
public class RssBlog : Blog

{
public string RssUrl { get; set; }
}
Este modelo se asignará al siguiente esquema de la base de datos (tenga en cuenta la columna discriminada
creada implícitamente, que identifica qué tipo de blog se almacena en cada fila):
NOTE
Las columnas de la base de datos se convierten en NULL automáticamente según sea necesario al usar la asignación TPH.
Por ejemplo, la columna RssUrl admite valores NULL porque las instancias de blog normales no tienen esa propiedad.
Si no desea exponer un DbSet para una o varias entidades de la jerarquía, también puede usar la API fluida para
asegurarse de que se incluyen en el modelo.
TIP
Si no se basa en las convenciones, puede especificar explícitamente el tipo base mediante HasBaseType . También puede usar
.HasBaseType((Type)null) para quitar un tipo de entidad de la jerarquía.
Configuración de discriminador
Puede configurar el nombre y el tipo de la columna discriminadora y los valores que se usan para identificar cada
tipo en la jerarquía:

{
.HasDiscriminator<string>("blog_type")
.HasValue<Blog>("blog_base")
.HasValue<RssBlog>("blog_rss");
}
En los ejemplos anteriores, EF agregó el discriminador implícitamente como una propiedad Shadow en la entidad
base de la jerarquía. Esta propiedad se puede configurar como cualquier otra:

{
.Property("Discriminator")
.HasMaxLength(200);
}
Por último, el discriminador también se puede asignar a una propiedad .NET normal en la entidad:

{
.HasDiscriminator(b => b.BlogType);
.Property(e => e.BlogType)
.HasMaxLength(200)
.HasColumnName("blog_type");
}
Columnas compartidas
De forma predeterminada, cuando dos tipos de entidad del mismo nivel en la jerarquía tienen una propiedad con
el mismo nombre, se asignarán a dos columnas independientes. Sin embargo, si su tipo es idéntico, se pueden
asignar a la misma columna de base de datos:
public class MyContext : DbContext
{
public DbSet<BlogBase> Blogs { get; set; }

{
.HasColumnName("Url");
modelBuilder.Entity<RssBlog>()
.HasColumnName("Url");
}
}
public abstract class BlogBase

{
}
public class Blog : BlogBase

{
}
public class RssBlog : BlogBase

{
}
Secuencias
NOTE
Las secuencias son una característica que normalmente solo admiten las bases de datos relacionales. Si utiliza una base de
datos no relacional como Cosmos, consulte la documentación de la base de datos para generar valores únicos.
Una secuencia genera valores numéricos únicos y secuenciales en la base de datos. Las secuencias no están
asociadas a una tabla específica y se pueden configurar varias tablas para que dibujen valores de la misma
secuencia.
Uso básico
Puede configurar una secuencia en el modelo y, a continuación, utilizarla para generar valores para las propiedades:

{
modelBuilder.HasSequence<int>("OrderNumbers");
.Property(o => o.OrderNo)
.HasDefaultValueSql("NEXT VALUE FOR shared.OrderNumbers");
}
Tenga en cuenta que el SQL específico que se usa para generar un valor a partir de una secuencia es específico de
la base de datos; el ejemplo anterior funciona en SQL Server pero producirá un error en otras bases de datos.
Consulte la documentación específica de su base de datos para obtener más información.
Configuración de las opciones de secuencia

También puede configurar aspectos adicionales de la secuencia, como su esquema, valor inicial, incremento, etc.:

{
modelBuilder.HasSequence<int>("OrderNumbers", schema: "shared")
.StartsAt(1000)
.IncrementsBy(5);
}
Campos de respaldo
Los campos de respaldo permiten a EF leer o escribir en un campo en lugar de una propiedad. Esto puede ser útil
cuando se usa la encapsulación en la clase para restringir el uso de y/o mejorar la semántica en torno al acceso a
los datos por código de aplicación, pero el valor debe leerse o escribirse en la base de datos sin usar esas
restricciones o mejoras.
Configuración básica
Por Convención, se detectarán los campos siguientes como campos de respaldo para una propiedad determinada
(que se muestra en orden de prioridad).
_<camel-cased property name>
_<property name>
m_<camel-cased property name>
m_<property name>
En el ejemplo siguiente, la propiedad Url está configurada para tener _url como campo de respaldo:
public class Blog

{
private string _url;
public string Url

{
get { return _url; }
set { _url = value; }
}
}
Tenga en cuenta que los campos de respaldo solo se detectan para las propiedades que se incluyen en el modelo.
Para obtener más información sobre las propiedades que se incluyen en el modelo, vea incluir & excluyendo las
propiedades.
También puede configurar los campos de respaldo explícitamente, por ejemplo, si el nombre del campo no se
corresponde con las convenciones anteriores:

{
.HasField("_validatedUrl");
}
Acceso a campos y propiedades

De forma predeterminada, EF siempre leerá y escribirá en el campo de respaldo, suponiendo que se haya
configurado correctamente, y que nunca usará la propiedad. Sin embargo, EF también admite otros patrones de
acceso. Por ejemplo, en el ejemplo siguiente se indica a EF que escriba en el campo de respaldo solo mientras
materializa y use la propiedad en todos los demás casos:

{
.HasField("_validatedUrl")
.UsePropertyAccessMode(PropertyAccessMode.PreferFieldDuringConstruction);
}
Vea la enumeración PropertyAccessMode para obtener el conjunto completo de opciones admitidas.
NOTE
Con EF Core 3,0, el modo de acceso de propiedad predeterminado cambió de PreferFieldDuringConstruction a
PreferField .
Propiedades de solo campo

También puede crear una propiedad conceptual en el modelo que no tiene una propiedad de CLR correspondiente
en la clase de entidad, sino que usa un campo para almacenar los datos en la entidad. Esto es diferente de las
propiedades de las instantáneas, donde los datos se almacenan en el seguimiento de cambios, en lugar de en el
tipo CLR de la entidad. Las propiedades de solo campo se utilizan normalmente cuando la clase de entidad usa
métodos en lugar de propiedades para obtener o establecer valores, o en casos en los que los campos no se
deben exponer en absoluto en el modelo de dominio (por ejemplo, las claves principales).
Puede configurar una propiedad de solo campo proporcionando un nombre en la API de Property(...) :
{

{
.Property("_validatedUrl");
}
}
public class Blog

{
private string _validatedUrl;
public string GetUrl()

{
return _validatedUrl;
}
public void SetUrl(string url)

{
using (var client = new HttpClient())
{
var response = client.GetAsync(url).Result;
response.EnsureSuccessStatusCode();
}
_validatedUrl = url;
}
}
EF intentará buscar una propiedad CLR con el nombre especificado o un campo si no se encuentra una propiedad.
Si no se encuentra ninguna propiedad ni un campo, se configurará una propiedad Shadow en su lugar.
Es posible que tenga que hacer referencia a una propiedad de solo campo desde las consultas LINQ, pero estos
campos suelen ser privados. Puede usar el método EF.Property(...) en una consulta LINQ para hacer referencia
al campo:
var blogs = db.blogs.OrderBy(b => EF.Property<string>(b, "_validatedUrl"));

NOTE
Esta característica es nueva en EF Core 2.1.
Los convertidores de valores permiten convertir los valores de propiedad al leer o escribir en la base de datos.
Esta conversión puede ser de un valor a otro del mismo tipo (por ejemplo, cifrar cadenas) o de un valor de un
tipo a un valor de otro tipo (por ejemplo, convertir valores de enumeración en cadenas en la base de datos y
desde ellas).
Aspectos básicos
Los convertidores de valores se especifican en términos de un ModelClrType y un ProviderClrType . El tipo de
modelo es el tipo .NET de la propiedad en el tipo de entidad. El tipo de proveedor es el tipo .NET que entiende el
proveedor de base de datos. Por ejemplo, para guardar las enumeraciones como cadenas en la base de datos, el
tipo de modelo es el tipo de la enumeración y el tipo de proveedor es String . Estos dos tipos pueden ser iguales.
Las conversiones se definen utilizando dos Func árboles de expresión: uno de ModelClrType a ProviderClrType
y otro de ProviderClrType a ModelClrType . Los árboles de expresión se usan para que se puedan compilar en el
código de acceso a la base de datos para conversiones eficientes. En las conversiones complejas, el árbol de
expresión puede ser una llamada simple a un método que realiza la conversión.
Configurar un convertidor de valores

Las conversiones de valores se definen en las propiedades del OnModelCreating de la DbContext . Por ejemplo,
considere una enumeración y un tipo de entidad definidos como:
public class Rider

{
public EquineBeast Mount { get; set; }
}
public enum EquineBeast

{
Donkey,
Mule,
Horse,
Unicorn
}
A continuación, se pueden definir conversiones en OnModelCreating para almacenar los valores de enumeración
como cadenas (por ejemplo, "Donkey", "Mule",...) en la base de datos:
{
modelBuilder
.Entity<Rider>()
.Property(e => e.Mount)
.HasConversion(
v => v.ToString(),
v => (EquineBeast)Enum.Parse(typeof(EquineBeast), v));
}
NOTE
Un valor null nunca se pasará a un convertidor de valores. Esto hace que la implementación de conversiones sea más
sencilla y permite que se compartan entre propiedades que aceptan valores NULL y que no aceptan valores NULL.
La clase ValueConverter
Al llamar a HasConversion como se muestra anteriormente, se creará una instancia de ValueConverter y se
establecerá en la propiedad. En su lugar, se puede crear el ValueConverter explícitamente. Por ejemplo:
var converter = new ValueConverter<EquineBeast, string>(

v => v.ToString(),
v => (EquineBeast)Enum.Parse(typeof(EquineBeast), v));
modelBuilder
.Entity<Rider>()
.HasConversion(converter);
Esto puede ser útil cuando varias propiedades usan la misma conversión.
NOTE
Actualmente no hay ninguna manera de especificar en un lugar que cada propiedad de un tipo determinado debe usar el
mismo convertidor de valores. Esta característica se considerará para futuras versiones.
Convertidores integrados
EF Core incluye un conjunto de clases de ValueConverter predefinidas, que se encuentran en el espacio de
nombres Microsoft.EntityFrameworkCore.Storage.ValueConversion . Dichos componentes son:
BoolToZeroOneConverter -bool a cero y uno
BoolToStringConverter -bool a cadenas como "Y" y "N"
BoolToTwoValuesConverter -bool a dos valores cualesquiera
matriz de bytes de BytesToStringConverter a una cadena codificada en Base64
conversiones de CastingConverter que requieren solo una conversión de tipos
CharToStringConverter -char a una cadena de un solo carácter
DateTimeOffsetToBinaryConverter -DateTimeOffset a un valor codificado en binario 64 bits
DateTimeOffsetToBytesConverter -DateTimeOffset a la matriz de bytes
DateTimeOffsetToStringConverter -DateTimeOffset a cadena
DateTimeToBinaryConverter : DateTime al valor de 64 bits, incluido DateTimeKind
DateTimeToStringConverter : fecha y hora en cadena
DateTimeToTicksConverter : fecha y hora en pasos
EnumToNumberConverter -enum al número subyacente
EnumToStringConverter -enum a cadena
GuidToBytesConverter -GUID a una matriz de bytes
GuidToStringConverter -GUID a cadena
NumberToBytesConverter : cualquier valor numérico en una matriz de bytes
NumberToStringConverter : cualquier valor numérico a cadena
StringToBytesConverter : cadena en bytes UTF8
TimeSpanToStringConverter -TimeSpan a String
TimeSpanToTicksConverter -TimeSpan a ticks
Observe que EnumToStringConverter se incluye en esta lista. Esto significa que no es necesario especificar la
conversión explícitamente, como se muestra anteriormente. En su lugar, use simplemente el convertidor
integrado:
var converter = new EnumToStringConverter<EquineBeast>();
modelBuilder
.Entity<Rider>()
.HasConversion(converter);
Tenga en cuenta que todos los convertidores integrados no tienen estado y, por tanto, una sola instancia puede
compartirse de forma segura con varias propiedades.
Conversiones predefinidas
En el caso de las conversiones comunes para las que existe un convertidor integrado, no es necesario especificar
el convertidor explícitamente. En su lugar, solo tiene que configurar el tipo de proveedor que se debe usar y EF
usará automáticamente el convertidor integrado adecuado. La enumeración de las conversiones de cadenas se
usa como ejemplo anterior, pero EF lo hará automáticamente si se configura el tipo de proveedor:
modelBuilder
.Entity<Rider>()
.HasConversion<string>();
Lo mismo se puede lograr especificando explícitamente el tipo de columna. Por ejemplo, si el tipo de entidad se
define de la manera siguiente:
public class Rider

{
[Column(TypeName = "nvarchar(24)")]
public EquineBeast Mount { get; set; }
}
A continuación, los valores de enumeración se guardarán como cadenas en la base de datos sin ninguna otra
configuración en OnModelCreating .
Limitaciones
Hay algunas limitaciones actuales conocidas del sistema de conversión de valores:
Como se indicó anteriormente, no se puede convertir null .
Actualmente no hay ninguna manera de distribuir una conversión de una propiedad a varias columnas o
viceversa.
El uso de conversiones de valores puede afectar a la capacidad de EF Core para traducir expresiones a SQL. Se
registrará una advertencia para dichos casos. La eliminación de estas limitaciones se está considerando en una
versión futura.
La propagación de datos es el proceso de rellenar una base de datos con un conjunto inicial de datos.
Hay varias maneras de lograrlo en EF Core:
Datos de inicialización del modelo
Personalización de la migración manual
Lógica de inicialización personalizada
Datos de inicialización del modelo

NOTE
A diferencia de EF6, en EF Core, la propagación de datos se puede asociar a un tipo de entidad como parte de la
configuración del modelo. A continuación, las migraciones de EF Core pueden calcular automáticamente las
operaciones de inserción, actualización o eliminación que se deben aplicar al actualizar la base de datos a una
nueva versión del modelo.
NOTE
Las migraciones solo tienen en cuenta los cambios del modelo al determinar qué operación se debe realizar para obtener los
datos de inicialización en el estado deseado. Por lo tanto, es posible que se pierdan los cambios realizados en los datos fuera
de las migraciones o se produzca un error.
Por ejemplo, se configurarán los datos de inicialización de una Blog en OnModelCreating :
modelBuilder.Entity<Blog>().HasData(new Blog {BlogId = 1, Url = "http://sample.com"});
Para agregar entidades que tienen una relación, es necesario especificar los valores de clave externa:
modelBuilder.Entity<Post>().HasData(
new Post() { BlogId = 1, PostId = 1, Title = "First post", Content = "Test 1" });
Si el tipo de entidad tiene propiedades en el estado de sombra, se puede usar una clase anónima para
proporcionar los valores:
modelBuilder.Entity<Post>().HasData(
new { BlogId = 1, PostId = 2, Title = "Second post", Content = "Test 2" });
Los tipos de entidad de propiedad se pueden inicializar de una manera similar:

modelBuilder.Entity<Post>().OwnsOne(p => p.AuthorName).HasData(
new { PostId = 1, First = "Andriy", Last = "Svyryd" },
new { PostId = 2, First = "Diego", Last = "Vega" });
Vea el proyecto de ejemplo completo para obtener más contexto.

Una vez que se han agregado los datos al modelo, se deben usar las migraciones para aplicar los cambios.
TIP
Si necesita aplicar las migraciones como parte de una implementación automatizada, puede crear un script SQL que se
pueda obtener como vista previa antes de la ejecución.
Como alternativa, puede usar context.Database.EnsureCreated() para crear una nueva base de datos que contenga
los datos de inicialización, por ejemplo, para una base de datos de prueba o cuando se usa el proveedor en
memoria o cualquier base de datos que no sea de relación. Tenga en cuenta que si la base de datos ya existe,
EnsureCreated() no actualizará el esquema ni los datos de inicialización en la base de datos. En el caso de las
bases de datos relacionales, no debe llamar a EnsureCreated() si tiene previsto usar las migraciones.
Limitaciones de los datos de inicialización del modelo
Este tipo de datos de inicialización se administra mediante migraciones y el script para actualizar los datos que ya
están en la base de datos debe generarse sin necesidad de conectarse a la base de datos. Esto impone algunas
restricciones:
El valor de clave principal debe especificarse incluso si la base de datos lo genera normalmente. Se usará para
detectar los cambios de datos entre las migraciones.
Los datos previamente inicializados se quitarán si se cambia la clave principal de cualquier manera.
Por lo tanto, esta característica es muy útil para los datos estáticos que no se espera que cambien fuera de las
migraciones y no depende de nada más en la base de datos, por ejemplo códigos postales.
Si el escenario incluye alguno de los siguientes, se recomienda usar la lógica de inicialización personalizada que se
describe en la última sección:
Datos temporales para pruebas
Datos que dependen del estado de la base de datos
Datos que necesitan que la base de datos genere valores clave, incluidas las entidades que usan claves
alternativas como identidad.
Datos que requieren una transformación personalizada (que no se controlan mediante conversiones de
valores), como algunas operaciones hash de contraseñas.
Datos que requieren llamadas a la API externa, como ASP.NET Core roles de identidad y la creación de usuarios
Personalización de la migración manual

Cuando se agrega una migración, los cambios en los datos especificados con HasData se transforman en llamadas
a InsertData() , UpdateData() y DeleteData() . Una manera de resolver algunas de las limitaciones de HasData es
agregar manualmente estas llamadas o operaciones personalizadas a la migración.
migrationBuilder.InsertData(
table: "Blogs",
columns: new[] { "Url" },
values: new object[] { "http://generated.com" });
Lógica de inicialización personalizada
Una manera sencilla y eficaz de realizar la propagación de datos es usar DbContext.SaveChanges() antes de que la
lógica de la aplicación principal comience la ejecución.
using (var context = new DataSeedingContext())

{
var testBlog = context.Blogs.FirstOrDefault(b => b.Url == "http://test.com");

if (testBlog == null)
{
context.Blogs.Add(new Blog { Url = "http://test.com" });
}
}
WARNING
El código de propagación no debe formar parte de la ejecución normal de la aplicación, ya que esto puede provocar
problemas de simultaneidad cuando se ejecutan varias instancias y también requeriría que la aplicación tuviera permiso para
modificar el esquema de la base de datos.
En función de las restricciones de la implementación, el código de inicialización se puede ejecutar de diferentes

maneras:
Ejecución local de la aplicación de inicialización
Implementar la aplicación de inicialización con la aplicación principal, invocar la rutina de inicialización y
deshabilitar o quitar la aplicación de inicialización.
Normalmente, esto se puede automatizar mediante el uso de perfiles de publicación.
Tipos de entidad con constructores
NOTE
A partir de EF Core 2,1, ahora es posible definir un constructor con parámetros y EF Core llamar a este constructor
al crear una instancia de la entidad. Los parámetros de constructor se pueden enlazar a propiedades asignadas o a
varios tipos de servicios para facilitar comportamientos como la carga diferida.
NOTE
A partir de EF Core 2,1, todos los enlaces de constructor son por Convención. La configuración de constructores específicos
que se va a usar está planeada para una versión futura.
Enlazar a propiedades asignadas

Considere un modelo típico de blog o post:
public class Blog

{

public string Author { get; set; }
public ICollection<Post> Posts { get; } = new List<Post>();

}
public class Post

{

public DateTime PostedOn { get; set; }

}
Cuando EF Core crea instancias de estos tipos, como los resultados de una consulta, primero llamará al
constructor sin parámetros predeterminado y, a continuación, establecerá cada propiedad en el valor de la base de
datos. Sin embargo, si EF Core encuentra un constructor con parámetros con nombres de parámetros y tipos que
coinciden con los de propiedades asignadas, se llamará en su lugar al constructor con parámetros con valores
para esas propiedades y no establecerá cada propiedad explícitamente. Por ejemplo:
public class Blog
{
public Blog(int id, string name, string author)
{
Id = id;
Name = name;
Author = author;
}


}
public class Post

{
public Post(int id, string title, DateTime postedOn)
{
Id = id;
Title = title;
PostedOn = postedOn;
}


}
Cosas que tener en cuenta:

No todas las propiedades deben tener parámetros de constructor. Por ejemplo, la propiedad post. Content no
está establecida por ningún parámetro de constructor, por lo que EF Core la establecerá después de llamar al
constructor de la manera normal.
Los nombres y tipos de parámetros deben coincidir con los nombres y tipos de propiedad, con la excepción de
que las propiedades pueden tener mayúsculas y minúsculas Pascal, mientras que los parámetros tienen
mayúsculas y minúsculas Camel.
EF Core no pueden establecer las propiedades de navegación (como blog o publicaciones anteriores) mediante
un constructor.
El constructor puede ser público, privado o tener cualquier otra accesibilidad. Sin embargo, los proxies de
carga diferida requieren que el constructor sea accesible desde la clase de proxy heredada. Normalmente esto
significa que se hace público o protegido.
Propiedades de solo lectura
Una vez que las propiedades se establecen mediante el constructor, puede tener sentido que algunas de ellas sean
de solo lectura. EF Core es compatible con esto, pero hay algunas cosas que debe buscar:
Las propiedades sin establecedores no se asignan por Convención. (Esto tiende a asignar propiedades que no
deben asignarse, como las propiedades calculadas).
El uso de valores de clave generados automáticamente requiere una propiedad de clave que sea de lectura y
escritura, ya que el valor de clave debe establecerse mediante el generador de claves al insertar nuevas
entidades.
Una manera sencilla de evitar estos aspectos es usar establecedores privados. Por ejemplo:
public class Blog
{
public Blog(int id, string name, string author)
{
Id = id;
Name = name;
Author = author;
}
public int Id { get; private set; }
public string Name { get; private set; }

public string Author { get; private set; }

}
public class Post

{
public Post(int id, string title, DateTime postedOn)
{
Id = id;
Title = title;
}
public int Id { get; private set; }
public string Title { get; private set; }

public DateTime PostedOn { get; private set; }

}
EF Core ve una propiedad con un establecedor privado como de lectura y escritura, lo que significa que todas las
propiedades se asignan como antes y la clave todavía se puede generar en el almacén.
Una alternativa al uso de establecedores privados es hacer que las propiedades sean realmente de solo lectura y
agregar una asignación más explícita en OnModelCreating. Del mismo modo, algunas propiedades se pueden
quitar por completo y reemplazar solo por campos. Por ejemplo, considere estos tipos de entidad:
public class Blog
{
private int _id;
public Blog(string name, string author)

{
Name = name;
Author = author;
}
public string Name { get; }

public string Author { get; }

}
public class Post

{
private int _id;
public Post(string title, DateTime postedOn)

{
Title = title;
}
public string Title { get; }

public DateTime PostedOn { get; }

}
Y esta configuración en OnModelCreating:

{
modelBuilder.Entity<Blog>(
b =>
{
b.HasKey("_id");
b.Property(e => e.Author);
b.Property(e => e.Name);
});
modelBuilder.Entity<Post>(
b =>
{
b.HasKey("_id");
b.Property(e => e.Title);
b.Property(e => e.PostedOn);
});
}
Cosas que hay que tener en cuenta:

La clave "propiedad" es ahora un campo. No se trata de un campo de readonly para que se puedan usar las
claves generadas por el almacén.
Las demás propiedades son propiedades de solo lectura establecidas solo en el constructor.
Si el valor de la clave principal solo se establece en EF o se lee de la base de datos, no es necesario incluirlo en
el constructor. Esto deja la clave "Property" como un campo simple y deja claro que no se debe establecer
explícitamente al crear nuevos blogs o publicaciones.
NOTE
Este código producirá una advertencia del compilador ' 169 ' que indica que el campo nunca se utiliza. Esto puede pasarse
por alto, ya que en realidad EF Core está utilizando el campo de forma extralingüística.
Insertar servicios
EF Core también puede insertar "servicios" en el constructor de un tipo de entidad. Por ejemplo, se puede insertar
lo siguiente:
DbContext : la instancia de contexto actual, que también se puede escribir como el tipo de DbContext derivado.
ILazyLoader -el servicio de carga diferida, consulte la documentación sobre la carga diferida para obtener más
detalles.
Action<object, string> : un delegado de carga diferida; consulte la documentación sobre la carga diferida para
obtener más detalles.
IEntityType : los metadatos de EF Core asociados a este tipo de entidad
NOTE
A partir de EF Core 2,1, solo se pueden insertar los servicios conocidos por EF Core. Se está considerando la compatibilidad
con la inserción de servicios de aplicación en una versión futura.
Por ejemplo, un DbContext insertado se puede usar para tener acceso de forma selectiva a la base de datos para
obtener información sobre las entidades relacionadas sin cargarlas todas. En el ejemplo siguiente, se usa para
obtener el número de publicaciones en un blog sin cargar las entradas:
public class Blog
{
public Blog()
{
}
private Blog(BloggingContext context)

{
Context = context;
}
private BloggingContext Context { get; set; }

public ICollection<Post> Posts { get; set; }
public int PostsCount

=> Posts?.Count
?? Context?.Set<Post>().Count(p => Id == EF.Property<int?>(p, "BlogId"))
?? 0;
}
public class Post

{

}
Algunos aspectos que se deben tener en cuenta:

El constructor es privado, ya que nunca lo llama EF Core, y hay otro constructor público para uso general.
El código que usa el servicio inyectado (es decir, el contexto) está defensivo con respecto a que se null
controlar los casos en los que EF Core no crea la instancia.
Dado que el servicio se almacena en una propiedad de lectura y escritura, se restablecerá cuando la entidad se
adjunte a una nueva instancia de contexto.
WARNING
Inyectar DbContext como esto se suele considerar un anti-patrón, ya que une los tipos de entidad directamente a EF Core.
Tenga en cuenta todas las opciones antes de usar la inserción de servicios como esta.
División de tablas
EF Core permite asignar dos o más entidades a una sola fila. Esto se denomina División de tablas o uso
compartido de tablas.
Configuración
Para usar la división de tablas, los tipos de entidad deben asignarse a la misma tabla, tener las claves principales
asignadas a las mismas columnas y al menos una relación configurada entre la clave principal de un tipo de
entidad y otra en la misma tabla.
Un escenario común para la división de tablas es usar solo un subconjunto de las columnas de la tabla para un
mayor rendimiento o encapsulación.
En este ejemplo Order representa un subconjunto de DetailedOrder .
public class Order

{
public OrderStatus? Status { get; set; }
public DetailedOrder DetailedOrder { get; set; }
}
public class DetailedOrder

{
public OrderStatus? Status { get; set; }
public string BillingAddress { get; set; }
public byte[] Version { get; set; }
}
Además de la configuración necesaria, llamamos Property(o => o.Status).HasColumnName("Status") para asignar

DetailedOrder.Status a la misma columna que Order.Status .
modelBuilder.Entity<DetailedOrder>(dob =>
{
dob.ToTable("Orders");
dob.Property(o => o.Status).HasColumnName("Status");
});
modelBuilder.Entity<Order>(ob =>
{
ob.ToTable("Orders");
ob.Property(o => o.Status).HasColumnName("Status");
ob.HasOne(o => o.DetailedOrder).WithOne()
.HasForeignKey<DetailedOrder>(o => o.Id);
});
TIP
Uso
Guardar y consultar entidades mediante la división de tablas se realiza de la misma manera que otras entidades:
using (var context = new TableSplittingContext())

{
context.Database.EnsureDeleted();
context.Add(new Order
{
Status = OrderStatus.Pending,
DetailedOrder = new DetailedOrder
{
Status = OrderStatus.Pending,
ShippingAddress = "221 B Baker St, London",
BillingAddress = "11 Wall Street, New York"
}
});
}

{
var pendingCount = context.Orders.Count(o => o.Status == OrderStatus.Pending);
Console.WriteLine($"Current number of pending orders: {pendingCount}");
}

{
var order = context.DetailedOrders.First(o => o.Status == OrderStatus.Pending);
Console.WriteLine($"First pending order will ship to: {order.ShippingAddress}");
}
Entidad dependiente opcional

NOTE
Esta característica se presentó en EF Core 3,0.
Si todas las columnas utilizadas por una entidad dependiente están NULL en la base de datos, no se creará
ninguna instancia para ella cuando se realice la consulta. Esto permite el modelado de una entidad dependiente
opcional, donde la propiedad Relationship de la entidad de seguridad sería null. Tenga en cuenta que esto también
ocurrirá si todas las propiedades del dependiente son opcionales y se establecen en null , lo que podría no ser el
esperado.
Si alguno de los tipos de entidad que comparten una tabla tiene un token de simultaneidad, también debe
incluirse en todos los demás tipos de entidad. Esto es necesario para evitar un valor de token de simultaneidad
obsoleto cuando solo se actualiza una de las entidades asignadas a la misma tabla.
Para evitar exponer el token de simultaneidad al código utilizado, es posible crear uno como una propiedad de
sombra:
.Property<byte[]>("Version").IsRowVersion().HasColumnName("Version");
modelBuilder.Entity<DetailedOrder>()
.Property(o => o.Version).IsRowVersion().HasColumnName("Version");
Tipos de entidad en propiedad
EF Core permite a tipos de entidad del modelo que sólo pueden aparecer en las propiedades de navegación de
otros tipos de entidad. Se denominan tipos de entidad de propiedad. La entidad que contiene un tipo de entidad
propiedad es su propietario.
Las entidades propiedad son esencialmente parte del propietario y no pueden existir sin ella, son
conceptualmente similares a los agregados. Esto significa que la entidad propiedad es por definición en el lado
dependiente de la relación con el propietario.
Configuración explícita
Propiedad de entidad tipos nunca se incluyen por EF Core en el modelo por convención. Puede usar el método
OwnsOne en OnModelCreating o anotar el tipo con OwnedAttribute (novedad en EF Core 2,1) para configurar el
tipo como un tipo de propiedad.
En este ejemplo, StreetAddress es un tipo sin propiedad de identidad. Se usa como propiedad del tipo Order
para especificar la dirección de envío de un pedido en concreto.
Podemos usar el OwnedAttribute para tratarlo como una entidad propiedad cuando se hace referencia a él desde
otro tipo de entidad:
[Owned]
{
}
public class Order

{
}
También es posible usar el método OwnsOne de OnModelCreating para especificar que la propiedad
ShippingAddress es una entidad propiedad del tipo de entidad Order y para configurar aspectos adicionales si
es necesario.
modelBuilder.Entity<Order>().OwnsOne(p => p.ShippingAddress);
Si la propiedad ShippingAddress es privada en el tipo de Order , puede usar la versión de cadena del método
OwnsOne :
modelBuilder.Entity<Order>().OwnsOne(typeof(StreetAddress), "ShippingAddress");

Claves IMPLÍCITAS
Los tipos de propiedad configurados con OwnsOne o detectados a través de una navegación de referencia
siempre tienen una relación uno a uno con el propietario, por lo que no necesitan sus propios valores de clave, ya
que los valores de clave externa son únicos. En el ejemplo anterior, el tipo de StreetAddress no necesita definir
una propiedad de clave.
Para entender cómo EF Core realiza el seguimiento de estos objetos, es útil saber que se crea una clave principal
como una propiedad de sombra para el tipo de propiedad. El valor de la clave de una instancia del tipo de
propiedad será el mismo que el valor de la clave de la instancia de propietario.
Colecciones de tipos de propiedad

NOTE
Para configurar una colección de tipos de propiedad, use OwnsMany en OnModelCreating .

Los tipos de propiedad necesitan una clave principal. Si no hay buenas propiedades candidatas en el tipo .NET, EF
Core puede intentar crear una. Sin embargo, cuando los tipos de propiedad se definen a través de una colección,
no basta con crear simplemente una propiedad Shadow que actúe como clave externa en el propietario y la clave
principal de la instancia de propiedad, como hacemos para OwnsOne : puede haber varias instancias de tipo de
propiedad para cada propietario y, por lo tanto, la clave del propietario no es suficiente para proporcionar una
identidad única para cada instancia de
Las dos soluciones más directas son:
Definir una clave principal suplente en una nueva propiedad independiente de la clave externa que señala al
propietario. Los valores contenidos deben ser únicos en todos los propietarios (por ejemplo, si el {1} primario
tiene {1}secundarios, el {2} primario no puede tener {1}secundarios), por lo que el valor no tiene ningún
significado inherente. Dado que la clave externa no forma parte de la clave principal, sus valores se pueden
cambiar, por lo que puede trasladar un elemento secundario de un elemento primario a otro; sin embargo,
esto suele pasar por la semántica de agregado.
Usar la clave externa y una propiedad adicional como clave compuesta. El valor de propiedad adicional ahora
solo debe ser único para un elemento primario determinado (por lo que si el {1} primario tiene {1,1}
secundarios, el {2} principal todavía puede tener {2,1}secundarios). Al convertir la parte de clave externa de la
clave principal en la relación entre el propietario y la entidad propiedad, se convierte en inmutable y se refleja
mejor la semántica de agregado. Esto es lo que EF Core hace de forma predeterminada.
En este ejemplo, usaremos la clase Distributor :
public class Distributor

{
public ICollection<StreetAddress> ShippingCenters { get; set; }
}
De forma predeterminada, la clave principal que se usa para el tipo de propiedad al que se hace referencia a
través de la propiedad de navegación de ShippingCenters se ("DistributorId", "Id") donde "DistributorId"
es el FK y "Id" es un valor de int único.
Para configurar una llamada PK diferente HasKey :
modelBuilder.Entity<Distributor>().OwnsMany(p => p.ShippingCenters, a =>
{
a.WithOwner().HasForeignKey("OwnerId");
a.Property<int>("Id");
a.HasKey("Id");
});
NOTE
Antes de que el método EF Core 3,0 WithOwner() no existiera, se debe quitar esta llamada. Además, la clave principal no
se detectó automáticamente, por lo que siempre se especificó.
Asignar tipos de propiedad con división de tabla

Cuando se usan bases de datos relacionales, de forma predeterminada, los tipos de propiedad de propiedad se
asignan a la misma tabla que el propietario. Esto requiere dividir la tabla en dos: se usarán algunas columnas
para almacenar los datos del propietario, y algunas columnas se utilizarán para almacenar los datos de la entidad
propiedad. Se trata de una característica común conocida como División de tablas.
De forma predeterminada, EF Core asignará el nombre a las columnas de la base de datos para las propiedades
del tipo de entidad propiedad que sigue al patrón Navigation_OwnedEntityProperty. Por lo tanto, las propiedades
de StreetAddress aparecerán en la tabla ' Orders ' con los nombres ' ShippingAddress_Street ' y '
ShippingAddress_City '.
Puede usar el método HasColumnName para cambiar el nombre de esas columnas:
modelBuilder.Entity<Order>().OwnsOne(
o => o.ShippingAddress,
sa =>
{
sa.Property(p => p.Street).HasColumnName("ShipsToStreet");
sa.Property(p => p.City).HasColumnName("ShipsToCity");
});
NOTE
La mayoría de los métodos de configuración de tipo de entidad normales, como Ignore , se pueden llamar de la misma
manera.
Compartir el mismo tipo .NET entre varios tipos de propiedad

Un tipo de entidad de propiedad puede ser del mismo tipo de .NET que otro tipo de entidad de propiedad, por lo
que es posible que el tipo .NET no sea suficiente para identificar un tipo de propiedad.
En esos casos, la propiedad que apunta del propietario a la entidad propiedad se convierte en la navegación de
definición del tipo de entidad de propiedad. Desde la perspectiva del EF Core, la definición de la navegación es
parte de la identidad del tipo junto con el tipo de .NET.
Por ejemplo, en la siguiente clase ShippingAddress y BillingAddress son ambos del mismo tipo .NET,
StreetAddress :
{
public DetailedOrder Order { get; set; }
}
Para entender cómo EF Core distinguirá las instancias de de estos objetos de las que se ha realizado un
seguimiento, puede ser útil pensar que la navegación que define se ha convertido en parte de la clave de la
instancia junto con el valor de la clave del propietario y el tipo .NET del tipo de propiedad.
Tipos de propiedad anidados

En este ejemplo OrderDetails posee BillingAddress y ShippingAddress , que son tipos de StreetAddress . Luego,
OrderDetails es propiedad del tipo DetailedOrder .
public class DetailedOrder

{
public OrderDetails OrderDetails { get; set; }
public OrderStatus Status { get; set; }
}
public enum OrderStatus

{
Pending,
Shipped
}
Cada navegación a un tipo de propiedad define un tipo de entidad independiente con una configuración
completamente independiente.
Además de los tipos de propiedad anidados, un tipo de propiedad puede hacer referencia a una entidad normal,
puede ser el propietario o una entidad distinta, siempre y cuando la entidad propiedad esté en el lado
dependiente. Esta funcionalidad establece tipos de entidad de propiedad además de tipos complejos en EF6.

{
public DetailedOrder Order { get; set; }
}
Es posible encadenar el método OwnsOne en una llamada fluida para configurar este modelo:
modelBuilder.Entity<DetailedOrder>().OwnsOne(p => p.OrderDetails, od =>

{
od.WithOwner(d => d.Order);
od.OwnsOne(c => c.BillingAddress);
od.OwnsOne(c => c.ShippingAddress);
});
Observe la llamada WithOwner utilizada para configurar la propiedad de navegación que señala hacia atrás en el
propietario. Para configurar una navegación al tipo de entidad Owner que no forma parte de la relación de
propiedad WithOwner() se debe llamar a sin ningún argumento.
Es posible lograr el resultado mediante OwnedAttribute en OrderDetails y StreetAddress .
Almacenar tipos de propiedad en tablas independientes

Además, a diferencia de los tipos complejos de EF6, los tipos de propiedad se pueden almacenar en una tabla
independiente del propietario. Para invalidar la Convención que asigna un tipo de propiedad a la misma tabla
que el propietario, puede llamar simplemente a ToTable y proporcionar un nombre de tabla diferente. En el
ejemplo siguiente se asignará OrderDetails y sus dos direcciones a una tabla independiente de DetailedOrder :
modelBuilder.Entity<DetailedOrder>().OwnsOne(p => p.OrderDetails, od =>

{
od.ToTable("OrderDetails");
});
También es posible usar el TableAttribute para lograr esto, pero tenga en cuenta que esto produciría un error si
hay varias navegaciones al tipo de propiedad, ya que en ese caso se asignarían varios tipos de entidad a la misma
tabla.
Consultar tipos de propiedad

Al consultar al propietario, los tipos de propiedad se incluyen de forma predeterminada. No es necesario utilizar
el método Include , incluso si los tipos de propiedad se almacenan en una tabla independiente. En función del
modelo descrito anteriormente, la siguiente consulta obtendrá Order , OrderDetails y los dos StreetAddresses
de propiedad de la base de datos:
var order = context.DetailedOrders.First(o => o.Status == OrderStatus.Pending);

Console.WriteLine($"First pending order will ship to: {order.OrderDetails.ShippingAddress.City}");
Limitaciones
Algunas de estas limitaciones son fundamentales para el funcionamiento de los tipos de entidad de propiedad,
pero otras son restricciones que podríamos ser capaces de quitar en versiones futuras:
Restricciones por diseño
No se puede crear un DbSet<T> para un tipo de propiedad
No se puede llamar a Entity<T>() con un tipo de propiedad en ModelBuilder
Deficiencias actuales
Los tipos de entidad de propiedad no pueden tener jerarquías de herencia
Las navegaciones de referencia a tipos de entidad de propiedad no pueden ser null a menos que se asignen
explícitamente a una tabla independiente del propietario.
Los distintos propietarios no pueden compartir instancias de tipos de entidad con propiedad (este es un
escenario conocido para objetos de valor que no se pueden implementar mediante tipos de entidad de
propiedad)
Deficiencias en versiones anteriores
En EF Core 2,0, las navegaciones a tipos de entidad de propiedad no se pueden declarar en tipos de entidad
derivadas a menos que las entidades de propiedad se asignen explícitamente a una tabla independiente de la
jerarquía de propietarios. Esta limitación se ha eliminado en EF Core 2,1
En EF Core 2,0 y 2,1 solo se admiten las navegaciones de referencia a los tipos de propiedad. Esta limitación se
ha eliminado en EF Core 2,2
Tipos de entidad sin llave
NOTE
Esta característica se agregó en EF Core 2,1 bajo el nombre de los tipos de consulta. En EF Core 3,0 se cambió el nombre
del concepto a tipos de entidad sin entrada.
Además de los tipos de entidad normales, un modelo de EF Core puede contener _tipos de entidad_sin clave, que
se pueden usar para realizar consultas de base de datos con datos que no contengan valores de clave.
Características de tipos de entidad sin llave

Los tipos de entidad sin llave admiten muchas de las mismas capacidades de asignación que los tipos de entidad
normales, como las propiedades de navegación y asignación de herencia. En almacenes relacionales, pueden
configurar los objetos de base de datos de destino y las columnas a través de métodos de la API fluidos o las
anotaciones de datos.
Sin embargo, son diferentes de los tipos de entidad normales en que:
No se puede definir una clave.
Nunca se realiza un seguimiento de los cambios en DbContext y, por lo tanto, nunca se insertan, actualizan o
eliminan en la base de datos.
Nunca se detectan por convención.
Solo admite un subconjunto de capacidades de asignación de navegación, en concreto:
Nunca pueden actuar como el extremo principal de una relación.
Puede que no tengan navegaciones a entidades propiedad
Solo pueden contener propiedades de navegación de referencia que apunten a entidades normales.
Las entidades no pueden contener propiedades de navegación a tipos de entidad sin llave.
Debe configurarse con .HasNoKey() llamada al método.
Se puede asignar a una consulta de definición. Una consulta de definición es una consulta declarada en el
modelo que actúa como origen de datos para un tipo de entidad sin entrada.
Escenarios de uso
Algunos de los escenarios de uso principales de los tipos de entidad sin llave son:
Actúa como el tipo de valor devuelto para las consultas SQL sin procesar.
Asignación a vistas de base de datos que no contienen una clave principal.
Asignación de tablas que no tiene definida una clave principal.
Asignación de las consultas definidas en el modelo.
Asignación de objetos de base de datos

La asignación de un tipo de entidad sin llave a un objeto de base de datos se consigue mediante el ToTable o
ToView API fluida. Desde la perspectiva de EF Core, el objeto de base de datos especificado en este método es
una vista, lo que significa que se trata como un origen de consulta de solo lectura y no puede ser el destino de
las operaciones de actualización, inserción o eliminación. Sin embargo, esto no significa que el objeto de base de
datos sea realmente necesario para ser una vista de base de datos. Como alternativa, puede tratarse de una tabla
de base de datos que se tratará como de solo lectura. Por el contrario, en el caso de los tipos de entidad
normales, EF Core supone que un objeto de base de datos especificado en el método ToTable se puede tratar
como una tabla, lo que significa que se puede usar como origen de la consulta, pero también como destino de
las operaciones de actualización, eliminación e inserción. De hecho, puede especificar el nombre de una vista de
base de datos en ToTable y todo debería funcionar bien siempre que la vista esté configurada para ser
actualizable en la base de datos.
NOTE
ToView supone que el objeto ya existe en la base de datos y que no lo crearán las migraciones.
Ejemplo
En el ejemplo siguiente se muestra cómo utilizar los tipos de entidad sin entrada para consultar una vista de
base de datos.
TIP
En primer lugar, definimos un modelo sencillo de Blog y Post:
public class Blog

{
}
public class Post

{
}
A continuación, definimos una vista de base de datos simple que nos permitirá consultar el número de entradas
vinculadas a cada blog:
db.Database.ExecuteSqlRaw(
@"CREATE VIEW View_BlogPostCounts AS
SELECT b.Name, Count(p.PostId) as PostCount
FROM Blogs b
JOIN Posts p on p.BlogId = b.BlogId
GROUP BY b.Name");
A continuación, definimos una clase para contener el resultado de la vista de base de datos:
public class BlogPostsCount
{
public string BlogName { get; set; }
public int PostCount { get; set; }
}
A continuación, configuraremos el tipo de entidad sin llave en OnModelCreating con la API de HasNoKey .
Usamos la API de configuración fluida para configurar la asignación para el tipo de entidad sin llave:

{
modelBuilder
.Entity<BlogPostsCount>(eb =>
{
eb.HasNoKey();
eb.ToView("View_BlogPostCounts");
eb.Property(v => v.BlogName).HasColumnName("Name");
});
}
A continuación, configuramos el DbContext para incluir el DbSet<T> :
public DbSet<BlogPostsCount> BlogPostCounts { get; set; }
Por último, podemos consultar la vista de base de datos de la manera estándar:
var postCounts = db.BlogPostCounts.ToList();
foreach (var postCount in postCounts)

{
Console.WriteLine($"{postCount.BlogName} has {postCount.PostCount} posts.");
Console.WriteLine();
}
TIP
Nota también hemos definido una propiedad de consulta de nivel de contexto (DbSet) para que actúe como raíz para las
consultas en este tipo.
Alternar entre varios modelos con el mismo tipo
DbContext
El modelo integrado OnModelCreating puede utilizar una propiedad en el contexto para cambiar la forma en que se
compila el modelo. Por ejemplo, supongamos que desea configurar una entidad de forma diferente en función de
alguna propiedad:

{
if (UseIntProperty)
{
modelBuilder.Entity<ConfigurableEntity>().Ignore(e => e.StringProperty);
}
else
{
modelBuilder.Entity<ConfigurableEntity>().Ignore(e => e.IntProperty);
}
}
Desafortunadamente, este código no funcionaría tal cual, ya que EF crea el modelo y se ejecuta OnModelCreating
una sola vez, con lo que se almacena en caché el resultado por motivos de rendimiento. Sin embargo, puede
enlazar con el mecanismo de almacenamiento en caché del modelo para que EF tenga en cuenta la propiedad que
genera distintos modelos.
IModelCacheKeyFactory
EF utiliza el IModelCacheKeyFactory para generar claves de caché para los modelos; de forma predeterminada, EF
supone que para un tipo de contexto dado, el modelo será el mismo, por lo que la implementación predeterminada
de este servicio devuelve una clave que solo contiene el tipo de contexto. Para generar diferentes modelos a partir
del mismo tipo de contexto, debe reemplazar el servicio IModelCacheKeyFactory con la implementación correcta. la
clave generada se comparará con otras claves del modelo mediante el método Equals , teniendo en cuenta todas
las variables que afectan al modelo:
La siguiente implementación tiene en cuenta el IgnoreIntProperty al generar una clave de caché del modelo:
public class DynamicModelCacheKeyFactory : IModelCacheKeyFactory

{
public object Create(DbContext context)
=> context is DynamicContext dynamicContext
? (context.GetType(), dynamicContext.UseIntProperty)
: (object)context.GetType();
}
Por último, registre la nueva IModelCacheKeyFactory en el OnConfiguring de contexto:

=> optionsBuilder
.UseInMemoryDatabase("DynamicContext")
.ReplaceService<IModelCacheKeyFactory, DynamicModelCacheKeyFactory>();
Datos espaciales
NOTE
Esta característica se agregó en EF Core 2,2.
Los datos espaciales representan la ubicación física y la forma de los objetos. Muchas bases de datos proporcionan
compatibilidad con este tipo de datos, por lo que se puede indizar y consultar junto con otros datos. Entre los
escenarios comunes se incluyen las consultas de objetos dentro de una distancia determinada desde una ubicación
o la selección del objeto cuyo borde contiene una ubicación determinada. EF Core admite la asignación a tipos de
datos espaciales mediante la biblioteca espacial NetTopologySuite .
Instalación
Para usar los datos espaciales con EF Core, debe instalar el paquete NuGet de soporte adecuado. El paquete que
necesita instalar depende del proveedor que esté usando.
P RO VEEDO R DE EF C O RE PA Q UET E DE N UGET ESPA C IA L
Microsoft.EntityFrameworkCore.SqlServer Microsoft. EntityFrameworkCore. SqlServer. NetTopologySuite
Microsoft.EntityFrameworkCore.Sqlite Microsoft. EntityFrameworkCore. SQLite. NetTopologySuite
Microsoft.EntityFrameworkCore.InMemory NetTopologySuite
Npgsql.EntityFrameworkCore.PostgreSQL Npgsql. EntityFrameworkCore. PostgreSQL. NetTopologySuite
Ingeniería inversa
Los paquetes de NuGet espaciales también habilitan los modelos de ingeniería inversa con propiedades espaciales,
pero debe instalar el paquete antes de ejecutar Scaffold-DbContext o dotnet ef dbcontext scaffold . Si no lo hace,
recibirá advertencias sobre cómo no encontrar las asignaciones de tipos para las columnas y se omitirán las
columnas.
NetTopologySuite (NTS)
NetTopologySuite es una biblioteca espacial para .NET. EF Core permite la asignación a tipos de datos espaciales en
la base de datos mediante el uso de tipos NTS en el modelo.
Para habilitar la asignación a tipos espaciales a través de NTS, llame al método UseNetTopologySuite en el
generador de opciones DbContext del proveedor. Por ejemplo, con SQL Server le llamaría como esto.
@"Data Source=(localdb)\MSSQLLocalDB;Initial Catalog=WideWorldImporters",
x => x.UseNetTopologySuite());
Hay varios tipos de datos espaciales. El tipo que use dependerá de los tipos de formas que desee permitir. Esta es la
jerarquía de tipos NTS que puede usar para las propiedades del modelo. Están ubicados en el espacio de nombres
NetTopologySuite.Geometries .
Geometría
Punto
LineString
Polygon
GeometryCollection
MultiPoint
MultiLineString
MultiPolygon
WARNING
La CircularString, CompoundCurve y CurePolygon no son compatibles con NTS.
El uso del tipo de geometría base permite que la propiedad especifique cualquier tipo de forma.
Las siguientes clases de entidad se pueden usar para asignar tablas en la base de datos de ejemplo Wide World
Importers.
[Table("Cities", Schema = "Application"))]

class City
{
public int CityID { get; set; }
public string CityName { get; set; }
public Point Location { get; set; }

}
[Table("Countries", Schema = "Application"))]

class Country
{
public int CountryID { get; set; }
public string CountryName { get; set; }
// Database includes both Polygon and MultiPolygon values

public Geometry Border { get; set; }
}
Crear valores
Puede usar constructores para crear objetos Geometry; sin embargo, NTS recomienda el uso de un generador de
geometría en su lugar. Esto le permite especificar un valor predeterminado de SRID (el sistema de referencia
espacial que usan las coordenadas) y le proporciona el control sobre aspectos más avanzados, como el modelo de
precisión (usado durante los cálculos) y la secuencia de coordenadas (determina las coordenadas: dimensiones). y
las medidas--están disponibles).
var geometryFactory = NtsGeometryServices.Instance.CreateGeometryFactory(srid: 4326);

var currentLocation = geometryFactory.CreatePoint(-122.121512, 47.6739882);
NOTE
4326 hace referencia a WGS 84, un estándar que se usa en GPS y en otros sistemas geográficos.
Longitud y latitud
Las coordenadas en NTS están en términos de valores X e y. Para representar la longitud y la latitud, use X para
longitud e y para latitud. Tenga en cuenta que esto es hacia atrás desde el formato de latitude, longitude en el
que normalmente se ven estos valores.
SRID omitido durante las operaciones de cliente
NTS omite los valores de SRID durante las operaciones. Supone un sistema de coordenadas plano. Esto significa
que si especifica coordenadas en términos de longitud y latitud, algunos valores evaluados por el cliente como la
distancia, la longitud y el área estarán en grados, no en metros. Para valores más significativos, primero debe
proyectar las coordenadas en otro sistema de coordenadas mediante una biblioteca como ProjNet4GeoAPI antes
de calcular estos valores.
Si una operación es evaluada por el servidor mediante EF Core a través de SQL, la unidad del resultado se
determinará por la base de datos.
Este es un ejemplo del uso de ProjNet4GeoAPI para calcular la distancia entre dos ciudades.
static class GeometryExtensions

{
static readonly CoordinateSystemServices _coordinateSystemServices
= new CoordinateSystemServices(
new CoordinateSystemFactory(),
new CoordinateTransformationFactory(),
new Dictionary<int, string>
{
// Coordinate systems:
[4326] = GeographicCoordinateSystem.WGS84.WKT,
// This coordinate system covers the area of our data.

// Different data requires a different coordinate system.
[2855] =
@"
PROJCS[""NAD83(HARN) / Washington North"",
GEOGCS[""NAD83(HARN)"",
DATUM[""NAD83_High_Accuracy_Regional_Network"",
SPHEROID[""GRS 1980"",6378137,298.257222101,
AUTHORITY[""EPSG"",""7019""]],
PRIMEM[""Greenwich"",0,
UNIT[""degree"",0.01745329251994328,
PROJECTION[""Lambert_Conformal_Conic_2SP""],
PARAMETER[""standard_parallel_1"",48.73333333333333],
PARAMETER[""standard_parallel_2"",47.5],
PARAMETER[""latitude_of_origin"",47],
PARAMETER[""central_meridian"",-120.8333333333333],
PARAMETER[""false_easting"",500000],
PARAMETER[""false_northing"",0],
UNIT[""metre"",1,
AUTHORITY[""EPSG"",""2855""]]
"
});
public static Geometry ProjectTo(this Geometry geometry, int srid)

{
var transformation = _coordinateSystemServices.CreateTransformation(geometry.SRID, srid);
var result = geometry.Copy();

result.Apply(new MathTransformFilter(transformation.MathTransform));
return result;
return result;
}
class MathTransformFilter : ICoordinateSequenceFilter

{
readonly MathTransform _transform;
public MathTransformFilter(MathTransform transform)

=> _transform = transform;
public bool Done => false;

public bool GeometryChanged => true;
public void Filter(CoordinateSequence seq, int i)

{
var result = _transform.Transform(
new[]
{
seq.GetOrdinate(i, Ordinate.X),
seq.GetOrdinate(i, Ordinate.Y)
});
seq.SetOrdinate(i, Ordinate.X, result[0]);
seq.SetOrdinate(i, Ordinate.Y, result[1]);
}
}
}
var seattle = new Point(-122.333056, 47.609722) { SRID = 4326 };

var redmond = new Point(-122.123889, 47.669444) { SRID = 4326 };
var distance = seattle.ProjectTo(2855).Distance(redmond.ProjectTo(2855));
Consulta de datos
En LINQ, los métodos y las propiedades NTS disponibles como funciones de base de datos se traducirán a SQL. Por
ejemplo, los métodos Distance y Contains se traducen en las siguientes consultas. En la tabla al final de este
artículo se muestran los miembros que son compatibles con varios proveedores de EF Core.
var nearestCity = db.Cities

.OrderBy(c => c.Location.Distance(currentLocation))
.FirstOrDefault();
var currentCountry = db.Countries

.FirstOrDefault(c => c.Border.Contains(currentLocation));
SQL Server
Si usa SQL Server, hay algunos aspectos adicionales que debe tener en cuenta.
Geografía o geometría
De forma predeterminada, las propiedades espaciales se asignan a geography columnas en SQL Server. Para usar
geometry , Configure el tipo de columna en el modelo.
Anillos de polígono de geografía

Cuando se usa el tipo de columna geography , SQL Server impone requisitos adicionales en el anillo exterior (o
shell) y los anillos interiores (o agujeros). El anillo exterior debe estar orientado en sentido contrario a las agujas
del reloj y los anillos interiores hacia la derecha. NTS valida esto antes de enviar los valores a la base de datos.
FullGlobe
SQL Server tiene un tipo de geometría no estándar para representar todo el globo terráqueo cuando se usa el tipo
de columna geography . También tiene una forma de representar polígonos basados en el globo completo (sin un
anillo exterior). Ninguno de ellos es compatible con NTS.
WARNING
Los FullGlobe y los polígonos basados en ellos no son compatibles con NTS.
SQLite
A continuación se muestra información adicional para los usuarios que usan SQLite.
Instalación de SpatiaLite
En Windows, la biblioteca de mod_spatialite nativa se distribuye como una dependencia del paquete NuGet. Otras
plataformas deben instalarse por separado. Esto se suele hacer mediante un administrador de paquetes de
software. Por ejemplo, puede usar APT en Ubuntu y homebrew en MacOS.
# Ubuntu
apt-get install libsqlite3-mod-spatialite
# macOS
brew install libspatialite
Desafortunadamente, las versiones más recientes de PROJ (una dependencia de SpatiaLite) son incompatibles con
el paquete SQLitePCLRawpredeterminado de EF. Para solucionar este fin, puede crear un proveedor de
SQLitePCLRaw personalizado que use la biblioteca de SQLite del sistema, o bien puede instalar una compilación
personalizada de SpatiaLite deshabilitar la compatibilidad con proj.
curl https://www.gaia-gis.it/gaia-sins/libspatialite-4.3.0a.tar.gz | tar -xz

cd libspatialite-4.3.0a
if [[ `uname -s` == Darwin* ]]; then

# Mac OS requires some minor patching
sed -i "" "s/shrext_cmds='\`test \\.\$module = .yes && echo .so \\|\\| echo
\\.dylib\`'/shrext_cmds='.dylib'/g" configure
fi
./configure --disable-proj
make
make install
Configuración de SRID
En SpatiaLite, las columnas deben especificar un SRID por columna. El valor predeterminado de SRID es 0 .
Especifique otro SRID con el método ForSqliteHasSrid.
modelBuilder.Entity<City>().Property(c => c.Location)

.ForSqliteHasSrid(4326);
Dimensión
De forma similar a SRID, la dimensión de una columna (o las ordenadas) también se especifica como parte de la
columna. Las ordenadas predeterminadas son X e y. Habilite las ordenadas adicionales (Z y M) mediante el método
ForSqliteHasDimension.
modelBuilder.Entity<City>().Property(c => c.Location)
.ForSqliteHasDimension(Ordinates.XYZ);
Operaciones traducidas
En esta tabla se muestran los miembros de NTS que cada proveedor de EF Core traduce en SQL.
SQ L SERVER SQ L SERVER
N ET TO P O LO GY SUIT E ( GEO M ET RÍA ) ( GEO GRA F ÍA ) SQ L IT E N P GSQ L
Geometry. Area ✔ ✔ ✔ ✔
Geometry. AsBinary () ✔ ✔ ✔ ✔
Geometry. astext () ✔ ✔ ✔ ✔
Geometry. Boundary ✔ ✔ ✔
Geometry. Buffer ✔ ✔ ✔ ✔
(Double)
Geometry. Buffer ✔ ✔
(Double, int)
Geometry. centroide ✔ ✔ ✔
Geometry. Contains ✔ ✔ ✔ ✔
(Geometry)
Geometry. ✔ ✔ ✔ ✔
ConvexHull ()
Geometry. CoveredBy ✔ ✔
(Geometry)
Geometry. cubiertas ✔ ✔
(Geometry)
Geometry. Crosses ✔ ✔ ✔
(Geometry)
Geometry. Difference ✔ ✔ ✔ ✔
(Geometry)
Geometry. Dimension ✔ ✔ ✔ ✔
Geometry. disunion ✔ ✔ ✔ ✔
(Geometry)
Geometry. Distance ✔ ✔ ✔ ✔
(Geometry)
Geometría. sobre ✔ ✔ ✔
Geometry. ✔
EqualsExact
(Geometry)
EqualsTopologically
(Geometry)
GeometryType
Geometry. ✔ ✔ ✔
GetGeometryN (int)
InteriorPoint
Intersection
(Geometry)
Geometry. Intersects ✔ ✔ ✔ ✔
(Geometry)
Geometry. IsEmpty ✔ ✔ ✔ ✔
Geometry. IsSimple ✔ ✔ ✔
Geometry. IsValid ✔ ✔ ✔ ✔
IsWithinDistance
(Geometry, Double)
Geometry. length ✔ ✔ ✔ ✔
NumGeometries
Geometry. NumPoints ✔ ✔ ✔ ✔
OgcGeometryType
Geometry. superpone ✔ ✔ ✔ ✔
(Geometry)
PointOnSurface
Geometry. Relate ✔ ✔ ✔
(Geometry, String)
Geometry. Reverse () ✔ ✔
Geometry. SRID ✔ ✔ ✔ ✔
SymmetricDifference
(Geometry)
Geometry. ToBinary () ✔ ✔ ✔ ✔
Geometry. ToText () ✔ ✔ ✔ ✔
Geometry. toques ✔ ✔ ✔
(Geometry)
Geometry. Union () ✔ ✔
Geometry. Union ✔ ✔ ✔ ✔
(Geometry)
Geometry. Within ✔ ✔ ✔ ✔
(Geometry)
GeometryCollection. ✔ ✔ ✔ ✔
Count
GeometryCollection ✔ ✔ ✔ ✔
[int]
LineString. Count ✔ ✔ ✔ ✔
LineString. EndPoint ✔ ✔ ✔ ✔
LineString. GetPointN ✔ ✔ ✔ ✔
(int)
LineString. IsClosed ✔ ✔ ✔ ✔
LineString. IsRing ✔ ✔ ✔
LineString. StartPoint ✔ ✔ ✔ ✔
MultiLineString. ✔ ✔ ✔ ✔
IsClosed
Punto. M ✔ ✔ ✔ ✔
Point. X ✔ ✔ ✔ ✔
Punto. Y ✔ ✔ ✔ ✔
Punto. Z ✔ ✔ ✔ ✔
Polygon. ExteriorRing ✔ ✔ ✔ ✔
Polygon. ✔ ✔ ✔ ✔
GetInteriorRingN (int)
Polygon. ✔ ✔ ✔ ✔
NumInteriorRings
Datos espaciales en SQL Server
Página principal de SpatiaLite
Documentación espacial Npgsql
Documentación de PostGIS
Administración de esquemas de base de datos
EF Core proporciona dos métodos principales para mantener sincronizados el esquema de la base de datos y el
modelo de EF Core. Para elegir entre los dos, decida si es el modelo de EF Core o el esquema de la base de datos el
origen verdadero.
Si quiere que el modelo de EF Core sea el origen verdadero, use Migraciones. Al realizar cambios en el modelo de
EF Core, este método aplica de forma incremental los cambios de esquema correspondientes a la base de datos
para que siga siendo compatible con el modelo de EF Core.
Si quiere que el esquema de la base de datos sea el origen verdadero, use Ingeniería inversa. Este método permite
aplicar la técnica de scaffolding a un elemento DbContext y a las clases de tipo de entidad mediante la aplicación de
ingeniería inversa al esquema de la base de datos de un modelo de EF Core.
NOTE
Las API de creación y eliminación también pueden crear el esquema de la base de datos a partir del modelo de EF Core. Pero
son principalmente para pruebas, creación de prototipos y otros escenarios donde la eliminación de la base de datos es
aceptable.
Migraciones
Un modelo de datos cambia durante el desarrollo y deja de estar sincronizado con la base de datos. Puede
quitar la base de datos y dejar que EF cree una que coincida con el modelo, pero este procedimiento provoca
la pérdida de datos. La característica de migraciones de EF Core proporciona una manera de actualizar
incrementalmente el esquema de la base de datos para mantenerla sincronizada con el modelo de datos de la
aplicación al tiempo que se conservan los datos existentes en la base de datos.
Las migraciones incluyen herramientas de línea de comandos y API que facilitan las siguientes tareas:
Crear una migración. Generar código que puede actualizar la base de datos para sincronizarla con un
conjunto de cambios en el modelo.
Actualizar la base de datos. Aplicar las migraciones pendientes para actualizar el esquema de la base de
datos.
Personalizar el código de migración. A veces el código generado debe modificarse o complementarse.
Quitar una migración. Eliminar el código generado.
Revertir una migración. Deshacer los cambios de la base de datos.
Generar scripts SQL. Puede que necesite un script para actualizar una base de datos de producción o para
solucionar problemas con el código de migración.
Aplicar migraciones en tiempo de ejecución. Si las actualizaciones en tiempo de diseño y la ejecución de
scripts no son las mejores opciones, llame al método Migrate() .
TIP
Si DbContext está en un ensamblado diferente al del proyecto de inicio, puede especificar de manera explícita los
proyectos de destino e inicio tanto en las herramientas de la Consola del Administrador de paquetes como en las
herramientas de la CLI de .NET Core.
Instalar las herramientas

Instale las herramientas de línea de comandos:
Para Visual Studio, se recomiendan las herramientas de la Consola del Administrador de paquetes.
Para otros entornos de desarrollo, elija las herramientas de la CLI de .NET Core.
Crear una migración

Una vez definido el modelo inicial, es el momento de crear la base de datos. Para agregar una migración
inicial, ejecute el siguiente comando.
CLI de .NET Core
Visual Studio
dotnet ef migrations add InitialCreate
Se agregan tres archivos al proyecto en el directorio Migraciones :

XXXXXXXXXXXXXX_InitialCreate.cs : archivo principal de las migraciones. Contiene las operaciones
necesarias para aplicar la migración (en Up() ) y para revertirla (en Down() ).
XXXXXXXXXXXXXX_InitialCreate.Designer.cs : archivo de metadatos de las migraciones. Contiene
información que usa EF.
MyContextModelSnapshot.cs : instantánea del modelo actual. Se usa para determinar qué ha cambiado
al agregar la siguiente migración.
La marca de tiempo del nombre del archivo ayuda a mantenerlos ordenados cronológicamente para que se
pueda ver la progresión de cambios.
TIP
Puede mover los archivos de Migraciones y cambiar su espacio de nombres. Se crean nuevas migraciones como
elementos del mismo nivel de la última migración.
Actualizar la base de datos

Luego aplique la migración a la base de datos para crear el esquema.
CLI de .NET Core
Visual Studio
Personalizar el código de migración

Después de realizar cambios en el modelo de EF Core, puede que el esquema de la base de datos no esté
sincronizado. Para ponerlo al día, agregue otra migración. El nombre de la migración se puede usar como
mensaje de confirmación en un sistema de control de versiones. Por ejemplo, podría elegir un nombre como
AddProductReviews si el cambio es una nueva clase de entidad para las revisiones.
CLI de .NET Core
Visual Studio
dotnet ef migrations add AddProductReviews
Tras aplicar scaffolding a la migración (código generado para ella), revise el código para mayor precisión y
agregue, quite o modifique todas las operaciones necesarias para aplicarla correctamente.
Por ejemplo, una migración podría contener las siguientes operaciones:
migrationBuilder.DropColumn(
name: "FirstName",
table: "Customer");
name: "LastName",
table: "Customer");
migrationBuilder.AddColumn<string>(
name: "Name",
table: "Customer",
nullable: true);
Aunque estas operaciones hacen que el esquema de la base de datos sea compatible, no conservan los
nombres de cliente existentes. Para que sea mejor, vuelva a escribirla como se indica a continuación.
migrationBuilder.AddColumn<string>(
name: "Name",
table: "Customer",
nullable: true);
migrationBuilder.Sql(
@"
UPDATE Customer
SET Name = FirstName + ' ' + LastName;
");
name: "FirstName",
table: "Customer");
name: "LastName",
table: "Customer");
TIP
El proceso de scaffolding de la migración advierte si una operación puede ocasionar una pérdida de datos (como el
borrado de una columna). Si aparece dicha advertencia, asegúrese especialmente de revisar el código de las migraciones
para mayor precisión.
Aplique la migración a la base de datos con el comando apropiado.

CLI de .NET Core
Visual Studio
Migraciones vacías
A veces resulta útil agregar una migración sin realizar ningún cambio de modelo. En este caso, agregar una
nueva migración crea archivos de código con clases vacías. Puede personalizar esta migración para llevar a
cabo operaciones que no estén directamente relacionadas con el modelo de EF Core. Algunos aspectos que
podría querer administrar de esta manera son:
Búsqueda de texto completo
Funciones
Procedimientos almacenados
Desencadenadores
Vistas
Quitar una migración

A veces uno agrega una migración y se da cuenta de que debe realizar cambios adicionales en el modelo de
EF Core antes de aplicarla. Para quitar la última migración, use este comando.
CLI de .NET Core
Visual Studio
dotnet ef migrations remove
Después de quitar la migración, puede realizar los cambios de modelo adicionales y volver a agregarla.
Revertir una migración

Si ya ha aplicado una migración (o varias migraciones) a la base de datos pero necesita revertirla, puede usar
el mismo comando que para aplicar migraciones, aunque debe especificar el nombre de la migración que
quiere revertir.
CLI de .NET Core
Visual Studio
dotnet ef database update LastGoodMigration
Generar scripts SQL

Al depurar las migraciones o implementarlas en una base de datos de producción, es útil generar un script
SQL. El script luego se puede revisar y ajustar a las necesidades de una base de datos de producción. El script
también puede usarse junto con una tecnología de implementación. El comando básico es el siguiente.
CLI de .NET Core
Visual Studio
Uso básico
dotnet ef migrations script
Con From (To implícito)

Se generará un script SQL desde esta migración a la migración más reciente.
dotnet ef migrations script 20190725054716_Add_new_tables
Con From y To
Se generará un script SQL de la migración de from a la migración de to especificada.
dotnet ef migrations script 20190725054716_Add_new_tables 20190829031257_Add_audit_table
Puede usar un valor from que sea más reciente que el valor to para generar un script de reversión. Tome
nota de los posibles escenarios de pérdida de datos.
Hay varias opciones para este comando.
La migración from debe ser la última migración aplicada a la base de datos antes de ejecutar el script. Si no se
han aplicado migraciones, especifique 0 (es el valor predeterminado).
La migración to debe ser la última migración que se va a aplicar a la base de datos después de ejecutar el
script. El valor predeterminado es la última migración del proyecto.
Se puede generar un script idempotent de forma opcional. Este script solo aplica migraciones si aún no se
han aplicado a la base de datos. Es útil si no sabe exactamente cuál ha sido la última migración aplicada a la
base de datos o si va a implementar en varias bases de datos que pueden encontrarse en migraciones
diferentes.
Aplicar migraciones en tiempo de ejecución
Algunas aplicaciones pueden querer aplicar migraciones en tiempo de ejecución durante el inicio o la primera
ejecución. Para ello, se usa el método Migrate() .
Este método se basa en el servicio , que se puede usar para escenarios más avanzados. Use
IMigrator
myDbContext.GetInfrastructure().GetService<IMigrator>() para acceder a él.
myDbContext.Database.Migrate();
WARNING
Este método no es para todos. Aunque es excelente para las aplicaciones con una base de datos local, la mayoría de
las aplicaciones necesitan estrategias de implementación más sólidas, como la generación de scripts SQL.
No llame a EnsureCreated() antes de Migrate() . EnsureCreated() omite las migraciones para crear el
esquema, lo cual provoca un error de Migrate() .
Pasos siguientes
Para obtener más información, vea Referencia sobre las herramientas de Entity Framework Core (EF Core).
Migraciones en entornos de equipo
Al trabajar con migraciones en entornos de equipo, preste especial atención al archivo de instantáneas del modelo.
Este archivo puede indicarle si la migración de su compañero de equipo se combina correctamente con la suya o si
necesita resolver un conflicto volviendo a crear la migración antes de compartirla.
Combinación
Al fusionar mediante combinación las migraciones de sus compañeros de equipo, puede obtener conflictos en el
archivo de instantánea del modelo. Si los dos cambios no están relacionados, la combinación es trivial y las dos
migraciones pueden coexistir. Por ejemplo, puede obtener un conflicto de fusión mediante combinación en la
configuración del tipo de entidad Customer, que tiene el siguiente aspecto:
<<<<<<< Mine
b.Property<bool>("Deactivated");
=======
b.Property<int>("LoyaltyPoints");
>>>>>>> Theirs
Puesto que ambas propiedades deben existir en el modelo final, complete la combinación agregando ambas
propiedades. En muchos casos, es posible que el sistema de control de versiones combine automáticamente estos
cambios.
b.Property<bool>("Deactivated");
b.Property<int>("LoyaltyPoints");
En estos casos, la migración y la migración de su compañero son independientes entre sí. Dado que cualquiera de
ellas se podría aplicar en primer lugar, no es necesario realizar ningún cambio adicional en la migración antes de
compartirla con el equipo.
Resolución de conflictos
A veces se produce un conflicto real al combinar el modelo de instantánea de modelo. Por ejemplo, usted y su
compañero de equipo pueden cambiar el nombre de la misma propiedad.
<<<<<<< Mine
b.Property<string>("Username");
=======
b.Property<string>("Alias");
>>>>>>> Theirs
Si encuentra este tipo de conflicto, resuélvalos volviendo a crear la migración. Siga estos pasos:
1. Anular la combinación y revertir al directorio de trabajo antes de la fusión mediante combinación
2. Quitar la migración (pero mantener los cambios del modelo)
3. Combinar los cambios de su compañero en el directorio de trabajo
4. Volver a agregar la migración
Después de hacer esto, las dos migraciones se pueden aplicar en el orden correcto. En primer lugar, se aplica su
migración, cambiando el nombre de la columna a aliasy, a partir de ese momento, la migración lo cambia por
nombre de usuario.
La migración puede compartirse de forma segura con el resto del equipo.
Operaciones de migración personalizadas
La API de MigrationBuilder permite realizar muchos tipos diferentes de operaciones durante una migración, pero
está lejos de ser exhaustiva. Sin embargo, la API también es extensible, lo que le permite definir sus propias
operaciones. Hay dos maneras de extender la API: mediante el método Sql() o mediante la definición de objetos
de MigrationOperation personalizados.
Para ilustrar, echemos un vistazo a la implementación de una operación que crea un usuario de base de datos
mediante cada enfoque. En nuestras migraciones, queremos habilitar la escritura del código siguiente:
migrationBuilder.CreateUser("SQLUser1", "Password");
Usar MigrationBuilder. SQL ()

La forma más fácil de implementar una operación personalizada es definir un método de extensión que llame a
MigrationBuilder.Sql() . Este es un ejemplo que genera el correspondiente Transact-SQL.
static MigrationBuilder CreateUser(

this MigrationBuilder migrationBuilder,
string name,
string password)
=> migrationBuilder.Sql($"CREATE USER {name} WITH PASSWORD '{password}';");
Si las migraciones necesitan admitir varios proveedores de bases de datos, puede usar la propiedad
MigrationBuilder.ActiveProvider . Este es un ejemplo que admite tanto Microsoft SQL Server como PostgreSQL.

string name,
string password)
{
switch (migrationBuilder.ActiveProvider)
{
case "Npgsql.EntityFrameworkCore.PostgreSQL":
return migrationBuilder
.Sql($"CREATE USER {name} WITH PASSWORD '{password}';");
case "Microsoft.EntityFrameworkCore.SqlServer":
return migrationBuilder
.Sql($"CREATE USER {name} WITH PASSWORD = '{password}';");
}
return migrationBuilder;
}
Este enfoque solo funciona si conoce todos los proveedores en los que se va a aplicar la operación personalizada.
Uso de un MigrationOperation
Para desacoplar la operación personalizada de SQL, puede definir su propia MigrationOperation para
representarla. A continuación, la operación se pasa al proveedor para que pueda determinar el SQL adecuado que
se va a generar.
class CreateUserOperation : MigrationOperation

{
public string Password { get; set; }
}
Con este enfoque, el método de extensión solo tiene que agregar una de estas operaciones a
MigrationBuilder.Operations .

string name,
string password)
{
migrationBuilder.Operations.Add(
new CreateUserOperation
{
Name = name,
Password = password
});
return migrationBuilder;
}
Este enfoque requiere que cada proveedor sepa cómo generar SQL para esta operación en su servicio
IMigrationsSqlGenerator . Este es un ejemplo invalidando el generador del SQL Server para administrar la nueva
operación.
class MyMigrationsSqlGenerator : SqlServerMigrationsSqlGenerator
{
public MyMigrationsSqlGenerator(
MigrationsSqlGeneratorDependencies dependencies,
IMigrationsAnnotationProvider migrationsAnnotations)
: base(dependencies, migrationsAnnotations)
{
}
protected override void Generate(

MigrationOperation operation,
IModel model,
MigrationCommandListBuilder builder)
{
if (operation is CreateUserOperation createUserOperation)
{
Generate(createUserOperation, builder);
}
else
{
base.Generate(operation, model, builder);
}
}
private void Generate(

CreateUserOperation operation,
MigrationCommandListBuilder builder)
{
var sqlHelper = Dependencies.SqlGenerationHelper;
var stringMapping = Dependencies.TypeMappingSource.FindMapping(typeof(string));
builder
.Append("CREATE USER ")
.Append(sqlHelper.DelimitIdentifier(operation.Name))
.Append(" WITH PASSWORD = ")
.Append(stringMapping.GenerateSqlLiteral(operation.Password))
.AppendLine(sqlHelper.StatementTerminator)
.EndCommand();
}
}
Reemplace el servicio de generador de SQL de migraciones predeterminado por el actualizado.

=> options
.ReplaceService<IMigrationsSqlGenerator, MyMigrationsSqlGenerator>();
Uso de un proyecto de migración independiente
Es posible que desee almacenar las migraciones en un ensamblado diferente del que contiene el DbContext .
También puede usar esta estrategia para mantener varios conjuntos de migraciones, por ejemplo, una para el
desarrollo y otra para las actualizaciones de lanzamiento a lanzamiento.
Para hacer esto...
1. Cree una nueva biblioteca de clases.
2. Agregue una referencia al ensamblado DbContext.
3. Mueva las migraciones y los archivos de instantáneas de modelo a la biblioteca de clases.
TIP
Si no tiene ninguna migración existente, genere una en el proyecto que contiene el DbContext y muévala. Esto es
importante porque si el ensamblado de migraciones no contiene una migración existente, el comando Add-
Migration no podrá encontrar DbContext.
4. Configure el ensamblado de migraciones:
options.UseSqlServer(
connectionString,
x => x.MigrationsAssembly("MyApp.Migrations"));
5. Agregue una referencia al ensamblado de migraciones desde el ensamblado de inicio.

Si esto produce una dependencia circular, actualice la ruta de acceso de salida de la biblioteca de
clases:
<PropertyGroup>
<OutputPath>..\MyStartupProject\bin\$(Configuration)\</OutputPath>
</PropertyGroup>
Si lo hizo todo correctamente, debería poder agregar nuevas migraciones al proyecto.

CLI de .NET Core
Visual Studio
dotnet ef migrations add NewMigration --project MyApp.Migrations

Migraciones con varios proveedores
Las herramientas de EF Core solo las migraciones de scaffolding para el proveedor activo. Sin embargo, a veces es
posible que desee usar más de un proveedor (por ejemplo Microsoft SQL Server y SQLite) con DbContext. Hay dos
formas de controlar esto con las migraciones. Puede mantener dos conjuntos de migraciones, uno para cada
proveedor, o combinarlos en un único conjunto que pueda funcionar en ambos.
Dos conjuntos de migración

En el primer enfoque, se generan dos migraciones para cada cambio de modelo.
Una manera de hacerlo es colocar cada conjunto de migración en un ensamblado independiente y cambiar
manualmente el proveedor activo (y el ensamblado de migraciones) entre agregar las dos migraciones.
Otro enfoque que facilita el trabajo con las herramientas es crear un nuevo tipo que derive de su DbContext e
invalide el proveedor activo. Este tipo se utiliza en tiempo de diseño al agregar o aplicar migraciones.
class MySqliteDbContext : MyDbContext

{
=> options.UseSqlite("Data Source=my.db");
}
NOTE
Dado que cada conjunto de migración usa sus propios tipos DbContext, este enfoque no requiere el uso de un ensamblado
de migración independiente.
Al agregar una nueva migración, especifique los tipos de contexto.

CLI de .NET Core
Visual Studio
dotnet ef migrations add InitialCreate --context MyDbContext --output-dir Migrations/SqlServerMigrations

dotnet ef migrations add InitialCreate --context MySqliteDbContext --output-dir Migrations/SqliteMigrations
TIP
No es necesario especificar el directorio de salida para las migraciones posteriores, ya que se crean como elementos del
mismo nivel que el último.
Un conjunto de migración
Si no le gusta tener dos conjuntos de migraciones, puede combinarlas manualmente en un único conjunto que se
puede aplicar a ambos proveedores.
Las anotaciones pueden coexistir ya que un proveedor omite cualquier anotación que no comprenda. Por ejemplo,
una columna de clave principal que funciona con Microsoft SQL Server y SQLite podría tener este aspecto.
Id = table.Column<int>(nullable: false)
.Annotation("SqlServer:ValueGenerationStrategy",
SqlServerValueGenerationStrategy.IdentityColumn)
.Annotation("Sqlite:Autoincrement", true),
Si las operaciones solo se pueden aplicar en un proveedor (o son diferentes entre proveedores), use la propiedad
ActiveProvider para indicar qué proveedor está activo.
if (migrationBuilder.ActiveProvider == "Microsoft.EntityFrameworkCore.SqlServer")
{
migrationBuilder.CreateSequence(
name: "EntityFrameworkHiLoSequence");
}
Tabla de historial de migraciones personalizadas
De forma predeterminada, EF Core realiza un seguimiento de las migraciones que se han aplicado a la base de
datos mediante su grabación en una tabla denominada __EFMigrationsHistory . Por varias razones, puede que
desee personalizar esta tabla para satisfacer mejor sus necesidades.
IMPORTANT
Si personaliza la tabla de historial de migraciones después de aplicar las migraciones, es responsable de actualizar la tabla
existente en la base de datos.
Esquema y nombre de tabla

Puede cambiar el esquema y el nombre de la tabla mediante el método MigrationsHistoryTable() en
OnConfiguring() (o ConfigureServices() en ASP.NET Core). Este es un ejemplo del uso del proveedor de EF Core de
SQL Server.

=> options.UseSqlServer(
connectionString,
x => x.MigrationsHistoryTable("__MyMigrationsHistory", "mySchema"));
Otros cambios
Para configurar aspectos adicionales de la tabla, invalide y reemplace el servicio de IHistoryRepository específico
del proveedor. Este es un ejemplo de cómo cambiar el nombre de la columna MigrationId a ID en SQL Server.

=> options
.ReplaceService<IHistoryRepository, MyHistoryRepository>();
WARNING
SqlServerHistoryRepository está dentro de un espacio de nombres interno y puede cambiar en futuras versiones.
class MyHistoryRepository : SqlServerHistoryRepository
{
public MyHistoryRepository(HistoryRepositoryDependencies dependencies)
: base(dependencies)
{
}
protected override void ConfigureTable(EntityTypeBuilder<HistoryRow> history)

{
base.ConfigureTable(history);
history.Property(h => h.MigrationId).HasColumnName("Id");

}
}
Crear y quitar API
Los métodos EnsureCreated y EnsureDeleted proporcionan una alternativa ligera a las migraciones para
administrar el esquema de la base de datos. Estos métodos son útiles en escenarios en los que los datos son
transitorios y se pueden quitar cuando cambia el esquema. Por ejemplo, durante el prototipo, en las pruebas o en
las memorias caché locales.
Algunos proveedores (especialmente los no relacionales) no admiten las migraciones. Para estos proveedores,
EnsureCreated suele ser la manera más fácil de inicializar el esquema de la base de datos.
WARNING
EnsureCreated y las migraciones no funcionan bien juntos. Si utiliza migraciones, no use EnsureCreated para inicializar el
esquema.
La transición de EnsureCreated a migraciones no es una experiencia sin problemas. La manera más sencilla de
hacerlo es quitar la base de datos y volver a crearla con las migraciones. Si prevé usar migraciones en el futuro, es
mejor empezar con las migraciones en lugar de usar EnsureCreated.
EnsureDeleted
El método EnsureDeleted quitará la base de datos si existe. Si no tiene los permisos adecuados, se produce una
excepción.
// Drop the database if it exists

dbContext.Database.EnsureDeleted();
EnsureCreated
EnsureCreated creará la base de datos si no existe e inicializará el esquema de la base de datos. Si existe alguna
tabla (incluidas las tablas de otra clase DbContext), el esquema no se inicializará.
// Create the database if it doesn't exist

dbContext.Database.EnsureCreated();
TIP
También hay disponibles versiones asincrónicas de estos métodos.
Secuencia de comandos de SQL

Para obtener el SQL que usa EnsureCreated, puede utilizar el método GenerateCreateScript.
var sql = dbContext.Database.GenerateCreateScript();

Varias clases DbContext
EnsureCreated solo funciona cuando no hay ninguna tabla presente en la base de datos. Si es necesario, puede
escribir su propia comprobación para ver si es necesario inicializar el esquema y usar el servicio
IRelationalDatabaseCreator subyacente para inicializar el esquema.
// TODO: Check whether the schema needs to be initialized
// Initialize the schema for this DbContext

var databaseCreator = dbContext.GetService<IRelationalDatabaseCreator>();
databaseCreator.CreateTables();
Ingeniería inversa
La ingeniería inversa es el proceso de scaffolding de las clases de tipo de entidad y una clase DbContext basada
en un esquema de base de datos. Puede realizarse mediante el comando Scaffold-DbContext de las herramientas
de la consola del administrador de paquetes EF Core (PMC) o el comando dotnet ef dbcontext scaffold de las
herramientas de la interfaz de la línea de comandos (CLI) de .NET.
Instalación
Antes de la ingeniería inversa, deberá instalar las herramientas de PMC (solo en Visual Studio) o las
herramientasde la CLI. Vea los vínculos para obtener más información.
También necesitará instalar un proveedor de base de datos adecuado para el esquema de la base de datos al que
desea aplicar ingeniería inversa.
Cadena de conexión
El primer argumento del comando es una cadena de conexión a la base de datos. Las herramientas usarán esta
cadena de conexión para leer el esquema de la base de datos.
La forma de citar y escapar de la cadena de conexión depende del shell que use para ejecutar el comando.
Consulte la documentación de su shell para obtener información específica. Por ejemplo, PowerShell requiere que
se escape el carácter $ , pero no \ .
Scaffold-DbContext 'Data Source=(localdb)\MSSQLLocalDB;Initial Catalog=Chinook'

dotnet ef dbcontext scaffold "Data Source=(localdb)\MSSQLLocalDB;Initial Catalog=Chinook"

Configuración y secretos de usuario

Si tiene un proyecto de ASP.NET Core, puede usar la sintaxis de Name=<connection-string> para leer la cadena de
conexión de la configuración.
Esto funciona bien con la herramienta de administración de secretos para mantener la contraseña de la base de
datos separada del código base.
dotnet user-secrets set ConnectionStrings.Chinook "Data Source=(localdb)\MSSQLLocalDB;Initial

Catalog=Chinook"
dotnet ef dbcontext scaffold Name=Chinook Microsoft.EntityFrameworkCore.SqlServer
Nombre de proveedor
El segundo argumento es el nombre del proveedor. El nombre del proveedor suele ser el mismo que el nombre
del paquete NuGet del proveedor.
Especificar tablas
De forma predeterminada, se aplica ingeniería inversa a todas las tablas del esquema de la base de datos en tipos
de entidad. Puede limitar las tablas a las que se aplica ingeniería inversa mediante la especificación de esquemas
y tablas.
El parámetro -Schemas en PMC y la opción --schema de la CLI se pueden usar para incluir todas las tablas de un
esquema.
-Tables (PMC) y --table (CLI) se pueden usar para incluir tablas específicas.
Para incluir varias tablas en PMC, use una matriz.
Scaffold-DbContext ... -Tables Artist, Album
Para incluir varias tablas en la CLI, especifique la opción varias veces.
dotnet ef dbcontext scaffold ... --table Artist --table Album
Conservar nombres
Los nombres de tablas y columnas se han corregido para que coincidan mejor con las convenciones de
nomenclatura de .NET para tipos y propiedades de forma predeterminada. Si se especifica el modificador
-UseDatabaseNames en PMC o la opción --use-database-names de la CLI, se deshabilitará este comportamiento
para conservar los nombres de las bases de datos originales lo máximo posible. Los identificadores de .NET no
válidos seguirán siendo fijos y los nombres sintetizados, como las propiedades de navegación, seguirán
conforme a las convenciones de nomenclatura de .NET.
Anotaciones de datos o API fluidas

Los tipos de entidad se configuran mediante la API fluida de forma predeterminada. Especifique
-DataAnnotations (PMC) o --data-annotations (CLI) para usar las anotaciones de datos siempre que sea posible.
Por ejemplo, el uso de la API fluida le aplicará esta técnica:
entity.Property(e => e.Title)

.IsRequired()
.HasMaxLength(160);
Aunque el uso de anotaciones de datos es scaffolding:
[Required]
[StringLength(160)]
Nombre de DbContext
El nombre de la clase DbContext con scaffolding será el nombre de la base de datos con sufijo de contexto de
forma predeterminada. Para especificar otro, use -Context en PMC y --context en la CLI.
Directorios y espacios de nombres

Las clases de entidad y una clase DbContext se scaffolding en el directorio raíz del proyecto y usan el espacio de
nombres predeterminado del proyecto. Puede especificar el directorio en el que se van a aplicar las scaffolding
mediante -OutputDir (PMC) o --output-dir (CLI). El espacio de nombres será el espacio de nombres raíz más
los nombres de los subdirectorios del directorio raíz del proyecto.
También puede usar -ContextDir (PMC) y --context-dir (CLI) para aplicar scaffolding a la clase DbContext en
un directorio independiente de las clases de tipo de entidad.
Scaffold-DbContext ... -ContextDir Data -OutputDir Models
dotnet ef dbcontext scaffold ... --context-dir Data --output-dir Models
Funcionamiento
La ingeniería inversa comienza leyendo el esquema de la base de datos. Lee información acerca de las tablas,
columnas, restricciones e índices.
A continuación, usa la información de esquema para crear un modelo de EF Core. Las tablas se usan para crear
tipos de entidad. las columnas se usan para crear propiedades; y las claves externas se utilizan para crear
relaciones.
Por último, el modelo se usa para generar código. Las clases de tipo de entidad, la API fluida y las anotaciones de
datos correspondientes son scaffolding para volver a crear el mismo modelo desde la aplicación.
Limitaciones
No todo lo relacionado con un modelo se puede representar mediante un esquema de la base de datos. Por
ejemplo, la información sobre las jerarquías de herencia , los tipos de propiedad y la División de tablas
no están presentes en el esquema de la base de datos. Por este motivo, estas construcciones nunca se
aplicarán a ingeniería inversa.
Además, es posible que algunos tipos de columna no sean compatibles con el proveedor de EF Core. Estas
columnas no se incluirán en el modelo.
Puede definir tokens de simultaneidad en un modelo de EF Core para evitar que dos usuarios actualicen la
misma entidad al mismo tiempo. Algunas bases de datos tienen un tipo especial para representar este tipo de
columna (por ejemplo, rowversion en SQL Server), en cuyo caso se puede aplicar ingeniería inversa a esta
información; sin embargo, no se aplicarán ingeniería inversa a otros tokens de simultaneidad.
La C# característica 8 tipos de referencia que aceptan valores NULL no se admite actualmente en ingeniería
inversa: EF Core C# siempre genera código que supone que la característica está deshabilitada. Por ejemplo,
las columnas de texto que aceptan valores NULL se scaffolding como una propiedad con el tipo string , no
string? , con la API fluida o las anotaciones de datos que se usan para configurar si una propiedad es
obligatoria o no. Puede editar el código con scaffolding y reemplazarlo con anotaciones de C# nulabilidad. El
seguimiento de la compatibilidad con scaffolding para tipos de referencia que aceptan valores NULL se realiza
mediante el problema #15520.
Personalización del modelo

El código generado por EF Core es el código. No dude en cambiarlo. Solo se regenerará si vuelve a aplicar
ingeniería inversa al mismo modelo. El código con scaffolding representa un modelo que se puede utilizar para
tener acceso a la base de datos, pero ciertamente no es el único modelo que se puede usar.
Personalice las clases de tipo de entidad y la clase DbContext para que se adapte a sus necesidades. Por ejemplo,
puede elegir cambiar el nombre de tipos y propiedades, introducir jerarquías de herencia o dividir una tabla en
varias entidades. También puede quitar índices no únicos, secuencias sin usar y propiedades de navegación,
propiedades escalares opcionales y nombres de restricción del modelo.
También puede Agregar constructores, métodos, propiedades, etc. adicionales. usar otra clase parcial en un
archivo independiente. Este enfoque funciona incluso cuando se desea volver a aplicar ingeniería inversa al
modelo.
Actualizar el modelo
Después de realizar cambios en la base de datos, puede que tenga que actualizar el modelo de EF Core para
reflejar los cambios. Si los cambios en la base de datos son sencillos, puede que sea más fácil realizar los cambios
manualmente en el modelo de EF Core. Por ejemplo, cambiar el nombre de una tabla o columna, quitar una
columna o actualizar el tipo de una columna son cambios triviales que se deben realizar en el código.
Sin embargo, los cambios más significativos no son tan sencillos como los que se realizan de forma manual. Un
flujo de trabajo común consiste en volver a aplicar ingeniería inversa del modelo de la base de datos mediante
-Force (PMC) o --force (CLI) para sobrescribir el modelo existente con uno actualizado.
Otra característica solicitada comúnmente es la posibilidad de actualizar el modelo de la base de datos a la vez
que se conserva la personalización, como cambiar el nombre, las jerarquías de tipos, etc. Use el #831 de
problemas para realizar el seguimiento del progreso de esta característica.
WARNING
Si vuelve a aplicar ingeniería inversa al modelo desde la base de datos, se perderán los cambios realizados en los archivos.
Consulta de datos
Entity Framework Core usa Language Integrated Query (LINQ) para consultar datos de la base de datos. LINQ
permite usar C# (o el lenguaje .NET que prefiera) para escribir consultas fuertemente tipadas. Usa el contexto
derivado y las clases de entidad para hacer referencia a los objetos de base de datos. EF Core pasa una
representación de la consulta LINQ al proveedor de la base de datos. A su vez, los proveedores de la base de datos
la traducen al lenguaje de la consulta específico para la base de datos (por ejemplo, SQL para una base de datos
relacional).
TIP
Los fragmentos de código siguientes muestran algunos ejemplos de cómo realizar tareas comunes con Entity
Framework Core.
Carga de todos los datos

{
var blogs = context.Blogs.ToList();
}
Carga de una sola entidad

{
var blog = context.Blogs
.Single(b => b.BlogId == 1);
}
Filtros
{
.Where(b => b.Url.Contains("dotnet"))
.ToList();
}
Lecturas adicionales
Obtenga más información sobre las expresiones de consulta LINQ.
Para más información sobre cómo se procesa una consulta en EF Core, vea Cómo funcionan las consultas.
Evaluación de cliente frente a servidor
Como norma general, Entity Framework Core intenta evaluar una consulta en el servidor lo máximo posible. EF
Core convierte partes de la consulta en parámetros, que se pueden evaluar en el lado cliente. El resto de la consulta
( junto con los parámetros generados) se proporciona al proveedor de base de datos para determinar la consulta
de base de datos equivalente que se va a evaluar en el servidor. EF Core admite la evaluación de cliente parcial en
la proyección de nivel superior (fundamentalmente, la última llamada a Select() ). Si la proyección de nivel
superior de la consulta no se puede traducir en el servidor, EF Core capturará los datos necesarios del servidor y
evaluará las partes restantes de la consulta en el cliente. Si EF Core detecta una expresión, en cualquier lugar que
no sea la proyección de nivel superior, que no se puede traducir en el servidor, inicia una excepción en tiempo de
ejecución. Vea Funcionamiento de la consulta para saber cómo determina EF Core lo que no se puede traducir al
servidor.
NOTE
Antes de la versión 3.0, Entity Framework Core admitía la evaluación de cliente en cualquier parte de la consulta. Para
obtener más información, vea la sección sobre versiones anteriores.
TIP
Evaluación de cliente en la proyección de nivel superior

En el ejemplo siguiente, se usa un método auxiliar para estandarizar las direcciones URL para blogs, que se
devuelven desde una base de datos de SQL Server. Como el proveedor de SQL Server no tiene información de
cómo se implementa este método, no es posible traducirlo a código SQL. Todos los demás aspectos de la consulta
se evalúan en la base de datos, pero es el cliente quien pasa la URL devuelta mediante este método.

.OrderByDescending(blog => blog.Rating)
.Select(blog => new
{
Id = blog.BlogId,
Url = StandardizeUrl(blog.Url)
})
.ToList();
public static string StandardizeUrl(string url)

{
url = url.ToLower();
if (!url.StartsWith("http://"))
{
url = string.Concat("http://", url);
}
return url;
}
Evaluación de cliente no admitida
Aunque la evaluación de cliente es útil, en ocasiones puede generar un rendimiento bajo. Considere la consulta
siguiente, en la que ahora el método auxiliar se usa en un filtro WHERE. Como el filtro no se puede aplicar en la
base de datos, se deben extraer todos los datos de la memoria para aplicar el filtro en el cliente. Según el filtro y la
cantidad de datos en el servidor, la evaluación de cliente podría dar lugar a un rendimiento deficiente. Por tanto,
Entity Framework Core bloquea esa evaluación de cliente e inicia una excepción en tiempo de ejecución.

.Where(blog => StandardizeUrl(blog.Url).Contains("dotnet"))
.ToList();
Evaluación explícita de cliente

Es posible que tenga que forzar la evaluación de cliente de forma explícita en ciertos casos como los siguientes:
La cantidad de datos es pequeña, por lo que la evaluación en el cliente no incurre en una gran penalización del
rendimiento.
El operador de LINQ que se usa carece de traducción del lado servidor.
En esos casos, puede participar de forma explícita en la evaluación de cliente si llamada a métodos como
AsEnumerable o ToList ( AsAsyncEnumerable o ToListAsync para async). Al usar AsEnumerable se haría streaming
de los resultados, pero al usar ToList se almacenarían en búfer mediante la creación de una lista, que también
consume memoria adicional. Como si se realizara la enumeración varias veces, el almacenamiento de los
resultados en una lista es más útil, ya que solo hay una consulta a la base de datos. En función del uso
determinado, debe evaluar qué método es más útil para cada caso.

.AsEnumerable()
.Where(blog => StandardizeUrl(blog.Url).Contains("dotnet"))
.ToList();
Posible fuga de memoria en la evaluación de cliente

Como la traducción y compilación de consultas son costosas, EF Core almacena en caché el plan de consulta
compilado. El delegado en caché puede usar el código de cliente mientras se realiza la evaluación de cliente de la
proyección de nivel superior. EF Core genera parámetros para las partes evaluadas por el cliente del árbol y
reutiliza el plan de consulta en el que reemplaza los valores de parámetro. Pero determinadas constantes del árbol
de expresión no se pueden convertir en parámetros. Si el delegado en caché contiene ese tipo de constantes, esos
objetos no se pueden recolectar como elementos no utilizados porque todavía se hace referencia a ellos. Si este
tipo de objeto contiene un elemento DbContext u otros servicios, podría hacer que el uso de memoria de la
aplicación crezca con el tiempo. Este comportamiento suele ser un signo de fuga de memoria. EF Core inicia una
excepción cada vez que detecta constantes de un tipo que no se puede asignar mediante el proveedor de base de
datos actual. Las causas comunes y sus soluciones son las siguientes:
Uso de un método de instancia : cuando se usan métodos de instancia en una proyección de cliente, el árbol
de expresión contiene una constante de la instancia. Si el método no usa ningún dato de la instancia, considere
la posibilidad de convertirlo en estático. Si necesita datos de la instancia en el cuerpo del método, pase los datos
específicos como argumento al método.
Paso de argumentos constantes al método : este caso surge generalmente al usar this en un argumento
para el método de cliente. Puede dividir el argumento en varios argumentos escalares, que podrá asignar el
proveedor de base de datos.
Otras constantes : si se detecta una constante en cualquier otro caso, puede evaluar si es necesaria para el
procesamiento. Si es necesario tener la constante, o bien si no puede usar una solución de los casos anteriores,
cree una variable local para almacenar el valor y use la variable local en la consulta. EF Core convertirá la
variable local en un parámetro.
La sección siguiente se aplica a las versiones de EF Core anteriores a la 3.0.
En las versiones anteriores de EF Core se admitía la evaluación de cliente en cualquier parte de la consulta, no solo
en la proyección de nivel superior. Por ese motivo las consultas similares a la publicada en la sección Evaluación de
cliente no admitida funcionaban correctamente. Como este comportamiento podría provocar problemas de
rendimiento inadvertidos, EF Core registró una advertencia de evaluación de cliente. Para obtener más información
sobre cómo ver la salida de registro, vea Registro.
Opcionalmente, en EF Core se permitía cambiar el comportamiento predeterminado para iniciar una excepción o
no hacer nada al realizar la evaluación de cliente (excepto para la proyección). El comportamiento de inicio de
excepción haría que fuese similar al de la versión 3.0. Para cambiar el comportamiento, debe configurar las
advertencias al establecer las opciones del contexto, normalmente en DbContext.OnConfiguring , o bien en
Startup.cs si usa ASP.NET Core.

{
optionsBuilder
.UseSqlServer(@"Server=(localdb)\mssqllocaldb;Database=EFQuerying;Trusted_Connection=True;")
.ConfigureWarnings(warnings => warnings.Throw(RelationalEventId.QueryClientEvaluationWarning));
}
Consultas de seguimiento frente a consultas de no
seguimiento
El comportamiento de seguimiento controla si Entity Framework Core mantendrá información sobre una instancia
de entidad en su herramienta de seguimiento de cambios. Si se hace seguimiento de una entidad, cualquier cambio
detectado en ella persistirá hasta la base de datos durante SaveChanges() . EF Core también corregirá las
propiedades de navegación entre las entidades de un resultado de consulta de seguimiento y las entidades que se
encuentran en la herramienta de seguimiento de cambios.
NOTE
No se realiza el seguimiento de los tipos de entidad sin clave. Siempre que en este artículo se mencionen los tipos de entidad,
se refiere a aquellos con una clave definida.
TIP
Consultas de seguimiento
De manera predeterminada, las consultas que devuelven tipos de entidad son consultas de seguimiento. Esto
significa que puede hacer cambios en esas instancias de entidad y que esos cambios se conservan mediante
SaveChanges() . En el ejemplo siguiente, se detectará el cambio en la clasificación de los blogs y persistirá hasta la
base de datos durante SaveChanges() .
var blog = context.Blogs.SingleOrDefault(b => b.BlogId == 1);

blog.Rating = 5;
Consultas de no seguimiento
Las consultas de no seguimiento son útiles cuando los resultados se usan en un escenario de solo lectura. Su
ejecución es más rápida porque no es necesario configurar la información de seguimiento de cambios. Si no
necesita actualizar las entidades recuperadas de la base de datos, se debe usar una consulta de no seguimiento.
Puede cambiar una consulta individual para que sea una consulta de no seguimiento.

.AsNoTracking()
.ToList();
También puede cambiar el comportamiento de seguimiento predeterminado en el nivel de instancia de contexto:
context.ChangeTracker.QueryTrackingBehavior = QueryTrackingBehavior.NoTracking;
var blogs = context.Blogs.ToList();

Resolución de identidad
Dado que una consulta de seguimiento usa la herramienta de seguimiento de cambios, EF Core realizará la
resolución de identidades en una consulta de este tipo. Al materializar una entidad, EF Core devolverá la misma
instancia de entidad de la herramienta de seguimiento de cambios si ya está en proceso de seguimiento. Si el
resultado contiene la misma entidad varias veces, se devuelve la misma instancia con cada repetición. Las consultas
de no seguimiento no usan la herramienta de seguimiento de cambios y no realizan la resolución de identidades.
Así que, se devuelve una nueva instancia de la entidad incluso cuando la misma entidad está contenida en el
resultado varias veces. Este comportamiento era diferente en las versiones anteriores a EF Core 3.0; consulte las
versiones anteriores.
Seguimiento y proyecciones personalizadas

Incluso si el tipo de resultado de la consulta no es un tipo de entidad, EF Core seguirá realizando el seguimiento de
los tipos de entidad contenidos en el resultado de forma predeterminada. En la consulta siguiente, que devuelve un
tipo anónimo, se hará seguimiento de las instancias de Blog en el conjunto de resultados.

.Select(b =>
new
{
Blog = b,
PostCount = b.Posts.Count()
});
Si el conjunto de resultados contiene tipos de entidad que proceden de la composición LINQ, EF Core realizará un
seguimiento de ellos.

.Select(b =>
new
{
Blog = b,
Post = b.Posts.OrderBy(p => p.Rating).LastOrDefault()
});
Si el conjunto de resultados no contiene ningún tipo de entidad, no se realiza ningún seguimiento. En la consulta
siguiente, se devuelve un tipo anónimo con algunos de los valores de la entidad (pero sin instancias del tipo de
entidad real). No hay entidades con seguimiento que procedan de la consulta.

.Select(b =>
new
{
Id = b.BlogId,
Url = b.Url
});
EF Core admite la evaluación del cliente en la proyección de nivel superior. Si EF Core materializa una instancia de
entidad para la evaluación del cliente, se realizará un seguimiento de esta. Aquí, como se pasan entidades de blog
al método cliente StandardizeURL , EF Core también realizará un seguimiento de las instancias del blog.
.Select(blog => new
{
Id = blog.BlogId,
Url = StandardizeUrl(blog)
})
.ToList();
public static string StandardizeUrl(Blog blog)

{
var url = blog.Url.ToLower();
if (!url.StartsWith("http://"))
{
url = string.Concat("http://", url);
}
return url;
}
EF Core no realiza un seguimiento de las instancias de entidad sin clave contenidas en el resultado. Sin embargo, sí
lo hace de todas las demás instancias de tipos de entidad con clave según las reglas anteriores.
Algunas de las reglas anteriores funcionaban de forma diferente antes de EF Core 3.0. Para más información,
consulte las versiones anteriores.
Antes de la versión 3.0, EF Core presentaba algunas diferencias en el modo en que se realizaba el seguimiento. Las
diferencias destacables son las siguientes:
Como se explica en la página Evaluación de cliente frente a servidor, EF Core admitía la evaluación de
clientes admitidos en cualquier parte de la consulta anterior antes de la versión 3.0. La evaluación de clientes
provocaba la materialización de entidades, las cuales no formaban parte del resultado. Por lo tanto, EF Core
analizaba el resultado para detectar de qué realizar el seguimiento. Este diseño tenía algunas diferencias,
como se indica a continuación:
No se realizaba el seguimiento de la evaluación de clientes en la proyección, lo que provocaba la
materialización pero no se devolvía la instancia de la entidad materializada. En el ejemplo siguiente
no se realizaba un seguimiento de entidades blog .

.Select(blog => new
{
Id = blog.BlogId,
Url = StandardizeUrl(blog)
})
.ToList();
En algunos casos, EF Core no realizaba un seguimiento de los objetos que procedían de la

composición LINQ. En el ejemplo siguiente no se realizaba un seguimiento de Post .
.Select(b =>
new
{
Blog = b,
Post = b.Posts.OrderBy(p => p.Rating).LastOrDefault()
});
Siempre que los resultados de consulta contenían tipos de entidad sin clave, significaba que no se hacía un
seguimiento de la consulta completa. Esto quiere decir que tampoco se realizaba un seguimiento de los tipos
de entidad con claves que estaban en el resultado.
EF Coreó realizaba la resolución de identidades en consultas de no seguimiento. Se usaban referencias
débiles para mantener el seguimiento de entidades que ya se habían devuelto. Por lo tanto, si un conjunto de
resultados contenía la misma entidad varias veces, obtenía la misma instancia para cada caso. Sin embargo,
si un resultado anterior con la misma identidad se salía del ámbito y generaba un elemento no utilizado, EF
Core devolvía una nueva instancia.
Operadores de consulta complejos
Language Integrated Query (LINQ) contiene muchos operadores complejos, que combinan varios orígenes de
datos o realizan procesamientos complejos. No todos los operadores de LINQ tienen traducciones adecuadas en el
lado servidor. En ocasiones, una consulta en un formato se traduce en el servidor, pero si se escribe en otro
formato, no se traduce aunque el resultado sea el mismo. En esta página se describen algunos de los operadores
complejos y sus variaciones admitidas. En futuras versiones, es posible que se reconozcan más patrones y se
agreguen sus correspondientes traducciones. También es importante tener en cuenta que la compatibilidad con la
traducción varía entre proveedores. Es posible que una consulta determinada, que se traduzca en SqlServer, no
funcione para bases de datos SQLite.
TIP
Join
El operador Join de LINQ permite conectar dos orígenes de datos en función del selector de claves de cada origen,
lo que genera una tupla de valores cuando la clave coincide. Se traduce de forma natural a INNER JOIN en las bases
de datos relacionales. Aunque Join de LINQ tiene selectores de clave externa e interna, la base de datos requiere
una única condición de combinación. Por tanto, EF Core genera una condición de combinación que compara el
selector de clave externa con el selector de clave interna para determinar si son iguales. Además, si los selectores de
clave son tipos anónimos, EF Core genera una condición de combinación para comparar los componentes de
igualdad.
var query = from photo in context.Set<PersonPhoto>()

join person in context.Set<Person>()
on photo.PersonPhotoId equals person.PhotoId
select new { person, photo };
SELECT [p].[PersonId], [p].[Name], [p].[PhotoId], [p0].[PersonPhotoId], [p0].[Caption], [p0].[Photo]

FROM [PersonPhoto] AS [p0]
INNER JOIN [Person] AS [p] ON [p0].[PersonPhotoId] = [p].[PhotoId]
GroupJoin
El operador GroupJoin de LINQ permite conectar dos orígenes de datos de forma similar a Join, pero crea un grupo
de valores internos para los elementos externos coincidentes. Al ejecutar una consulta como la del ejemplo
siguiente se genera un resultado de Blog & IEnumerable<Post> . Como las bases de datos (especialmente las
relacionales) no tienen una manera de representar una colección de objetos del lado cliente, en muchos casos
GroupJoin no se traduce en el servidor. Requiere que se obtengan todos los datos del servidor para ejecutar
GroupJoin sin un selector especial (la primera de las consultas siguientes). Pero si el selector limita los datos que se
seleccionan, la captura de todos los datos del servidor puede causar problemas de rendimiento (la segunda de las
consultas siguientes). Por eso EF Core no traduce GroupJoin.
var query = from b in context.Set<Blog>()
join p in context.Set<Post>()
on b.BlogId equals p.PostId into grouping
select new { b, grouping };

on b.BlogId equals p.PostId into grouping
select new { b, Posts = grouping.Where(p => p.Content.Contains("EF")).ToList() };
SelectMany
El operador SelectMany de LINQ permite enumerar un selector de colecciones para cada elemento externo y
generar tuplas de valores de cada origen de datos. En cierto modo es una combinación, pero sin ninguna condición,
por lo que todos los elementos externos se conectan con un elemento del origen de la colección. En función de
cómo se relacione el selector de colecciones con el origen de datos externo, SelectMany puede traducirse en varias
consultas diferentes en el lado servidor.
El selector de colecciones no hace referencia al elemento externo
Cuando el selector de colecciones no hace referencia a nada del origen externo, el resultado es un producto
cartesiano de ambos orígenes de datos. Se traduce a CROSS JOIN en las bases de datos relacionales.

from p in context.Set<Post>()
select new { b, p };
SELECT [b].[BlogId], [b].[OwnerId], [b].[Rating], [b].[Url], [p].[PostId], [p].[AuthorId], [p].[BlogId], [p].

[Content], [p].[Rating], [p].[Title]
FROM [Blogs] AS [b]
CROSS JOIN [Posts] AS [p]
El selector de colecciones hace referencia al elemento externo en una cláusula WHERE

Cuando el selector de colecciones tiene una cláusula WHERE, que hace referencia al elemento exterior, EF Core lo
traduce a una combinación de base de datos y usa el predicado como condición de combinación. Normalmente,
este caso se produce cuando se usa la navegación de colección en el elemento exterior como selector de
colecciones. Si la colección está vacía para un elemento externo, no se generarán resultados para ese elemento
externo. Pero si se aplica DefaultIfEmpty en el selector de colecciones, el elemento exterior se conectará con un
valor predeterminado del elemento interno. Debido a esta distinción, este tipo de consultas se traduce a
INNER JOIN en ausencia de DefaultIfEmpty y LEFT JOIN cuando se aplica DefaultIfEmpty .

from p in context.Set<Post>().Where(p => b.BlogId == p.BlogId)
var query2 = from b in context.Set<Blog>()

from p in context.Set<Post>().Where(p => b.BlogId == p.BlogId).DefaultIfEmpty()
FROM [Blogs] AS [b]
INNER JOIN [Posts] AS [p] ON [b].[BlogId] = [p].[BlogId]

FROM [Blogs] AS [b]
LEFT JOIN [Posts] AS [p] ON [b].[BlogId] = [p].[BlogId]
El selector de colecciones hace referencia al elemento externo en una cláusula distinta de WHERE
Cuando el selector de colecciones hace referencia al elemento exterior, que no está en una cláusula WHERE (como
en el caso anterior), no se traduce a una combinación de base de datos. Por este motivo es necesario evaluar el
selector de colecciones para cada elemento exterior. Se traduce a operaciones APPLY en muchas bases de datos
relacionales. Si la colección está vacía para un elemento externo, no se generarán resultados para ese elemento
externo. Pero si se aplica DefaultIfEmpty en el selector de colecciones, el elemento exterior se conectará con un
valor predeterminado del elemento interno. Debido a esta distinción, este tipo de consultas se traduce a
CROSS APPLY en ausencia de DefaultIfEmpty y OUTER APPLY cuando se aplica DefaultIfEmpty . Algunas bases de
datos como SQLite no admiten los operadores APPLY , por lo que este tipo de consulta no se puede traducir.

from p in context.Set<Post>().Select(p => b.Url + "=>" + p.Title)
var query2 = from b in context.Set<Blog>()

from p in context.Set<Post>().Select(p => b.Url + "=>" + p.Title).DefaultIfEmpty()
SELECT [b].[BlogId], [b].[OwnerId], [b].[Rating], [b].[Url], ([b].[Url] + N'=>') + [p].[Title] AS [p]

FROM [Blogs] AS [b]
CROSS APPLY [Posts] AS [p]
SELECT [b].[BlogId], [b].[OwnerId], [b].[Rating], [b].[Url], ([b].[Url] + N'=>') + [p].[Title] AS [p]

FROM [Blogs] AS [b]
OUTER APPLY [Posts] AS [p]
GROUP BY
Los operadores GroupBy de LINQ crean un resultado de tipo IGrouping<TKey, TElement> , donde TKey y TElement
podrían ser cualquier tipo arbitrario. Además, IGrouping implementa IEnumerable<TElement> , lo que significa que
se puede redactar sobre este elemento con cualquier operador de LINQ después de la agrupación. Como ninguna
estructura de base de datos puede representar una instancia de IGrouping , en la mayoría de los casos los
operadores GroupBy no tienen ninguna traducción. Cuando se aplica un operador de agregado a cada grupo, lo
que devuelve un valor escalar, se puede traducir a GROUP BY de SQL en las bases de datos relacionales. GROUP BY
de SQL también es restrictivo. Requiere que se agrupe solo por valores escalares. La proyección solo puede
contener columnas de clave de agrupación o cualquier agregado aplicado en una columna. EF Core identifica este
patrón y lo traduce al servidor, como en el ejemplo siguiente:
var query = from p in context.Set<Post>()
group p by p.AuthorId into g
select new
{
g.Key,
Count = g.Count()
};
SELECT [p].[AuthorId] AS [Key], COUNT(*) AS [Count]

FROM [Posts] AS [p]
GROUP BY [p].[AuthorId]
EF Core también traduce las consultas en las que un operador de agregado en la agrupación aparece en un
operador Where o OrderBy (u otro orden) de LINQ. Usa la cláusula HAVING en SQL para la cláusula WHERE. La
parte de la consulta antes de aplicar el operador GroupBy puede ser cualquier consulta compleja, siempre que se
pueda traducir al servidor. Además, una vez que se aplican operadores de agregado en una consulta de agrupación
para quitar agrupaciones del origen resultante, se puede redactar sobre ella como cualquier otra consulta.
var query = from p in context.Set<Post>()

group p by p.AuthorId into g
where g.Count() > 0
orderby g.Key
select new
{
g.Key,
Count = g.Count()
};
SELECT [p].[AuthorId] AS [Key], COUNT(*) AS [Count]

FROM [Posts] AS [p]
GROUP BY [p].[AuthorId]
HAVING COUNT(*) > 0
ORDER BY [p].[AuthorId]
Los operadores de agregado que admite EF Core son los siguientes

Average
Count
LongCount
Max
Min
Sum
Left Join
Aunque Left Join no es un operador de LINQ, las bases de datos relacionales tienen el concepto de combinación
izquierda que se usa con frecuencia en las consultas. Un patrón determinado en las consultas LINQ proporciona el
mismo resultado que LEFT JOIN en el servidor. EF Core identifica estos patrones y genera la operación LEFT JOIN
equivalente en el lado servidor. El patrón implica la creación de GroupJoin entre los dos orígenes de datos y,
después, la reducción de la agrupación mediante el operador SelectMany con DefaultIfEmpty en el origen de
agrupación para que coincida con NULL cuando el elemento interior no tiene un elemento relacionado. En el
ejemplo siguiente se muestra el aspecto de este patrón y lo que genera.
on b.BlogId equals p.BlogId into grouping
from p in grouping.DefaultIfEmpty()

FROM [Blogs] AS [b]
LEFT JOIN [Posts] AS [p] ON [b].[BlogId] = [p].[BlogId]
En el patrón anterior se crea una estructura compleja en el árbol de expresión. Por eso, EF Core requiere que se
reduzcan los resultados de agrupación del operador GroupJoin en un paso inmediatamente después del operador.
Aunque se use GroupJoin-DefaultIfEmpty-SelectMany, pero en otro patrón, es posible que no se identifique como
una combinación izquierda.
Carga de datos relacionados
Entity Framework Core permite usar las propiedades de navegación del modelo para cargar las entidades
relacionados. Existen tres patrones de O/RM comunes que se usan para cargar los datos relacionados.
Carga diligente significa que los datos relacionados se cargan desde la base de datos como parte de la
consulta inicial.
Carga explícita significa que los datos relacionados se cargan de manera explícita desde la base de datos
más adelante.
Carga diferida significa que los datos relacionados se cargan de manera transparente desde la base de datos
cuando se accede a la propiedad de navegación.
TIP
Carga diligente
Puede usar el método Include para especificar los datos relacionados que se incluirán en los resultados de la
consulta. En el ejemplo siguiente, las entradas relacionadas rellenarán la propiedad Posts de los blogs que se
devuelvan en los resultados.

{
.Include(blog => blog.Posts)
.ToList();
}
TIP
Entity Framework Core corregirá automáticamente las propiedades de navegación para todas las entidades que se cargaron
previamente en la instancia del contexto. Por tanto, incluso si los datos de una propiedad de navegación no se incluyen
explícitamente, es posible que la propiedad se siga rellenando si algunas o todas las entidades relacionadas se cargaron
previamente.
Puede incluir los datos relacionados de varias relaciones en una sola consulta.

{
.Include(blog => blog.Owner)
.ToList();
}
Inclusión de varios niveles

Puede explorar en profundidad las relaciones para incluir varios niveles de datos relacionados con el método
ThenInclude . En el ejemplo siguiente se cargan todos los blogs, las entradas relacionadas y el creador de cada
entrada.

{
.ThenInclude(post => post.Author)
.ToList();
}
Puede encadenar varias llamadas en ThenInclude para continuar incluyendo más niveles de datos relacionados.

{
.ThenInclude(author => author.Photo)
.ToList();
}
Puede combinar todo esto para incluir datos relacionados provenientes de varios niveles y varias raíces en la
misma consulta.

{
.ThenInclude(author => author.Photo)
.Include(blog => blog.Owner)
.ThenInclude(owner => owner.Photo)
.ToList();
}
Es posible que quiera incluir varias entidades relacionadas para una de las entidades que se está incluyendo. Por
ejemplo, cuando consulte Blogs , incluye Posts y luego quiere incluir tanto Author como Tags de las Posts .
Para hacerlo, debe especificar cada inicio de ruta de acceso de inclusión en la raíz. Por ejemplo,
Blog -> Posts -> Author y Blog -> Posts -> Tags . Esto no significa que vaya a obtener combinaciones
redundantes; en la mayoría de los casos, EF consolidará las combinaciones al generar código SQL.

{
.ThenInclude(post => post.Tags)
.ToList();
}
Cau t i on
Desde la versión 3.0.0, todas las instancias de Include producirán que se agregue una combinación JOIN
adicional a las consultas SQL generadas por los proveedores relacionales, mientras que las versiones anteriores
generaban consultas SQL adicionales. Esto puede cambiar significativamente el rendimiento de las consultas,
tanto para bien como para mal. En concreto, es posible que las consultas LINQ con un número excesivamente alto
de operadores Include deban dividirse en varias consultas LINQ independientes con el fin de evitar el problema
de explosión cartesiana.
Inclusión en tipos derivados
Puede incluir datos relacionados provenientes de las navegaciones que se definen solo en un tipo derivado con
Include y ThenInclude .
Dado el modelo siguiente:
public class SchoolContext : DbContext

{
public DbSet<Person> People { get; set; }
public DbSet<School> Schools { get; set; }

{
modelBuilder.Entity<School>().HasMany(s => s.Students).WithOne(s => s.School);
}
}
public class Person

{
}
public class Student : Person

{
public School School { get; set; }
}
public class School

{
public List<Student> Students { get; set; }

}
El contenido de la navegación School de todas las personas que son estudiantes se puede cargar de manera
diligente mediante el uso de diversos patrones:
con conversión
context.People.Include(person => ((Student)person).School).ToList()
con el operador as
context.People.Include(person => (person as Student).School).ToList()
con la sobrecarga de Include que toma el parámetro del tipo string
context.People.Include("School").ToList()
Carga explícita
Puede cargar de manera explícita una propiedad de navegación a través de la API DbContext.Entry(...) .
{
context.Entry(blog)
.Collection(b => b.Posts)
.Load();
context.Entry(blog)
.Reference(b => b.Owner)
.Load();
}
También puede cargar de manera explícita una propiedad de navegación si ejecuta una consulta independiente
que devuelve las entidades relacionadas. Si está habilitado el seguimiento de cambios, cuando se cargue una
entidad, EF Core establecerá automáticamente las propiedades de navegación de la entidad recién cargada para
hacer referencia a cualquier entidad ya cargada y establecerá las propiedades de navegación de las entidades ya
cargadas para hacer referencia a la entidad recién cargada.
Consulta de las entidades relacionadas
También puede obtener una consulta LINQ que represente el contenido de una propiedad de navegación.
Esto permite, entre otras acciones, ejecutar un operador de agregado en las entidades relacionadas sin cargarlas
en la memoria.

{
var postCount = context.Entry(blog)

.Query()
.Count();
}
También puede filtrar las entidades relacionadas que se cargan en la memoria.

{
var goodPosts = context.Entry(blog)

.Query()
.Where(p => p.Rating > 3)
.ToList();
}
Carga diferida
La manera más simple de usar la carga diferida es instalar el paquete Microsoft.EntityFrameworkCore.Proxies y
habilitarlo con una llamada a UseLazyLoadingProxies . Por ejemplo:
=> optionsBuilder
.UseLazyLoadingProxies()
.UseSqlServer(myConnectionString);
O al usar AddDbContext:
.AddDbContext<BloggingContext>(
b => b.UseLazyLoadingProxies()
.UseSqlServer(myConnectionString));
EF Core habilitará la carga diferida de cualquier propiedad de navegación que se pueda invalidar, es decir, debe
ser virtual y debe estar en una clase desde la que se pueda heredar. Por ejemplo, en las entidades siguientes, las
propiedades de navegación Post.Blog y Blog.Posts serán de carga diferida.
public class Blog

{
public virtual ICollection<Post> Posts { get; set; }

}
public class Post

{
public virtual Blog Blog { get; set; }

}
Carga diferida sin servidores proxy

Los servidores proxy de carga diferida funcionan inyectando el servicio ILazyLoader en una entidad, tal como se
describe en Entity Type Constructors (Constructores de tipo de entidad). Por ejemplo:
public class Blog
{
private ICollection<Post> _posts;
public Blog()
{
}
private Blog(ILazyLoader lazyLoader)

{
LazyLoader = lazyLoader;
}
private ILazyLoader LazyLoader { get; set; }

public ICollection<Post> Posts

{
get => LazyLoader.Load(this, ref _posts);
set => _posts = value;
}
}
public class Post

{
private Blog _blog;
public Post()
{
}
private Post(ILazyLoader lazyLoader)

{
}
private ILazyLoader LazyLoader { get; set; }

public Blog Blog

{
get => LazyLoader.Load(this, ref _blog);
set => _blog = value;
}
}
Esto no requiere tipos de entidad de los cuales heredar ni propiedades de navegación para ser virtual y permite
que las instancias de entidad creadas con new se carguen de manera diferida una vez que se asocian a un
contexto. Sin embargo, requiere una referencia al servicio ILazyLoader , que está definido en el paquete
Microsoft.EntityFrameworkCore.Abstractions. Este paquete contiene un conjunto mínimo de tipos, por lo que es
muy poco el impacto al depender de él. Sin embargo, para evitar por completo depender de cualquier paquete de
EF Core en los tipos de entidad, es posible insertar el método ILazyLoader.Load como delegado. Por ejemplo:
public class Blog
{
private ICollection<Post> _posts;
public Blog()
{
}
private Blog(Action<object, string> lazyLoader)

{
}
private Action<object, string> LazyLoader { get; set; }

public ICollection<Post> Posts

{
get => LazyLoader.Load(this, ref _posts);
set => _posts = value;
}
}
public class Post

{
private Blog _blog;
public Post()
{
}
private Post(Action<object, string> lazyLoader)

{
}
private Action<object, string> LazyLoader { get; set; }

public Blog Blog

{
get => LazyLoader.Load(this, ref _blog);
set => _blog = value;
}
}
El código anterior usa un método de extensión Load para que el uso del delegado sea un poco más limpio:
public static class PocoLoadingExtensions
{
public static TRelated Load<TRelated>(
this Action<object, string> loader,
object entity,
ref TRelated navigationField,
[CallerMemberName] string navigationName = null)
where TRelated : class
{
loader?.Invoke(entity, navigationName);
return navigationField;
}
}
NOTE
El parámetro de constructor del delegado de carga diferida se debe denominar "lazyLoader". La configuración para usar otro
nombre está planificada para una versión futura.
Datos relacionados y serialización

Como EF Core corregirá automáticamente las propiedades de navegación, puede terminar con ciclos en el grafo
de objetos. Por ejemplo, cargar un blog y sus entradas relacionadas dará lugar a un objeto de blog que hará
referencia a una colección de entradas. Cada una de esas entradas tendrá una referencia de vuelta al blog.
Algunos marcos de serialización no permiten ese tipo de ciclos. Por ejemplo, JSON.NET generará la excepción
siguiente si se encuentra un ciclo.
Newtonsoft.Json.JsonSerializationException: Self referencing loop detected for property 'Blog' with type
'MyApplication.Models.Blog'. (Newtonsoft.Json.JsonSerializationException: se detectó un bucle con
autorreferencia para la propiedad "Blog" con el tipo "MyApplication.Models.Blog").
Si usa ASP.NET Core, puede configurar JSON.NET para que omita los ciclos que encuentre en el grafo del objeto.
Esto se hace en el método ConfigureServices(...) en Startup.cs .

{
...
services.AddMvc()
.AddJsonOptions(
options => options.SerializerSettings.ReferenceLoopHandling =
Newtonsoft.Json.ReferenceLoopHandling.Ignore
);
...
}
Otra alternativa consiste en decorar una de las propiedades de navegación con el atributo [JsonIgnore] , que
indica a JSON.NET que no recorra esa propiedad de navegación mientras se serializa.
Consultas asincrónicas
Las consultas asincrónicas evitan bloquear un subproceso mientras la consulta se ejecuta en la base de datos. Las
consultas asincrónicas son importantes para mantener una interfaz de usuario dinámica en las aplicaciones cliente
de gran tamaño. También pueden aumentar el rendimiento de las aplicaciones web donde liberan el subproceso
para atender otras solicitudes de las aplicaciones web. Para más información, consulte Programación asincrónica en
C#.
WARNING
EF Core no admite que varias operaciones en paralelo se ejecuten en la misma instancia de contexto. Siempre debe esperar
que se complete una operación antes de iniciar la siguiente. Habitualmente, para esto se usa la palabra clave await en cada
una de las operaciones asincrónicas.
Entity Framework Core proporciona un conjunto de métodos de extensión asincrónicos similares a los de LINQ, que
ejecutan una consulta y devuelven resultados. Entre los ejemplos se incluyen ToListAsync() , ToArrayAsync() ,
SingleAsync() . No hay versiones asincrónicas de algunos operadores de LINQ como Where(...) o OrderBy(...)
porque estos métodos solo generan el árbol de la expresión de LINQ y no hacen que la consulta se ejecute en la
base de datos.
IMPORTANT
Los métodos de extensión asincrónicos de EF Core se define en el espacio de nombres Microsoft.EntityFrameworkCore . Es
necesario importar este espacio de nombres para que los métodos estén disponibles.
public async Task<List<Blog>> GetBlogsAsync()

{
{
return await context.Blogs.ToListAsync();
}
}
Entity Framework Core le permite descender hasta las consultas SQL sin formato cuando trabaja con una base de
datos relacional. Las consultas SQL sin formato son útiles si la consulta que quiere no se puede expresar mediante
LINQ. Las consultas SQL sin formato también se utilizan si el uso de una consulta LINQ genera una consulta SQL
ineficaz. Las consultas SQL sin formato pueden devolver tipos de entidad normales o tipos de entidad sin clave que
forman parte del modelo.
TIP
Consultas SQL básicas sin formato

Puede usar el método de extensión FromSqlRaw para empezar una consulta LINQ basada en una consulta SQL sin
formato. FromSqlRaw solo se puede usar en raíces de consulta, es decir, directamente en DbSet<> .

.FromSqlRaw("SELECT * FROM dbo.Blogs")
.ToList();
Las consultas SQL sin formato se pueden usar para ejecutar un procedimiento almacenado.

.FromSqlRaw("EXECUTE dbo.GetMostPopularBlogs")
.ToList();
Paso de parámetros
WARNING
Use siempre la parametrización para las consultas SQL sin formato
Al indicar cualquier valor proporcionado por el usuario en una consulta SQL sin formato, debe tener cuidado para evitar
ataques por inyección de código SQL. Además de validar que dichos valores no contienen caracteres no válidos, use siempre
la parametrización que envía los valores separados del texto SQL.
En concreto, no pase nunca a $"" o FromSqlRaw una cadena concatenada o interpolada ( ExecuteSqlRaw ) con valores
proporcionados por el usuario sin validar. Los métodos FromSqlInterpolated y ExecuteSqlInterpolated permiten usar
la sintaxis de interpolación de cadenas de manera que se protege frente a los ataques por inyección de código SQL.
En el ejemplo siguiente se pasa un parámetro único a un procedimiento almacenado; para ello, se incluye un
marcador de posición de parámetro en la cadena de consulta SQL y se proporciona un argumento adicional.
Aunque esta sintaxis se pueda parecer a la de String.Format , el valor suministrado se encapsula en un elemento
DbParameter y el nombre del parámetro generado se inserta donde se haya especificado el marcador de posición
{0} .
var user = "johndoe";

.FromSqlRaw("EXECUTE dbo.GetMostPopularBlogsForUser {0}", user)
.ToList();
FromSqlInterpolated es similar a FromSqlRaw , pero permite usar la sintaxis de interpolación de cadenas. Al igual
que FromSqlRaw , FromSqlInterpolated solo se puede usar en raíces de consulta. Como en el ejemplo anterior, el
valor se convierte a DbParameter y no es vulnerable a la inyección de código SQL.
NOTE
Antes de la versión 3.0, FromSqlRaw y FromSqlInterpolated eran dos sobrecargas denominadas FromSql . Para obtener
más información, vea la sección sobre versiones anteriores.
var user = "johndoe";

.FromSqlInterpolated($"EXECUTE dbo.GetMostPopularBlogsForUser {user}")
.ToList();
También puede construir un elemento DbParameter y suministrarlo como un valor de parámetro. Dado que se usa
un marcador de posición de parámetro SQL normal, en lugar de un marcador de posición de cadena, FromSqlRaw
se puede usar de forma segura:
var user = new SqlParameter("user", "johndoe");

.FromSqlRaw("EXECUTE dbo.GetMostPopularBlogsForUser @user", user)
.ToList();
FromSqlRaw permite usar parámetros con nombre en la cadena de consulta SQL, lo que resulta útil cuando un
procedimiento almacenado tiene parámetros opcionales:
var user = new SqlParameter("user", "johndoe");

.FromSqlRaw("EXECUTE dbo.GetMostPopularBlogsForUser @filterByUser=@user", user)
.ToList();
Redacción con LINQ

Puede redactar sobre la consulta SQL sin formato inicial mediante operadores de LINQ. EF Core la tratará como
una subconsulta y redactará sobre ella en la base de datos. En el ejemplo siguiente se usa una consulta SQL sin
formato que realiza una selección en una función con valores de tabla (TVF). Y después se redacta sobre ella con
LINQ para realizar el filtrado y la ordenación.
var searchTerm = ".NET";

.FromSqlInterpolated($"SELECT * FROM dbo.SearchBlogs({searchTerm})")
.Where(b => b.Rating > 3)
.OrderByDescending(b => b.Rating)
.ToList();
La consulta anterior genera el código SQL siguiente:
SELECT [b].[BlogId], [b].[OwnerId], [b].[Rating], [b].[Url]

FROM (
SELECT * FROM dbo.SearchBlogs(@p0)
) AS [b]
WHERE [b].[Rating] > 3
ORDER BY [b].[Rating] DESC
Inclusión de datos relacionados

El método Include puede usarse para incluir datos relacionados, igual que cualquier otra consulta LINQ:

.Include(b => b.Posts)
.ToList();
La redacción con LINQ requiere que la consulta SQL sin procesar se pueda redactar, ya que EF Core tratará el
código SQL proporcionado como una subconsulta. Las consultas SQL que se pueden redactar empiezan con la
palabra clave SELECT . Es más, el código SQL que se pasa no debe contener ningún carácter ni opción que no sea
válido en una subconsulta, como los siguientes:
Un punto y coma final
En SQL Server, una sugerencia en el nivel de consulta final (por ejemplo, OPTION (HASH JOIN) )
En SQL Server, una cláusula ORDER BY que no se usa con OFFSET 0 O BIEN TOP 100 PERCENT en la cláusula
SELECT
SQL Server no permite la redacción sobre llamadas a procedimientos almacenados, por lo que cualquier intento
de aplicar operadores de consulta adicionales a ese tipo de llamada producirá código SQL no válido. Use el
método AsEnumerable o AsAsyncEnumerable justo después de los métodos FromSqlRaw o FromSqlInterpolated
para asegurarse de que EF Core no intente redactar sobre un procedimiento almacenado.
Seguimiento de cambios
Las consultas que usan los métodos FromSqlRaw o FromSqlInterpolated siguen las mismas reglas de seguimiento
de cambios que las demás consultas LINQ en EF Core. Por ejemplo, si la consulta proyecta tipos de entidad, se
realizará un seguimiento de los resultados de forma predeterminada.
En el ejemplo siguiente se usa una consulta SQL sin formato que realiza una selección en una función con valores
de tabla (TVF) y después deshabilita el seguimiento de cambios con la llamada a AsNoTracking :

.AsNoTracking()
.ToList();
Limitaciones
Existen algunas limitaciones que debe considerar al usar las consultas SQL sin formato:
La consulta SQL debe devolver datos para todas las propiedades del tipo de entidad.
Los nombres de las columnas del conjunto de resultados deben coincidir con los nombres de las columnas a
los que se asignan las propiedades. Tenga en cuenta que este comportamiento es diferente al de EF6. En EF6 se
omitía la asignación de propiedades y columnas para las consultas SQL sin formato, y los nombres de las
columnas del conjunto de resultados tenían que coincidir con los nombres de las propiedades.
La consulta SQL no puede contener datos relacionados. Sin embargo, en muchos casos puede redactar sobre la
consulta si usa el operador Include para devolver datos relacionados (consulte Inclusión de datos
relacionados).
EF Core 2.2 y las versiones anteriores tenían dos sobrecargas de método denominadas FromSql , que se
comportaban de la misma manera que las sobrecargas FromSqlRaw y FromSqlInterpolated más recientes.
Resultaba sencillo llamar de forma accidental al método de cadena sin formato cuando la intención era llamar al
método de cadena interpolada y viceversa. La llamada accidental a la sobrecarga incorrecta podría generar como
resultado consultas que no se parametrizaban cuando debían.
Filtros de consulta global
NOTE
Esta característica se incluyó por primera vez en EF Core 2.0.
Los filtros de consulta global son predicados de consulta LINQ (una expresión booleana que habitualmente se pasa
al operador de consulta LINQ Where) aplicados a los tipos de entidad del modelo de metadatos (habitualmente en
OnModelCreating). Estos filtros se aplican automáticamente a las consultas LINQ que implican a esos tipos de
entidad, incluidos aquellos a los que se hace referencia de forma indirecta, por ejemplo mediante el uso de Include
o de referencias de propiedad de navegación directas. Algunas aplicaciones comunes de esta característica son:
Eliminación temporal : un tipo de entidad define una propiedad IsDeleted.
Ser vicios multiinquilino : un tipo de entidad define una propiedad TenantId.
Ejemplo
En el ejemplo siguiente se muestra cómo usar los filtros de consulta global para implementar los comportamientos
de consulta de multiinquilino y de eliminación temporal en un simple modelo de creación de blogs.
TIP
En primer lugar, defina las entidades:
public class Blog

{
private string _tenantId;


}
public class Post

{
public bool IsDeleted { get; set; }

}
Tenga en cuenta la declaración de un campo tenantId en la entidad Blog. Se usará para asociar cada instancia de
blog con un inquilino específico. También hay definida una propiedad IsDeleted en el tipo de entidad Post. Se usa
para llevar un seguimiento de si una instancia Post se eliminó de manera temporal. Es decir, la instancia se marca
como eliminada sin quitar físicamente los datos subyacentes.
A continuación, configure los filtros de consulta en OnModelCreating con la API HasQueryFilter .

{
modelBuilder.Entity<Blog>().Property<string>("_tenantId").HasColumnName("TenantId");
// Configure entity filters

modelBuilder.Entity<Blog>().HasQueryFilter(b => EF.Property<string>(b, "_tenantId") == _tenantId);
modelBuilder.Entity<Post>().HasQueryFilter(p => !p.IsDeleted);
}
Las expresiones de predicado pasadas a las llamadas de HasQueryFilter ahora se aplicarán automáticamente a
cualquier consulta LINQ para esos tipos.
TIP
Tenga en cuenta el uso de un campo en el nivel de instancia de DbContext: _tenantId se usa para establecer el inquilino
actual. Los filtros de nivel de modelo usan el valor de la instancia de contexto correcta (es decir, la instancia que está
ejecutando la consulta).
NOTE
Actualmente no es posible definir varios filtros de consulta en la misma entidad. Solo se aplicará el último. Sin embargo,
puede definir un único filtro con varias condiciones mediante el operador lógico AND ( && en C#).
Deshabilitación de filtros
Los filtros se pueden deshabilitar para consultas LINQ individuales mediante el operador IgnoreQueryFilters() .
blogs = db.Blogs
.IgnoreQueryFilters()
.ToList();
Limitaciones
Los filtros de consulta global tienen las limitaciones siguientes:
Solo se pueden definir filtros para el tipo de entidad raíz de una jerarquía de herencia.
NOTE
Esta característica ayuda a establecer la correlación de las consultas LINQ en el código con las consultas SQL
generadas capturadas en los registros. El usuario anota una consulta LINQ con el nuevo método TagWith() :
(from f in context.Friends.TagWith("This is my spatial query!")
Esta consulta LINQ se traduce a la siguiente instrucción SQL:
-- This is my spatial query!

Es posible llamar a TagWith() muchas veces en la misma consulta. Las etiquetas de consulta son acumulativas. Por
ejemplo, si tenemos los siguientes métodos:
IQueryable<Friend> GetNearestFriends(Point myLocation) =>

from f in context.Friends.TagWith("GetNearestFriends")
select f;
IQueryable<T> Limit<T>(IQueryable<T> source, int limit) =>

source.TagWith("Limit").Take(limit);
La siguiente consulta:
var results = Limit(GetNearestFriends(myLocation), 25).ToList();
Se traduce en:
-- GetNearestFriends
-- Limit

También es posible utilizar cadenas de varias líneas como etiquetas de consulta. Por ejemplo:
var results = Limit(GetNearestFriends(myLocation), 25).TagWith(
@"This is a multi-line
string").ToList();
Produce el siguiente SQL:
-- GetNearestFriends
-- Limit
-- This is a multi-line
-- string

Restricciones conocidas
Las etiquetas de consulta no se pueden parametrizar : EF Core siempre trata las etiquetas de consulta de la
consulta LINQ como literales de cadena que se incluyen en el código SQL generado. Las consultas compiladas que
toman las etiquetas de consulta como parámetros no están permitidas.
Funcionamiento de las consultas
Entity Framework Core usa Language Integrated Query (LINQ) para consultar datos de la base de datos. LINQ
permite usar C# (o el lenguaje .NET que prefiera) para escribir consultas fuertemente tipadas basadas en el
contexto derivado y las clases de entidad.
La duración de una consulta

A continuación se muestra información general de alto nivel del proceso por el que pasa toda consulta.
1. Entity Framework Core procesa la consulta LINQ para crear una representación que está lista para que el
proveedor de base de datos la procese.
a. El resultado se almacena en caché para que no sea necesario hacer este procesamiento cada vez que se
ejecuta la consulta.
2. El resultado se pasa al proveedor de base de datos.
a. El proveedor de base de datos identifica qué partes de la consulta se pueden evaluar en la base de datos.
b. Estas partes de la consulta se traducen al lenguaje de la consulta específico para la base de datos (por
ejemplo, SQL para una base de datos relacional).
c. Se envía una consulta a la base de datos y se devuelve el conjunto de resultados (los resultados son
valores de la base de datos y no instancias de entidad).
3. Para cada elemento del conjunto de resultados
a. Si se trata de una consulta con seguimiento, EF comprueba si los datos representan una entidad que ya
existe en la herramienta de seguimiento de cambios para la instancia de contexto.
Si es así, se devuelve la entidad existente.
En caso contrario, se crea una entidad nueva, se configura el seguimiento de cambios y se
devuelve la entidad nueva.
b. Si se trata de una consulta que no es de seguimiento, siempre se crea y devuelve una entidad nueva.
Cuándo se ejecutan las consultas

Cuando llama a los operadores LINQ, simplemente crea una representación de la consulta en memoria. La
consulta solo se envía a la base de datos cuando se usan los resultados.
Las operaciones más comunes que generan que la consulta se envíe a la base de datos son:
La iteración de los resultados en un bucle for
El uso de operadores como ToList , ToArray , Single y Count o las sobrecargas asincrónicas equivalentes
WARNING
Valide siempre la entrada del usuario: aunque EF Core protege contra los ataques por inyección de código SQL con el
uso de parámetros y el escape de cadenas literales en consultas, no valida las entradas. Se debe realizar una validación
apropiada, según los requisitos de la aplicación, antes de que los valores de los orígenes que no son de confianza se usen en
consultas LINQ, se asignen a las propiedades de una entidad o se pasen a otras API de EF Core. Esto incluye cualquier
intervención del usuario que se use para construir consultas de manera dinámica. Incluso al usar LINQ, si acepta la
intervención del usuario para crear expresiones, necesita garantizar que solo se pueden construir las expresiones previstas.
Guardado de datos
Cada instancia de contexto tiene un elemento ChangeTracker que es responsable de realizar el seguimiento de los
cambios que deben escribirse en la base de datos. Al realizar cambios en instancias de las clases de entidad, estos
cambios se registran en ChangeTracker y luego se escriben en la base de datos cuando se llama a SaveChanges . El
proveedor de base de datos es responsable de convertir los cambios en operaciones específicas de la base de
datos (por ejemplo, los comandos INSERT , UPDATE y DELETE de una base de datos relacional).
Guardado básico
Obtenga información sobre cómo agregar, modificar y quitar datos mediante las clases de entidad y contexto.
TIP
Agregar datos
Use el método DbSet.Add para agregar instancias nuevas de las clases de entidad. Los datos se insertarán en la
base de datos cuando llame a SaveChanges.

{
var blog = new Blog { Url = "http://example.com" };
context.Blogs.Add(blog);
}
TIP
Los métodos Add, Attach y Update funcionan en todo el grafo de entidades que se pasaron a ellos, tal como se describe en
la sección de datos relacionados. También puede usar la propiedad EntityEntry.State para establecer el estado de una sola
unidad. Por ejemplo, context.Entry(blog).State = EntityState.Modified .
Actualización de datos
EF detectará automáticamente los cambios hechos en una entidad existente de la que hace seguimiento el contexto.
Esto incluye entidades que se cargan o consultan desde la base de datos y las entidades que se agregaron y
guardaron anteriormente en la base de datos.
Solo debe modificar los valores asignados a las propiedades y llamar a SaveChanges.

{
var blog = context.Blogs.First();
blog.Url = "http://example.com/blog";
}
Eliminar datos
Use el método DbSet.Remove para eliminar las instancias de las clases de entidad.
Si la entidad ya existe en la base de datos, se eliminará durante SaveChanges. Si la entidad todavía no se guarda en
la base de datos (es decir, si se hace seguimiento cuando se agrega), se quitará del contexto y ya no se insertará
cuando se llame a SaveChanges.
{
var blog = context.Blogs.First();
context.Blogs.Remove(blog);
}
Varias operaciones en una única llamada a SaveChanges

Puede combinar varias operaciones Add, Update y Remove en una sola llamada a SaveChanges.
NOTE
Para la mayoría de los proveedores de base de datos, SaveChanges es transaccional. Esto significa que todas las operaciones
se realizarán correctamente o presentarán un error y que nunca se aplicarán de manera parcial.

{
// seeding database
context.Blogs.Add(new Blog { Url = "http://example.com/blog" });
context.Blogs.Add(new Blog { Url = "http://example.com/another_blog" });
}

{
// add
context.Blogs.Add(new Blog { Url = "http://example.com/blog_one" });
context.Blogs.Add(new Blog { Url = "http://example.com/blog_two" });
// update
var firstBlog = context.Blogs.First();
firstBlog.Url = "";
// remove
var lastBlog = context.Blogs.Last();
context.Blogs.Remove(lastBlog);
}
Guardado de datos relacionados
Además de las entidades aisladas, también puede usar las relaciones definidas en el modelo.
TIP
Incorporación de un grafo de entidades nuevas

Si crea varias entidades relacionadas, agregar una de ellas al contexto hará que las otras también se agreguen.
En el ejemplo siguiente, el blog y tres entradas relacionadas se insertan en la base de datos. Las entradas se
buscan y agregan, porque son accesibles a través de la propiedad de navegación Blog.Posts .

{
var blog = new Blog
{
Url = "http://blogs.msdn.com/dotnet",
Posts = new List<Post>
{
new Post { Title = "Intro to C#" },
new Post { Title = "Intro to VB.NET" },
new Post { Title = "Intro to F#" }
}
};
}
TIP
Use la propiedad EntityEntry.State para establecer el estado de una sola unidad. Por ejemplo,
context.Entry(blog).State = EntityState.Modified .
Incorporación de una entidad relacionada

Si hace referencia a una entidad nueva desde la propiedad de navegación de una entidad a la que el contexto ya
hace seguimiento, se detectará la entidad y se insertará en la base de datos.
En el ejemplo siguiente, la entidad post se inserta porque se agrega a la propiedad Posts de la entidad blog
que se capturó de la base de datos.
{
var blog = context.Blogs.Include(b => b.Posts).First();
var post = new Post { Title = "Intro to EF Core" };
blog.Posts.Add(post);
}
Cambio de las relaciones

Si cambia la propiedad de navegación de una entidad, los cambios correspondientes se harán en la columna de
clave externa de la base de datos.
En el ejemplo siguiente, la entidad post se actualiza para que pertenezca a la entidad blog nueva, porque su
propiedad de navegación Blog está establecida para que apunte a blog . Tenga en cuenta que blog también se
insertará en la base de datos porque se trata de una entidad nueva a la que hace referencia la propiedad de
navegación de una entidad de la que el contexto ( post ) ya hace seguimiento.

{
var blog = new Blog { Url = "http://blogs.msdn.com/visualstudio" };
var post = context.Posts.First();
post.Blog = blog;
}
Eliminación de relaciones
Para quitar una relación, establezca una navegación de referencia en null o quite la entidad relacionada de una
navegación de colección.
Quitar una relación puede tener efectos secundarios en la entidad dependiente, según el comportamiento de
eliminación en cascada que esté configurado en la relación.
De manera predeterminada, en el caso de las relaciones obligatorias, hay configurado un comportamiento de
eliminación en cascada y la entidad secundaria o dependiente se eliminará de la base de datos. En el caso de las
relaciones opcionales, no hay configurada una eliminación en cascada de manera predeterminada, pero la
propiedad de clave externa se establecerá en NULL.
Consulte la sección sobre las relaciones obligatorias y opcionales para más información sobre cómo se puede
configurar la obligatoriedad de las relaciones.
Consulte el artículo sobre la eliminación en cascada para más detalles sobre el funcionamiento de los
comportamientos de eliminación en cascada, cómo se pueden configurar de manera explícita y cómo se
seleccionan por convención.
En el ejemplo siguiente, se configura una eliminación en cascada en la relación entre Blog y Post , por lo que la
entidad post se elimina de la base de datos.
{
var post = blog.Posts.First();
blog.Posts.Remove(post);
}
En la terminología de las bases de datos, la eliminación en cascada se usa habitualmente para describir una
característica que permite eliminar una fila para desencadenar de manera automática la eliminación de las filas
relacionadas. Un concepto estrechamente relacionado que también abarcan los comportamientos de eliminación
de EF Core es la eliminación automática de una entidad secundaria cuando se interrumpe su relación con una
entidad primaria. Esto normalmente se conoce como la "eliminación de entidades huérfanas".
EF Core implementa varios comportamientos de eliminación distintos y permite configurar estos
comportamientos de las relaciones individuales. EF Core también implementa convenciones que configuran
automáticamente útiles comportamientos de eliminación predeterminados para cada relación en función de la
obligatoriedad de la relación.
Comportamientos de eliminación
Los comportamientos de eliminación se define en el tipo de enumerador DeleteBehavior y se pueden pasar a la
API fluida OnDelete para controlar si la eliminación de una entidad principal o primaria o la interrupción de la
relación con entidades dependientes o secundarias debería tener un efecto secundario en estas últimas.
Hay tres acciones que EF puede llevar a cabo cuando se elimina una entidad principal o primaria o cuando se
interrumpe la relación con una entidad secundaria:
Se puede eliminar la entidad secundaria o dependiente.
Los valores de clave externa de la entidad secundaria se pueden establecer en NULL.
La entidad secundaria se mantiene sin cambios.
NOTE
El comportamiento de eliminación configurado en el modelo EF Core solo se aplica cuando la entidad principal se elimina
mediante EF Core y las entidades dependientes se cargan en la memoria (es decir, en el caso de las entidades dependientes
con seguimiento). Es necesario configurar un comportamiento en cascada correspondiente en la base de datos para
garantizar que la acción necesaria se aplique a los datos a los que el contexto no hace seguimiento. Si usa EF Core para
crear la base de datos, este comportamiento en cascada se configurará automáticamente.
La segunda acción mencionada, establecer un valor de clave externa en NULL, no es válida si la clave externa no
admite un valor NULL. (Una clave externa que no admite un valor NULL equivale a una relación obligatoria). En
estos casos, EF Core hace seguimiento de que la propiedad de la clave externa se haya marcado como NULL hasta
que se llama a SaveChanges, momento en que se genera una excepción porque el cambio no puede durar hasta
la base de datos. Esto es similar a obtener una infracción de restricción de la base de datos.
Existen cuatro comportamientos de eliminación, los que se indican en las tablas siguientes.
Relaciones opcionales
En el caso de las relaciones opcionales (clave externa que admite un valor NULL) es posible guardar un valor de
clave externa NULL, lo que tiene como resultado los efectos siguientes:
EF EC TO EN L A EN T IDA D DEP EN DIEN T E EF EC TO EN L A EN T IDA D DEP EN DIEN T E
N O M B RE DEL C O M P O RTA M IEN TO O SEC UN DA RIA EN L A M EM O RIA O SEC UN DA RIA EN L A B A SE DE DATO S
Cascade Las entidades se eliminan Las entidades se eliminan
ClientSetNull (valor predeterminado) Las propiedades de clave externa se None

establecen en NULL
SetNull Las propiedades de clave externa se Las propiedades de clave externa se

establecen en NULL establecen en NULL
Restrict None None
Relaciones obligatorias
En el caso de las relaciones obligatorias (clave externa que no admite un valor NULL) no es posible guardar un
valor de clave externa NULL, lo que tiene como resultado los efectos siguientes:
EF EC TO EN L A EN T IDA D DEP EN DIEN T E EF EC TO EN L A EN T IDA D DEP EN DIEN T E

N O M B RE DEL C O M P O RTA M IEN TO O SEC UN DA RIA EN L A M EM O RIA O SEC UN DA RIA EN L A B A SE DE DATO S
Cascade (valor predeterminado) Las entidades se eliminan Las entidades se eliminan
ClientSetNull SaveChanges genera una excepción None
SetNull SaveChanges genera una excepción SaveChanges genera una excepción
Restrict None None
En las tablas anteriores, None puede dar lugar a una infracción de restricción. Por ejemplo, si se elimina una
entidad principal o secundaria pero no se hace ninguna acción para cambiar la clave externa de una entidad
dependiente o secundaria, es probable que la base de datos genere una excepción en SaveChanges debido a una
infracción de restricción externa.
En un nivel superior:
Si tiene entidades que no pueden existir sin una entidad primaria y quiere que EF se encargue de eliminar
automáticamente las entidades secundarias, use Cascade.
Habitualmente, las entidades que no pueden existir sin una entidad primaria usan las relaciones
obligatorias, en las que el valor predeterminado es Cascade.
Si tiene entidades que pueden tener o no una entidad primaria y quiere que EF se encargue de anular
automáticamente la clave externa, use ClientSetNull.
Habitualmente, las entidades que pueden existir sin una entidad primaria usan las relaciones
opcionales, en las que el valor predeterminado es ClientSetNull.
Si quiere que la base de datos también intente propagar los valores NULL a las claves externas
secundarias incluso si no se cargó la entidad secundaria, use SetNull. Sin embargo, tenga en cuenta que
la base de datos debe admitir esta opción y que configurar de este modo la base de datos puede dar
lugar a otras restricciones, por lo que, en la práctica, a menudo esta opción no es factible. Es por este
motivo que SetNull no es el valor predeterminado.
Si no quiere que EF Core elimine una entidad o anule la clave externa automáticamente, use Restrict. Tenga en
cuenta que esta acción requiere que el código mantenga las entidades secundarias y sus valores de clave
externa sincronizados de manera manual. Si no es así, se generarán excepciones de restricción.
NOTE
En EF Core, a diferencia de lo que ocurre en EF6, los efectos en cascada no se producen de inmediato, sino que solo cuando
se llama a SaveChanges.
NOTE
Cambios en EF Core 2.0: en versiones anteriores, Restrict haría que las propiedades de claves externas opcionales de las
entidades dependientes con seguimiento se establecieran en NULL y que este fuera el comportamiento de eliminación
predeterminado de las relaciones opcionales. En EF Core 2.0, se introdujo ClientSetNull para representar ese
comportamiento y se transformó en el valor predeterminado de las relaciones opcionales. El comportamiento de Restrict se
ajustó para que nunca haya efectos secundarios en las entidades dependientes.
Ejemplos de eliminación de entidades

El código siguiente forma parte de un ejemplo que se puede descargar y ejecutar. El ejemplo muestra qué pasa
con cada comportamiento de eliminación, tanto en las relaciones opcionales como en las obligatorias, cuando se
elimina una entidad primaria.

var posts = blog.Posts.ToList();
DumpEntities(" After loading entities:", context, blog, posts);
context.Remove(blog);
DumpEntities($" After deleting blog '{blog.BlogId}':", context, blog, posts);
try
{
Console.WriteLine(" Saving changes:");
DumpSql();
DumpEntities(" After SaveChanges:", context, blog, posts);

}
catch (Exception e)
{
DumpSql();
Console.WriteLine($" SaveChanges threw {e.GetType().Name}: {(e is DbUpdateException ?
e.InnerException.Message : e.Message)}");
}
Analicemos cada variación para comprender lo que sucede.

DeleteBehavior.Cascade con relación obligatoria u opcional
After loading entities:
Blog '1' is in state Unchanged with 2 posts referenced.
Post '1' is in state Unchanged with FK '1' and reference to blog '1'.
After deleting blog '1':

Blog '1' is in state Deleted with 2 posts referenced.
Saving changes:
DELETE FROM [Posts] WHERE [PostId] = 1
DELETE FROM [Blogs] WHERE [BlogId] = 1
After SaveChanges:
Blog '1' is in state Detached with 2 posts referenced.
Post '1' is in state Detached with FK '1' and no reference to a blog.
El blog se marca como eliminado

Inicialmente, las entradas no se modifican porque las cascadas no se producen hasta que se genera
SaveChanges
SaveChanges envía eliminaciones para las entidades dependientes o secundarias (entradas) y para la entidad
principal o primaria (blog)
Después de guardar, todas las entidades se desasocian porque se eliminaron de la base de datos
DeleteBehavior.ClientSetNull o DeleteBehavior.SetNull con relación obligatoria


Saving changes:
UPDATE [Posts] SET [BlogId] = NULL WHERE [PostId] = 1
SaveChanges threw DbUpdateException: Cannot insert the value NULL into column 'BlogId', table
'EFSaving.CascadeDelete.dbo.Posts'; column does not allow nulls. UPDATE fails. The statement has been
terminated.

SaveChanges
SaveChanges intenta establecer la clave externa de la entrada en NULL, pero se produce un error porque la
clave externa no admite un valor NULL
DeleteBehavior.ClientSetNull o DeleteBehavior.SetNull con relación opcional

Saving changes:
After SaveChanges:
Blog '1' is in state Detached with 2 posts referenced.
Post '1' is in state Unchanged with FK 'null' and no reference to a blog.

SaveChanges
SaveChanges intenta establecer la clave externa de las entidades dependientes o secundarias (entradas) en
NULL antes de eliminar la entidad principal o primaria (blog)
Después de guardar, se elimina la entidad principal o primaria (blog), pero todavía se hace seguimiento de las
entidades dependientes o secundarias (entradas)
Las entidades dependientes o secundarias (entradas) con seguimiento ahora tienen valores de clave externa
NULL y se quitó la referencia a la entidad principal o primaria (blog) que se eliminó
DeleteBehavior.Restrict con relación obligatoria u opcional


Saving changes:
SaveChanges threw InvalidOperationException: The association between entity types 'Blog' and 'Post' has
been severed but the foreign key for this relationship cannot be set to null. If the dependent entity should
be deleted, then setup the relationship to use cascade deletes.

SaveChanges
Como Restrict le indica a EF que no establezca automáticamente la clave externa en NULL, no se anula y
SaveChanges genera una excepción sin guardar
Ejemplos de eliminación de entidades huérfanas

El código siguiente forma parte de un ejemplo que se puede descargar y ejecutar. El ejemplo muestra qué sucede
en cada comportamiento de eliminación, tanto para las relaciones opcionales como para las obligatorias, cuando
se interrumpe la relación entre una entidad primaria o principal y sus entidades secundarias o dependientes. En
este ejemplo, la relación se interrumpe al quitar las entidades dependientes o secundarias (entradas) de la
propiedad de navegación de la colección en la entidad principal o primaria (blog). Sin embargo, el
comportamiento es el mismo si se anula la referencia de la entidad secundaria o dependiente respecto de la
entidad principal o primaria.

var posts = blog.Posts.ToList();
DumpEntities(" After loading entities:", context, blog, posts);
blog.Posts.Clear();
DumpEntities(" After making posts orphans:", context, blog, posts);
try
{
Console.WriteLine(" Saving changes:");
DumpSql();
DumpEntities(" After SaveChanges:", context, blog, posts);

}
catch (Exception e)
{
DumpSql();
Console.WriteLine($" SaveChanges threw {e.GetType().Name}: {(e is DbUpdateException ?
e.InnerException.Message : e.Message)}");
}
Analicemos cada variación para comprender lo que sucede.

DeleteBehavior.Cascade con relación obligatoria u opcional

After making posts orphans:

Post '1' is in state Modified with FK '1' and no reference to a blog.
Saving changes:
After SaveChanges:
Las entradas se marcan como modificadas porque la interrupción de la relación hizo que la clave externa se
marcara como NULL
Si la clave externa no admite un valor NULL, el valor actual no se modificará incluso si se marca como
NULL
SaveChanges envía eliminaciones para las entidades dependientes o secundarias (entradas)
Después de guardar, las entidades dependientes o secundarias (entradas) se desasocian porque se eliminaron
de la base de datos
DeleteBehavior.ClientSetNull o DeleteBehavior.SetNull con relación obligatoria


Post '1' is in state Modified with FK 'null' and no reference to a blog.
Saving changes:
SaveChanges threw DbUpdateException: Cannot insert the value NULL into column 'BlogId', table
'EFSaving.CascadeDelete.dbo.Posts'; column does not allow nulls. UPDATE fails. The statement has been
terminated.
marcara como NULL
NULL
SaveChanges intenta establecer la clave externa de la entrada en NULL, pero se produce un error porque la
clave externa no admite un valor NULL
DeleteBehavior.ClientSetNull o DeleteBehavior.SetNull con relación opcional


Saving changes:
After SaveChanges:
marcara como NULL
NULL
SaveChanges establece la clave externa de las entidades dependientes o secundarias (entradas) en NULL
Después de guardar, las entidades dependientes o secundarias (entradas) ahora tienen valores NULL de clave
externa y se quitó la referencia a la entidad principal o primaria (blog) que se eliminó
DeleteBehavior.Restrict con relación obligatoria u opcional

Saving changes:
SaveChanges threw InvalidOperationException: The association between entity types 'Blog' and 'Post' has
been severed but the foreign key for this relationship cannot be set to null. If the dependent entity should
be deleted, then setup the relationship to use cascade deletes.
marcara como NULL
NULL
Como Restrict le indica a EF que no establezca automáticamente la clave externa en NULL, no se anula y
SaveChanges genera una excepción sin guardar
Aplicación en cascada a las entidades sin seguimiento

Cuando llama a SaveChanges, se aplicarán las reglas de la aplicación en cascada a cualquier entidad de la que el
contexto hace el seguimiento. Esto es lo que ocurre en todos los ejemplos anteriores, que es la razón por la cual
se generó código SQL para eliminar tanto la entidad principal o primaria (blog) como todas las entidades
dependientes o secundarias (entradas):

Si solo se carga la entidad principal (por ejemplo, cuando se hace una solicitud para un blog sin
Include(b => b.Posts) para que también incluya las entradas), SaveChanges solo generará código SQL para
eliminar la entidad principal o primaria:
Las entidades dependientes o secundarias (entradas) solo se eliminarán si la base de datos tiene configurado un
comportamiento en cascada correspondiente. Si usa EF para crear la base de datos, este comportamiento en
cascada se configurará automáticamente.
Administrar los conflictos de simultaneidad
NOTE
En esta página se documenta cómo funciona la simultaneidad en EF Core y cómo administrar los conflictos de simultaneidad
en la aplicación. Consulte Concurrency Tokens (Tokens de simultaneidad) para detalles sobre cómo configurar los tokens de
simultaneidad en el modelo.
TIP
La simultaneidad de base de datos se refiere a las situaciones en las que varios procesos o usuarios acceden o
cambian los mismos datos de una base de datos al mismo tiempo. El control de simultaneidad se refiere a los
mecanismos específicos que se usan para garantizar la coherencia de los datos en presencia de cambios
simultáneos.
EF Core implementa el control de simultaneidad optimista, lo que significa que permitirá que varios procesos o
usuarios hagan cambios de manera independiente sin la sobrecarga que implica la sincronización o el bloqueo. En
la situación ideal, estos cambios no interferirán entre sí y, por tanto, se realizarán correctamente. En el peor
escenario, dos o más procesos intentarán hacer cambios conflictivos y solo uno de ellos se completará
correctamente.
Funcionamiento del control de simultaneidad en EF Core

Las propiedades configuradas como tokens de simultaneidad se usan para implementar el control de
simultaneidad optimista: cada vez que se realiza una operación de actualización o eliminación durante
SaveChanges , el valor del token de simultaneidad en la base de datos se compara con el valor original leído por EF
Core.
Si los valores coinciden, la operación se puede completar.
Si no coinciden, EF Core supone que otro usuario realizó una operación en conflicto y anula la transacción
actual.
La situación en que otro usuario realizó una operación que entra en conflicto con la operación actual se conoce
como conflicto de simultaneidad.
Los proveedores de base de datos son responsable de implementar la comparación de los valores de los tokens de
simultaneidad.
En las bases de datos relacionales, EF Core incluye una comprobación del valor del token de simultaneidad en la
cláusula WHERE de cualquier instrucción UPDATE o DELETE . Después de ejecutar las instrucciones, EF Core lee el
número de filas que se vieron afectadas.
Si no se afectó ninguna fila, se detecta un conflicto de simultaneidad y EF Core genera la excepción
DbUpdateConcurrencyException .
Por ejemplo, queremos configurar LastName en Person como token de simultaneidad. Luego, toda operación de
actualización en Person incluirá la comprobación de la simultaneidad en la cláusula WHERE :
UPDATE [Person] SET [FirstName] = @p1
WHERE [PersonId] = @p0 AND [LastName] = @p2;
Resolución de los conflictos de simultaneidad

Siguiendo con el ejemplo anterior, si un usuario intenta guardar algunos cambios en una Person pero otro
usuario ya cambió LastName , se generará una excepción.
En este punto, la aplicación simplemente podría informar al usuario que la actualización no se realizó
correctamente debido a cambios en conflicto y siguió adelante. Pero podría ser conveniente pedirle al usuario que
se asegure de que este registro sigue representando a la misma persona real y que reintente la operación.
Este proceso es un ejemplo de cómo resolver un conflicto de simultaneidad.
Resolver un conflicto de simultaneidad implica combinar los cambios pendientes del DbContext actual con los
valores de la base de datos. Los valores que se van a combinar variarán en función de la aplicación y los puede
dirigir el mismo usuario.
Existen tres conjuntos de valores disponibles para ayudar a resolver un conflicto de simultaneidad:
Los valores actuales son los valores que la aplicación intentó escribir en la base de datos.
Los valores originales son los valores que se recuperaron originalmente de la base de datos, antes de realizar
cualquier edición.
Los valores de base de datos son los valores actualmente almacenados en la base de datos.
El enfoque general para controlar un conflicto de simultaneidad es:
1. Detecte DbUpdateConcurrencyException durante SaveChanges .
2. Use DbUpdateConcurrencyException.Entries para preparar un nuevo conjunto de cambios para las entidades
afectadas.
3. Actualice los valores originales del token de simultaneidad para reflejar los valores actuales en la base de datos.
4. Reintente el proceso hasta que no haya ningún conflicto.
En el ejemplo siguiente, Person.FirstName y Person.LastName están configurados como tokens de simultaneidad.
Hay un comentario // TODO: en la ubicación donde se incluye la lógica específica de la aplicación para elegir el
valor que se guardará.
using (var context = new PersonContext())
{
// Fetch a person from database and change phone number
var person = context.People.Single(p => p.PersonId == 1);
person.PhoneNumber = "555-555-5555";
// Change the person's name in the database to simulate a concurrency conflict

context.Database.ExecuteSqlRaw(
"UPDATE dbo.People SET FirstName = 'Jane' WHERE PersonId = 1");
var saved = false;

while (!saved)
{
try
{
// Attempt to save changes to the database
saved = true;
}
catch (DbUpdateConcurrencyException ex)
{
foreach (var entry in ex.Entries)
{
if (entry.Entity is Person)
{
var proposedValues = entry.CurrentValues;
var databaseValues = entry.GetDatabaseValues();
foreach (var property in proposedValues.Properties)

{
var proposedValue = proposedValues[property];
var databaseValue = databaseValues[property];
// TODO: decide which value should be written to database

// proposedValues[property] = <value to be saved>;
}
// Refresh original values to bypass next concurrency check

entry.OriginalValues.SetValues(databaseValues);
}
else
{
throw new NotSupportedException(
"Don't know how to handle concurrency conflicts for "
+ entry.Metadata.Name);
}
}
}
}
}
Usar transacciones
Las transacciones permiten procesar varias operaciones de base de datos de manera atómica. Si se confirma la
transacción, todas las operaciones se aplicaron correctamente a la base de datos. Si se revierte la transacción,
ninguna de las operaciones se aplicó a la base de datos.
TIP
Comportamiento predeterminado de las transacciones

De manera predeterminada, si el proveedor de base de datos admite las transacciones, todos los cambios de una
llamada sencilla a SaveChanges() se aplican a una transacción. Si cualquiera de los cambios presenta un error, la
transacción se revertirá y no se aplicará ninguno de los cambios a la base de datos. Esto significa que se garantiza
que SaveChanges() se complete correctamente o deje sin modificaciones la base de datos si se produce un error.
Este comportamiento predeterminado es suficiente para la mayoría de las aplicaciones. Solo debe controlar
manualmente las transacciones si los requisitos de la aplicación lo consideran necesario.
Control de las transacciones

Puede usar la API DbContext.Database para iniciar, confirmar y revertir las transacciones. En el ejemplo siguiente se
muestran dos operaciones SaveChanges() y una consulta LINQ que se ejecuta en una sola transacción.
No todos los proveedores de base de datos admiten transacciones. Algunos proveedores pueden generar una
excepción o una operación no efectiva cuando se llaman a las API de transacción.
{
using (var transaction = context.Database.BeginTransaction())
{
try
{
context.Blogs.Add(new Blog { Url = "http://blogs.msdn.com/dotnet" });
context.Blogs.Add(new Blog { Url = "http://blogs.msdn.com/visualstudio" });


.ToList();
// Commit transaction if all commands succeed, transaction will auto-rollback

// when disposed if either commands fails
}
catch (Exception)
{
// TODO: Handle failure
}
}
}
Transacción de contexto cruzado (solo bases de datos relacionales)

También puede compartir una transacción en varias instancias de contexto. Esta funcionalidad solo está disponible
cuando se usa un proveedor de base de datos relacionales porque requiere el uso de DbTransaction y
DbConnection , específicos para las bases de datos relacionales.
Para compartir una transacción, los contextos deben compartir tanto DbConnection como DbTransaction .
Permitir conexiones proporcionadas externamente
Compartir una DbConnection requiere la capacidad de pasar una conexión a un contexto cuando se construya.
La manera más sencilla de permitir que DbConnection se proporcione de manera externa es dejar de usar el
método DbContext.OnConfiguring para configurar el contexto y crear externamente DbContextOptions y pasarlas al
constructor del contexto.
TIP
DbContextOptionsBuilder es la API que usó en DbContext.OnConfiguring para configurar el contexto y ahora va a usarla
para crear externamente DbContextOptions .

{
: base(options)
{ }

}
Una alternativa es seguir usando DbContext.OnConfiguring , pero aceptar una DbConnection que se guarda y luego
se usa en DbContext.OnConfiguring .
{
private DbConnection _connection;
public BloggingContext(DbConnection connection)

{
_connection = connection;
}

{
optionsBuilder.UseSqlServer(_connection);
}
}
Compartir conexión y transacción

Ahora puede crear varias instancias de contexto que comparten la misma conexión. Luego use la API
DbContext.Database.UseTransaction(DbTransaction) para inscribir ambos contextos en la misma transacción.

.UseSqlServer(new SqlConnection(connectionString))
.Options;
using (var context1 = new BloggingContext(options))

{
using (var transaction = context1.Database.BeginTransaction())
{
try
{
context1.Blogs.Add(new Blog { Url = "http://blogs.msdn.com/dotnet" });
using (var context2 = new BloggingContext(options))

{
context2.Database.UseTransaction(transaction.GetDbTransaction());
var blogs = context2.Blogs

.ToList();
}

}
catch (Exception)
{
}
}
}
Uso de DbTransactions externas (solo bases de datos relacionales)

Si usa varias tecnologías de acceso a datos para acceder a una base de datos relacional, es posible que quiera
compartir una transacción entre las operaciones que estas distintas tecnologías realizan.
En el ejemplo siguiente se muestra cómo realizar una operación SqlClient de ADO.NET y una operación de Entity
Framework Core en la misma transacción.
using (var connection = new SqlConnection(connectionString))
{
connection.Open();
using (var transaction = connection.BeginTransaction())

{
try
{
// Run raw ADO.NET command in the transaction
var command = connection.CreateCommand();
command.Transaction = transaction;
command.CommandText = "DELETE FROM dbo.Blogs";
command.ExecuteNonQuery();
// Run an EF Core command in the transaction

.UseSqlServer(connection)
.Options;

{
context.Database.UseTransaction(transaction);
}

}
catch (System.Exception)
{
}
}
}
Utilizar System.Transactions
NOTE
Es posible usar transacciones de ambiente si necesita coordinar en un ámbito mayor.

using (var scope = new TransactionScope(
TransactionScopeOption.Required,
new TransactionOptions { IsolationLevel = IsolationLevel.ReadCommitted }))
{
using (var connection = new SqlConnection(connectionString))
{
connection.Open();
try
{

.Options;

{
}

scope.Complete();
}
{
}
}
}
También es posible inscribir en una transacción explícita.

using (var transaction = new CommittableTransaction(
new TransactionOptions { IsolationLevel = IsolationLevel.ReadCommitted }))
{
var connection = new SqlConnection(connectionString);
try
{
.Options;

{
context.Database.EnlistTransaction(transaction);


}

}
{
}
}
Limitaciones de System.Transactions
1. EF Core se basa en los proveedores de base de datos para implementar la compatibilidad con
System.Transactions. Si bien la compatibilidad es bastante común entre los proveedores de ADO.NET para
.NET Framework, la API solo se agregó recientemente a .NET Core y, por tanto, la compatibilidad no siempre
está tan extendida. Si un proveedor no implementa la compatibilidad con System.Transactions, es posible
que las llamadas a estas API se omitan completamente. SqlClient para .NET no lo admite desde la versión 2.1
en adelante. SqlClient para .NET Core 2.0 generará una excepción si intent usar la característica.
IMPORTANT
Se recomienda probar que la API se comporte correctamente con el proveedor antes de usarla para administrar las
transacciones. Si no es así, recomendamos que se ponga en contacto con el mantenedor del proveedor de base de
datos.
2. A partir de la versión 2.1, la implementación de System.Transactions en .NET Core no incluye compatibilidad

con transacciones distribuidas, por lo que no puede usar TransactionScope ni CommittableTransaction para
coordinar las transacciones entre varios administradores de recursos.
Guardado asincrónico
El guardado asincrónico evita bloquear un subproceso mientras se escriben los cambios en la base de datos. Esto
puede resultar útil para evitar la inmovilización de la interfaz de usuario de una aplicación cliente pesada. Las
operaciones asincrónicas también pueden aumentar el rendimiento de una aplicación web, donde se puede liberar
el subproceso para atender otras solicitudes mientras se completa la operación de la base de datos. Para más
información, consulte Programación asincrónica en C#.
WARNING
EF Core no admite que varias operaciones en paralelo se ejecuten en la misma instancia de contexto. Siempre debe esperar
que se complete una operación antes de iniciar la siguiente. Habitualmente, para esto se usa la palabra clave await en cada
una de las operaciones asincrónicas.
Entity Framework Core proporciona DbContext.SaveChangesAsync() como una alternativa asincrónica para
DbContext.SaveChanges() .
public static async Task AddBlogAsync(string url)

{
{
await context.SaveChangesAsync();
}
}
Una DbContext realizará seguimiento automático de las entidades que se devuelven de la base de datos. De ese
modo, los cambios hechos en estas entidades se detectarán cuando se llame a SaveChanges y la base de datos se
actualizará según sea necesario. Consulte Basic Save (Guardado básico) y Related Data (Datos relacionados) para
información detallada.
Sin embargo, en algunas ocasiones las entidades se consultan mediante el uso de una instancia de contexto y
luego se guardan con una instancia distinta. Esto suele ocurrir en escenarios "desconectados", como una aplicación
web, en los que las entidades se consultan, se envían al cliente, se modifican, se envían de vuelta al servidor en una
solicitud y, a continuación, se guardan. En este caso, la segunda instancia de contexto debe saber si las entidades
son nuevas (y se deben insertar) o existentes (y se deben actualizar).
TIP
TIP
EF Core solo puede hacer seguimiento de una instancia de una entidad con un valor de clave principal determinado. La mejor
manera de evitar que esto se convierta en un problema es usar un contexto de corta duración para cada unidad de trabajo
de manera que el contexto empiece vacío, tenga entidades asociadas, guarde esas entidades y, luego, se elimine y descarte el
contexto.
Identificación de unidades nuevas

El cliente identifica las unidades nuevas
El caso más sencillo de abordar es cuando el cliente informa al servidor si la entidad es nueva o existente. Por
ejemplo, a menudo la solicitud para insertar una entidad nueva es distinta de la solicitud para actualizar una
entidad existente.
En el resto de esta sección se analizan los casos en los que resulta necesario determinar de otro modo si se debe
realizar una inserción o una actualización.
Con claves generadas automáticamente
El valor de una clave generada automáticamente a menudo se puede usar para determinar si una entidad se debe
insertar o actualizar. Si no se estableció la clave (es decir, si todavía tiene el valor predeterminado de CLR de NULL,
cero, etc.), la entidad debe ser nueva y se debe insertar. Por el contrario, si el valor de la clave sí se estableció, ya se
debe haber guardado anteriormente y ahora se debe actualizar. En otras palabras, si la clave tiene un valor, es
porque la entidad ya se consultó, se envió al cliente y ahora vuelve para que la actualicen.
Resulta sencillo comprobar si una clave no se estableció cuando se conoce el tipo de entidad:
public static bool IsItNew(Blog blog)

=> blog.BlogId == 0;
Sin embargo, EF también tiene una manera integrada de hacer esto con cualquier tipo de entidad y cualquier tipo
de clave:
public static bool IsItNew(DbContext context, object entity)
=> !context.Entry(entity).IsKeySet;
TIP
Las claves se establecen tan pronto como el contexto hace seguimiento de las entidades, incluso si la entidad tiene el estado
Added (Agregada). Esto resulta útil cuando se recorre un grafo de entidades y se decide qué hacer con cada una de ellas,
como cuándo usar TrackGraph API. El valor de la clave solo se debe usar como se indica aquí antes de cualquier llamada para
hacer seguimiento de la entidad.
Con otras claves

Es necesario algún otro mecanismo para identificar las entidades nuevas cuando los valores de clave no se generan
automáticamente. Aquí existen dos enfoques generales:
Consulta para la entidad
Paso de una marca desde el cliente
Para consulta la entidad, simplemente use el método Find:
public static bool IsItNew(BloggingContext context, Blog blog)

=> context.Blogs.Find(blog.BlogId) == null;
Mostrar el código completo para pasar una marca desde un cliente va más allá del ámbito del presente documento.
En una aplicación web, habitualmente significa hacer distintas solicitudes para acciones diferentes o pasar algún
estado en la solicitud para luego extraerlo en el controlador.
Guardado de entidades únicas

Cuando se sabe si es necesario o no realizar una inserción o una actualización, las acciones de agregar o actualizar
se pueden usar correctamente:
public static void Insert(DbContext context, object entity)

{
context.Add(entity);
}
public static void Update(DbContext context, object entity)

{
context.Update(entity);
}
Sin embargo, si la entidad usa valores de clave generados automáticamente, el método Update se puede usar para
ambos casos:
public static void InsertOrUpdate(DbContext context, object entity)

{
context.Update(entity);
}
Habitualmente, el método Update marca la entidad para actualización y no para inserción. Sin embargo, si la
entidad tiene una clave generada automáticamente y no se estableció ningún valor de clave, la entidad se marca
automáticamente para inserción.
TIP
Este comportamiento se introdujo en EF Core 2.0. En las versiones anteriores siempre es necesario elegir explícitamente si
agregar o actualizar.
Si la entidad no usa claves generadas automáticamente, la aplicación debe decidir si la entidad se debe inserta ro
actualizar. Por ejemplo:
public static void InsertOrUpdate(BloggingContext context, Blog blog)

{
var existingBlog = context.Blogs.Find(blog.BlogId);
if (existingBlog == null)
{
context.Add(blog);
}
else
{
context.Entry(existingBlog).CurrentValues.SetValues(blog);
}
}
Estos son los pasos:

Si Find devuelve un valor NULL, la base de datos todavía no contiene el blog con su identificador, por lo que
llamamos a Add para marcarlo para inserción.
Si Find devuelve una entidad es porque existe en la base de datos y ahora el contexto hace seguimiento de esa
entidad existente.
Luego usamos SetValues para establecer los valores de todas las propiedades de esta entidad en los
valores que provienen del cliente.
La llamada a SetValues marcará la entidad para actualizarla según sea necesario.
TIP
SetValues solo marcará como modificadas las propiedades que tengan valores distintos a los de la entidad con seguimiento.
Esto significa que, cuando se envíe la actualización, solo se actualizarán las columnas que se hayan modificado realmente. (Si
no se modificó nada, no se enviará ninguna actualización).
Trabajo con grafos

Resolución de identidad
Como se indicó anteriormente, EF Core solo puede hacer seguimiento de una instancia de una entidad con un valor
de clave principal determinado. Cuando se trabaja con grafos, idealmente el grafo se debe crear de manera tal que
se mantenga esta invariable y el contexto se debe usar solo para una unidad de trabajo. Si el grafo contiene
duplicados, será necesario procesarlo antes de enviarlo a EF para consolidar varias instancias en una sola. Es
posible que esta acción no sea trivial cuando haya instancias con valores y relaciones en conflicto, por lo que la
consolidación de los duplicados se debe hacer tan pronto como sea posible en la canalización de aplicación para
evitar la resolución de conflictos.
Todas las entidades nuevas o todas las entidades existentes
Un ejemplo de trabajar con grafos es insertar o actualizar un blog junto con su colección de entradas asociadas. Si
las entidades del grafo se deben insertar o actualizar en su totalidad, el proceso es el mismo que se describió
anteriormente para las entidades únicas. Por ejemplo, un grafo de blogs y entradas creado de esta manera:
var blog = new Blog

{
Url = "http://sample.com",
Posts = new List<Post>
{
new Post {Title = "Post 1"},
new Post {Title = "Post 2"},
}
};
se puede insertar así:
public static void InsertGraph(DbContext context, object rootEntity)

{
context.Add(rootEntity);
}
La llamada a Add marcará el blog y todas las entradas para su inserción.

Del mismo modo, si es necesario actualizar todas las entidades de un grafo, se puede usar Update:
public static void UpdateGraph(DbContext context, object rootEntity)

{
context.Update(rootEntity);
}
El blog y todas las entradas se marcarán para su actualización.

Combinación de entidades nuevas y entidades existentes
Con las claves generadas automáticamente, Update se puede volver a usar tanto para inserciones como para
actualizaciones, incluso si el grafo contiene una combinación de entidades que requiere inserción y las que se
deben actualizar:
public static void InsertOrUpdateGraph(DbContext context, object rootEntity)

{
context.Update(rootEntity);
}
Update marcará una entidad en el grafo, ya sea el blog o una entrada, para inserción si no tiene establecido un
valor de clave, mientras que todas las demás entidades se marcarán para actualización.
Como antes, cuando no se usan claves generadas automáticamente, es posible usar una consulta y algún
procesamiento:
public static void InsertOrUpdateGraph(BloggingContext context, Blog blog)
{
var existingBlog = context.Blogs
.FirstOrDefault(b => b.BlogId == blog.BlogId);
{
context.Add(blog);
}
else
{
foreach (var post in blog.Posts)
{
var existingPost = existingBlog.Posts
.FirstOrDefault(p => p.PostId == post.PostId);
if (existingPost == null)
{
existingBlog.Posts.Add(post);
}
else
{
context.Entry(existingPost).CurrentValues.SetValues(post);
}
}
}
}
Control de eliminaciones
Puede ser difícil controlar las eliminaciones porque, habitualmente, la ausencia de una entidad implica que se debe
eliminar. Una manera de solucionar esto es usar las "eliminaciones temporales" en que la entidad se marca como
eliminada en lugar de eliminarla realmente. Luego, las eliminaciones pasan a ser iguales a las actualizaciones. Las
eliminaciones temporales se pueden implementar usando filtros de consulta.
En el caso de las eliminaciones reales, un patrón común es usar una extensión del modelo de consulta para realizar
lo que esencialmente es una diferencia de grafo. Por ejemplo:
public static void InsertUpdateOrDeleteGraph(BloggingContext context, Blog blog)
{
var existingBlog = context.Blogs
.FirstOrDefault(b => b.BlogId == blog.BlogId);
{
context.Add(blog);
}
else
{
{
var existingPost = existingBlog.Posts
.FirstOrDefault(p => p.PostId == post.PostId);
if (existingPost == null)
{
existingBlog.Posts.Add(post);
}
else
{
context.Entry(existingPost).CurrentValues.SetValues(post);
}
}
foreach (var post in existingBlog.Posts)

{
if (!blog.Posts.Any(p => p.PostId == post.PostId))
{
context.Remove(post);
}
}
}
}
TrackGraph
De manera interna, Add, Attach y Update usan el recorrido de grafo con una determinación hecha para cada
entidad a fin de saber si se debe marcar como Added (para inserción), Modified (para actualización), Unchanged
(para no hacer nada) o Deleted (para eliminación). Este mecanismo se expone a través de TrackGraph API. Por
ejemplo, supongamos que cuando el cliente envió de vuelta un grafo de entidades, estableció alguna marca en
cada entidad para indicar cómo se debe controlar. Entonces se puede usar TrackGraph para procesar esta marca:
public static void SaveAnnotatedGraph(DbContext context, object rootEntity)
{
context.ChangeTracker.TrackGraph(
rootEntity,
n =>
{
var entity = (EntityBase)n.Entry.Entity;
n.Entry.State = entity.IsNew
? EntityState.Added
: entity.IsChanged
? EntityState.Modified
: entity.IsDeleted
? EntityState.Deleted
: EntityState.Unchanged;
});
}
Las marcas solo se muestran como parte de la entidad para simplificar el ejemplo. Habitualmente, las marcas
serían parte de una DTO o alguno otro estado incluido en la solicitud.
Establecimiento de valores explícitos para
propiedades generadas
Una propiedad generada es una propiedad cuyo valor se genera (ya sea por medio de EF o de la base de datos)
cuando la entidad se agrega o actualiza. Consulte Generated Properties (Propiedades generadas) para más
información.
Puede haber situaciones en las que desea establecer un valor explícito para una propiedad generada en lugar de
hacer que se genere uno.
TIP
El modelo
El modelo que se usa en este artículo contiene una entidad Employee única.
public class Employee

{
public int EmployeeId { get; set; }
public DateTime EmploymentStarted { get; set; }
public int Salary { get; set; }
public DateTime? LastPayRaise { get; set; }
}
Guardado de un valor explícito durante la acción de agregar

La propiedad Employee.EmploymentStarted está configurada para tener valores generados por la base de datos
para las entidades nuevas (con un valor predeterminado).
modelBuilder.Entity<Employee>()
.Property(b => b.EmploymentStarted)
.HasDefaultValueSql("CONVERT(date, GETDATE())");
El código siguiente inserta dos empleados en la base de datos.

Para el primero, no se asigna ningún valor a la propiedad Employee.EmploymentStarted , por lo que permanece
establecido en el valor predeterminado de CLR para DateTime .
En el caso del segundo, se establece un valor explícito de 1-Jan-2000 .
using (var context = new EmployeeContext())
{
context.Employees.Add(new Employee { Name = "John Doe" });
context.Employees.Add(new Employee { Name = "Jane Doe", EmploymentStarted = new DateTime(2000, 1, 1) });
foreach (var employee in context.Employees)

{
Console.WriteLine(employee.EmployeeId + ": " + employee.Name + ", " + employee.EmploymentStarted);
}
}
La salida muestra que la base de datos generó un valor para el primer empleado y que el valor explícito se usó
para el segundo.
1: John Doe, 1/26/2017 12:00:00 AM

2: Jane Doe, 1/1/2000 12:00:00 AM
Valores explícitos en columnas IDENTITY de SQL Server

Por convención, la propiedad Employee.EmployeeId es una columna IDENTITY generada por el almacén.
En la mayoría de los casos, el enfoque anterior funcionará para las propiedades clave. Sin embargo, para insertar
valores explícitos en una columna IDENTITY de SQL Server, deberá habilitar IDENTITY_INSERT manualmente antes
de llamar a SaveChanges() .
NOTE
Tenemos una solicitud de característica en el trabajo pendiente para hacer esto de manera automática dentro del proveedor
de SQL Server.

{
context.Employees.Add(new Employee { EmployeeId = 100, Name = "John Doe" });
context.Employees.Add(new Employee { EmployeeId = 101, Name = "Jane Doe" });
try
{
context.Database.ExecuteSqlRaw("SET IDENTITY_INSERT dbo.Employees ON");
context.Database.ExecuteSqlRaw("SET IDENTITY_INSERT dbo.Employees OFF");
}
finally
{
}

{
Console.WriteLine(employee.EmployeeId + ": " + employee.Name);
}
}
La salida muestra que los identificadores suministrados se guardaron en la base de datos.

100: John Doe
101: Jane Doe
Establecimiento de un valor explícito durante la acción de actualización

La propiedad Employee.LastPayRaise está configurada para tener valores generados por la base de datos durante
las actualizaciones.
.Property(b => b.LastPayRaise)
.ValueGeneratedOnAddOrUpdate();
.Property(b => b.LastPayRaise)
.Metadata.SetAfterSaveBehavior(PropertySaveBehavior.Ignore);
NOTE
De manera predeterminada, EF Core generará una excepción si se intenta guardar un valor explícito para una propiedad
que se haya configurado para generarse durante la actualización. Para evitar esto, deberá descender a la API de metadatos
de nivel inferior y establecer AfterSaveBehavior (como se mostró anteriormente).
NOTE
Cambios en EF Core 2.0: en las versiones anteriores, el comportamiento posterior a la acción de guardar se controlaba
mediante la marca IsReadOnlyAfterSave . Esta marca ahora está obsoleta y la reemplaza AfterSaveBehavior .
También hay un desencadenador en la base de datos para generar valores para la columna LastPayRaise durante
las operaciones UPDATE .
CREATE TRIGGER [dbo].[Employees_UPDATE] ON [dbo].[Employees]
AFTER UPDATE
AS
BEGIN
SET NOCOUNT ON;
IF ((SELECT TRIGGER_NESTLEVEL()) > 1) RETURN;
IF UPDATE(Salary) AND NOT Update(LastPayRaise)

BEGIN
DECLARE @Id INT
DECLARE @OldSalary INT
DECLARE @NewSalary INT
SELECT @Id = INSERTED.EmployeeId, @NewSalary = Salary

FROM INSERTED
SELECT @OldSalary = Salary

FROM deleted
IF @NewSalary > @OldSalary

BEGIN
UPDATE dbo.Employees
SET LastPayRaise = CONVERT(date, GETDATE())
WHERE EmployeeId = @Id
END
END
END
El código siguiente aumenta el salario de ambos empleados en la base de datos.

Para el primero, no se asigna ningún valor a la propiedad Employee.LastPayRaise , por lo que sigue establecido
en NULL.
Para el segundo, establecemos un valor explícito de una semana atrás (se antedata el aumento salarial).

{
var john = context.Employees.Single(e => e.Name == "John Doe");
john.Salary = 200;
var jane = context.Employees.Single(e => e.Name == "Jane Doe");

jane.Salary = 200;
jane.LastPayRaise = DateTime.Today.AddDays(-7);

{
Console.WriteLine(employee.EmployeeId + ": " + employee.Name + ", " + employee.LastPayRaise);
}
}
La salida muestra que la base de datos generó un valor para el primer empleado y que el valor explícito se usó
para el segundo.
1: John Doe, 1/26/2017 12:00:00 AM

2: Jane Doe, 1/19/2017 12:00:00 AM
Implementaciones de .NET compatibles con EF Core
Queremos que EF Core esté disponible para los desarrolladores en todas las implementaciones de .NET
modernas y seguimos trabajando para alcanzar ese objetivo. Aunque la compatibilidad de EF Core en .NET Core
está cubierta por pruebas automatizadas y se sabe que muchas aplicaciones van a usarlo correctamente, Mono,
Xamarin y UWP presentan algunos problemas.
En la siguiente tabla se ofrecen instrucciones para cada implementación de .NET:
EF C O RE 2. 1 Y 3. 1
.NET Standard 2.0
.NET Core 2.0
.NET Framework(1) 4.7.2
Mono 5.4
Xamarin.iOS(2) 10.14
Xamarin.Android(2) 8.0
UWP(3) 10.0.16299
Unity(4) 2018.1
(1) Consulte la sección .NET Framework a continuación.

(2)Existen problemas y limitaciones conocidas con Xamarin que pueden impedir que algunas aplicaciones
desarrolladas con EF Core funcionen correctamente. Compruebe la lista de problemas activos para ver
soluciones alternativas.
(3)
Se recomienda EF Core 2.0.1 y versiones más recientes. Instale el paquete .NET Core UWP 6.x. Consulte la
sección Plataforma universal de Windows de este artículo.
(4) Hay problemas y limitaciones conocidas con Unity. Revise la lista de problemas activos.
.NET Framework
Es posible que las aplicaciones que tengan como destino .NET Framework deban modificarse para poder trabajar
con bibliotecas de .NET Standard:
Edite el archivo de proyecto y asegúrese de que la siguiente entrada aparece en el grupo de propiedades inicial:
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
En los proyectos de prueba, asegúrese también de que la entrada siguiente está presente:
<GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
Si quiere usar una versión anterior de Visual Studio, asegúrese de que actualiza el cliente de NuGet a la versión
3.6.0 para poder trabajar con bibliotecas de .NET Standard 2.0.
Si es posible, también se recomienda migrar de packages.config de NuGet a PackageReference. Agregue la
propiedad siguiente al archivo del proyecto:
<RestoreProjectStyle>PackageReference</RestoreProjectStyle>
Plataforma universal de Windows

Las versiones anteriores de EF Core y .NET UWP tuvieron numerosos problemas de compatibilidad,
especialmente con aplicaciones compiladas con la cadena de herramientas de .NET Native. La nueva versión de
.NET UWP agrega compatibilidad con .NET Standard 2.0 y contiene .NET Native 2.0, que soluciona la mayoría de
los problemas de compatibilidad que se notificaban anteriormente. EF Core 2.0.1 se ha probado más
exhaustivamente con UWP pero la prueba no está automatizada.
Al usar EF Core en UWP:
Para optimizar el rendimiento de las consultas, evite tipos anónimos en las consultas LINQ. Para
implementar una aplicación de UWP en la tienda de aplicaciones, la aplicación debe estar compilada con
.NET Native. Las consultas con tipos anónimos tienen un menor rendimiento en .NET Native.
Para optimizar el rendimiento de SaveChanges() , use
ChangeTrackingStrategy.ChangingAndChangedNotifications e implemente INotifyPropertyChanged,
INotifyPropertyChanging y INotifyCollectionChanged en los tipos de entidad.
Problemas de informes
En el caso de cualquier combinación que no funcione según lo esperado, se recomienda crear incidencias en el
rastreador de problemas de EF Core. En el caso de problemas relacionados con Xamarin, use el seguimiento de
problemas de Xamarin.Android o de Xamarin.iOS.
Entity Framework Core puede tener acceso a muchas bases de datos diferentes a través de bibliotecas de
complementos denominadas proveedores de bases de datos.
Proveedores actuales
IMPORTANT
Los proveedores de EF Core se componen de una serie de orígenes. No todos los proveedores se mantienen como
parte del proyecto Entity Framework Core. Al considerar un proveedor, evalúe la calidad, las licencias, el soporte técnico,
etc. a fin de asegurarse de que satisface los requisitos. Además, asegúrese de revisar la documentación de cada
proveedor para obtener información detallada de compatibilidad de versiones.
IMPORTANT
Por lo general, los proveedores de EF Core funcionan en versiones secundarias, pero no en todas las versiones
principales. Por ejemplo, un proveedor publicado para EF Core 2.1 debería funcionar con EF Core 2.2, pero no con EF
Core 3.0.
M OTO RES DE
PA Q UET E B A SE DE DATO S M A N T EN EDO R N OTA S O C REA DO PA RA VÍN C ULO S
N UGET C O M PAT IB L ES O P RO VEEDO R REQ UISITO S L A VERSIÓ N ÚT IL ES
Microsoft.EntityF De Proyecto EF 3.1 Documentación

rameworkCore.S SQL Server 2012 Core (Microsoft)
qlServer en adelante
Microsoft.EntityF De SQLite 3.7 en Proyecto EF 3.1 Documentación

rameworkCore.S adelante Core (Microsoft)
qlite
Microsoft.EntityF Base de datos Proyecto EF Limitaciones 3.1 Documentación

rameworkCore.I en memoria de Core (Microsoft)
nMemory EF Core
Microsoft.EntityF API de SQL de Proyecto EF 3.1 Documentación

rameworkCore.C Azure Cosmos Core (Microsoft)
osmos DB
Npgsql.EntityFra PostgreSQL Equipo de 3.1 Documentación

meworkCore.Pos desarrollo de
tgreSQL Npgsql
Pomelo.EntityFra MySQL, Proyecto Pomelo 3.1 Archivo Léame

meworkCore.My MariaDB Foundation
Sql
Devart.Data.MyS De MySQL 5 en DevArt Pagado 3.0 Documentación

ql.EFCore adelante
M OTO RES DE
Devart.Data.Ora Oracle DB DevArt Pagado 3.0 Documentación

cle.EFCore 9.2.0.4 y
versiones
posteriores
Devart.Data.Post De PostgreSQL DevArt Pagado 3.0 Documentación

greSql.EFCore 8.0 en adelante
Devart.Data.SQL De SQLite 3 en DevArt Pagado 3.0 Documentación

ite.EFCore adelante
FileContextCore Almacena datos Morris Janatzek Con fines de 3.0 Archivo Léame
en archivos. desarrollo.
EntityFramework Archivos de Bubi .NET Framework 2.2 Archivo Léame

Core.Jet Microsoft Access
EntityFramework SQL Server Erik Ejlskov .NET Framework 2.2 Wiki

Core.SqlServerC Compact 3,5 Jensen
ompact35
EntityFramework SQL Server Erik Ejlskov .NET Framework 2.2 Wiki

Core.SqlServerC Compact 4.0 Jensen
ompact40
FirebirdSql.Entity Firebird 2.5 y 3.x Jiří Č inčura 2.2 Documentación

FrameworkCore.
Firebird
Teradata.EntityFr Teradata Teradata 2.2 Sitio web

ameworkCore Database 16.10
en adelante
EntityFramework Firebird 2.5 y 3.x Rafael Almeida 2.1 Wiki

Core.FirebirdSql
EntityFramework Progress Alex Wiese 2.1 Archivo Léame

Core.OpenEdge OpenEdge
MySql.Data.Entit MySQL Proyecto MySQL 2.1 Documentación

yFrameworkCor (Oracle)
e
Oracle.EntityFra Oracle DB 11.2 y Oracle 2.1 Sitio web

meworkCore versiones
posteriores
IBM.EntityFrame Db2, Informix IBM Versión de 2.0 blog

workCore Windows
IBM.EntityFrame Db2, Informix IBM Versión de Linux 2.0 blog

workCore-lnx
M OTO RES DE
IBM.EntityFrame Db2, Informix IBM Versión de 2.0 blog

workCore-osx macOS
Pomelo.EntityFra Servidor MyCAT Proyecto Pomelo Solo versión 1.1 Archivo Léame
meworkCore.My Foundation preliminar
Cat
Agregar un proveedor de bases de datos a la aplicación

La mayoría de los proveedores de bases de datos para EF Core se distribuyen como paquetes NuGet y se
pueden instalar siguiendo estos pasos:
CLI de .NET Core
Visual Studio
dotnet add package provider_package_name
Una vez instalado, se configurará el proveedor en su DbContext , ya sea en el método OnConfiguring o el

método AddDbContext si se usa un contenedor de inserción de dependencias. Por ejemplo, la línea siguiente
configura el proveedor de SQL Server con la cadena de conexión pasada:
"Server=(localdb)\mssqllocaldb;Database=MyDatabase;Trusted_Connection=True;");
Los proveedores de bases de datos pueden ampliar EF Core para habilitar una funcionalidad única para bases
de datos específicas. Algunos conceptos son comunes a la mayoría de las bases de datos y se incluyen en los
componentes principales de EF Core. Estos conceptos incluyen la expresión de consultas en LINQ, las
transacciones y el seguimiento de cambios en objetos una vez cargados desde la base de datos. Algunos
conceptos son específicos de un proveedor determinado. Por ejemplo, el proveedor de SQL Server permite
configurar tablas optimizadas para memoria (una característica específica de SQL Server). Otros conceptos
son específicos de una clase de proveedores. Por ejemplo, los proveedores de EF Core para bases de datos
relacionales se basan en la biblioteca común Microsoft.EntityFrameworkCore.Relational , que proporciona API
para configurar asignaciones de tabla y columna, restricciones de clave externa, etc. Los proveedores
normalmente se distribuyen como paquetes NuGet.
IMPORTANT
Cuando se publica una nueva versión de revisión de EF Core, suele incluir actualizaciones del paquete
Microsoft.EntityFrameworkCore.Relational . Cuando se agrega un proveedor de bases de datos relacional, este
paquete se convierte en una dependencia transitiva de la aplicación. Pero muchos proveedores se publican
independientemente de EF Core y es posible que no puedan actualizarse para que se basen en la versión de revisión
más reciente de ese paquete. A fin de asegurarse de que obtendrá todas las correcciones de errores, se recomienda
agregar la versión de revisión de Microsoft.EntityFrameworkCore.Relational como dependencia directa de la
aplicación.
Proveedor de base de datos de Microsoft SQL Server
para EF Core
Este proveedor de base de datos permite usar Entity Framework Core con Microsoft SQL Server (incluido
Azure SQL Database). Este proveedor se mantiene como parte del proyecto Entity Framework Core.
Instalar
Instale el paquete NuGet Microsoft.EntityFrameworkCore.SqlServer.
CLI de .NET Core
Visual Studio
dotnet add package Microsoft.EntityFrameworkCore.SqlServer
NOTE
A partir de la versión 3.0.0, el proveedor hace referencia a Microsoft.Data.SqlClient (las versiones anteriores dependían de
System.Data.SqlClient). Si su proyecto depende directamente de SqlClient, asegúrese de que haga referencia al paquete
Microsoft.Data.SqlClient.
Motores de base de datos compatibles

Microsoft SQL Server (de 2012 en adelante)
Compatibilidad con tablas optimizadas para
memoria en EF Core proveedor de bases de datos de
SQL Server
Las tablas optimizadas para memoria son una característica de SQL Server en la que toda la tabla reside en
memoria. Una segunda copia de los datos de la tabla se conserva en el disco pero solo por la durabilidad. Los
datos de las tablas optimizadas para memoria solo se leen del disco durante la recuperación de la base de datos.
Por ejemplo, después de reiniciar el servidor.
Configurar una tabla optimizada para memoria

Puede especificar que la tabla a la que está asignada una entidad está optimizada para memoria. Al usar EF Core
para crear y mantener una base de datos basada en el modelo (ya sea con migraciones o EnsureCreated), se creará
una tabla optimizada para memoria para estas entidades.

{
modelBuilder.Entity<Blog>().IsMemoryOptimized();
}
Especificación de opciones de Azure SQL Database
NOTE
Esta API es nueva en EF Core 3,1.
Azure SQL Database proporciona una variedad de opciones de precios que normalmente se configuran a través de
Azure portal. Sin embargo, si administra el esquema mediante migraciones de EF Core , puede especificar las
opciones deseadas en el propio modelo.
Puede especificar el nivel de servicio de la base de datos (edición) mediante HasServiceTier:
modelBuilder.HasServiceTier("BusinessCritical");
Puede especificar el tamaño máximo de la base de datos mediante HasDatabaseMaxSize:
modelBuilder.HasDatabaseMaxSize("2 GB");
Puede especificar el nivel de rendimiento de la base de datos (SERVICE_OBJECTIVE) mediante

HasPerformanceLevel:
modelBuilder.HasPerformanceLevel("BC_Gen4_1");
Use HasPerformanceLevelSql para configurar el grupo elástico, ya que el valor no es un literal de cadena:
modelBuilder.HasPerformanceLevelSql("ELASTIC_POOL ( name = myelasticpool )");
TIP
Puede encontrar todos los valores admitidos en la documentación de ALTER DATABASE.
Proveedor de base de datos SQLite para EF Core
Este proveedor de base de datos permite usar Entity Framework Core con SQLite. Este proveedor se mantiene
como parte del proyecto Entity Framework Core.
Instalar
Instale el paquete NuGet Microsoft.EntityFrameworkCore.Sqlite.
CLI de .NET Core
Visual Studio
dotnet add package Microsoft.EntityFrameworkCore.Sqlite

SQLite (3.7 y superiores)
Limitaciones
Vea Limitaciones de SQLite para conocer algunas limitaciones importantes del proveedor de SQLite.
Limitaciones del proveedor de bases de datos de
SQLite EF Core
El proveedor de SQLite tiene varias limitaciones de migración. La mayoría de estas limitaciones son consecuencia
de las limitaciones del motor de base de datos SQLite subyacente y no son específicas de EF.
Limitaciones de modelado
La biblioteca relacional común (compartida por Entity Framework proveedores de bases de datos relacionales)
define las API para los conceptos de modelado que son comunes a la mayoría de los motores de bases de datos
relacionales. Un par de estos conceptos no es compatible con el proveedor de SQLite.
Esquemas
Secuencias
Columnas calculadas
Limitaciones de las consultas

SQLite no admite de forma nativa los siguientes tipos de datos. EF Core puede leer y escribir valores de estos tipos,
y también se admite la consulta de igualdad ( where e.Property == value ). Sin embargo, otras operaciones, como la
comparación y la ordenación, requerirán la evaluación en el cliente.
DateTimeOffset
Decimal
TimeSpan
UInt64
En lugar de DateTimeOffset , se recomienda usar valores DateTime. Al controlar varias zonas horarias,
recomendamos convertir los valores a UTC antes de guardar y, a continuación, volver a convertirlos a la zona
horaria adecuada.
El tipo de Decimal proporciona un alto nivel de precisión. Sin embargo, si no necesita ese nivel de precisión, se
recomienda usar Double en su lugar. Puede usar un convertidor de valores para seguir usando decimal en las
clases.
modelBuilder.Entity<MyEntity>()
.Property(e => e.DecimalProperty)
.HasConversion<double>();
Limitaciones de las migraciones

El motor de base de datos de SQLite no es compatible con una serie de operaciones de esquema que son
compatibles con la mayoría de las demás bases de datos relacionales. Si intenta aplicar una de las operaciones no
admitidas a una base de datos de SQLite, se producirá una NotSupportedException .
O P ERA C IÓ N SE A DM IT E? REQ UIERE VERSIÓ N
AddColumn ✔ 1.0
AddForeignKey ✗
AddPrimaryKey ✗
AddUniqueConstraint ✗
AlterColumn ✗
CreateIndex ✔ 1.0
CreateTable ✔ 1.0
DropColumn ✗
DropForeignKey ✗
DropIndex ✔ 1.0
DropPrimaryKey ✗
DropTable ✔ 1.0
DropUniqueConstraint ✗
RenameColumn ✔ 2.2.2
RenameIndex ✔ 2.1
RenameTable ✔ 1.0
EnsureSchema ✔ (no OP) 2.0
DropSchema ✔ (no OP) 2.0
Insertar ✔ 2.0
Actualizar ✔ 2.0
Eliminar ✔ 2.0
Solución de limitaciones de migraciones

Puede solucionar algunas de estas limitaciones escribiendo manualmente el código en las migraciones para
realizar una recompilación de la tabla. Una recompilación de la tabla implica cambiar el nombre de la tabla
existente, crear otra tabla, copiar los datos en la tabla nueva y eliminar la anterior. Tendrá que usar el método
Sql(string) para realizar algunos de estos pasos.
Vea realizar otros tipos de cambios de esquema de tabla en la documentación de SQLite para obtener más detalles.
En el futuro, EF puede admitir algunas de estas operaciones mediante el enfoque de regeneración de tablas en
segundo plano. Puede realizar un seguimiento de esta característica en nuestro proyecto de github.
Proveedor de Azure Cosmos DB para EF Core
NOTE
Este proveedor es nuevo en EF Core 3.0.
Este proveedor de base de datos permite usar Entity Framework Core con Azure Cosmos DB. Este proveedor se
mantiene como parte del proyecto Entity Framework Core.
Se recomienda encarecidamente que se familiarice con la documentación sobre Azure Cosmos DB antes de leer
esta sección.
NOTE
Este proveedor solo funciona con SQL API de Azure Cosmos DB.
Instalar
Instale el paquete NuGet Microsoft.EntityFrameworkCore.Cosmos.
CLI de .NET Core
Visual Studio
dotnet add package Microsoft.EntityFrameworkCore.Cosmos
Introducción
TIP
Puede ver en GitHub un ejemplo de este artículo.
Al igual que para otros proveedores, el primer paso es llamar a UseCosmos:

=> optionsBuilder.UseCosmos(
"https://localhost:8081",
"C2y6yDjf5/R+ob0N8A7Cgv30VRDJIWEHLM+4QDU5DE2nQ9nDuVTqobD4b8mGGyPMbIZnqyMsEcaGQy67XIw/Jw==",
databaseName: "OrdersDB");
WARNING
El punto de conexión y la clave se codifican aquí de forma rígida por motivos de simplicidad pero, en una aplicación de
producción, se deben almacenar de manera segura.
En este ejemplo, Order es una entidad sencilla con una referencia al tipo owned StreetAddress .
public class Order
{
public int? TrackingNumber { get; set; }
public string PartitionKey { get; set; }
}

{
}
La acción de guardar y consultar datos sigue el patrón de EF normal:
using (var context = new OrderContext())

{
await context.Database.EnsureDeletedAsync();
await context.Database.EnsureCreatedAsync();
{
Id = 1,
ShippingAddress = new StreetAddress { City = "London", Street = "221 B Baker St" },
PartitionKey = "1"
});
}

{
var order = await context.Orders.FirstAsync();
Console.WriteLine($"First order will ship to: {order.ShippingAddress.Street},
{order.ShippingAddress.City}");
}
IMPORTANT
Llamar a EnsureCreatedAsync es necesario para crear los contenedores necesarios e insertar los datos de inicialización si
están presentes en el modelo. Sin embargo, se debe llamar a EnsureCreatedAsync solo durante la implementación y no
durante la operación normal, porque podría provocar problemas de rendimiento.
Personalización del modelo específico de Cosmos

De manera predeterminada, todos los tipos de entidad están asignados al mismo contenedor, con un nombre que
depende del contexto derivado ( "OrderContext" en este caso). Para cambiar el nombre de contenedor
predeterminado, use HasDefaultContainer:
modelBuilder.HasDefaultContainer("Store");
Para asignar un tipo de entidad a un contenedor distinto, use ToContainer:

.ToContainer("Orders");
Para identificar el tipo de entidad que un elemento determinado representa, EF Core agrega un valor de
discriminador incluso si no hay tipos de entidad derivados. El nombre y el valor del discriminador se pueden
modificar.
Si ningún otro tipo de entidad se va a almacenar en el mismo contenedor, se puede quitar el discriminador
mediante la llamada a HasNoDiscriminator:
.HasNoDiscriminator();
Claves de partición
De forma predeterminada, EF Core creará contenedores con la clave de partición establecida en "__partitionKey"
sin proporcionarle ningún valor al insertar elementos. Sin embargo, para sacar el máximo partido a las
funcionalidades de rendimiento de Azure Cosmos, se debe usar una clave de partición seleccionada
cuidadosamente. Se puede configurar mediante la llamada a HasPartitionKey:
.HasPartitionKey(o => o.PartitionKey);
NOTE
La propiedad de clave de partición puede ser de cualquier tipo, siempre y cuando se convierta en una cadena.
Una vez configurada, la propiedad de clave de partición siempre debe tener un valor distinto de NULL. Al emitir
una consulta, se puede agregar una condición para que sea una partición única.

{
{
Id = 2,
ShippingAddress = new StreetAddress { City = "New York", Street = "11 Wall Street" },
PartitionKey = "2"
});
}

{
var order = await context.Orders.Where(p => p.PartitionKey == "2").LastAsync();
Console.Write("Last order will ship to: ");
Console.WriteLine($"{order.ShippingAddress.Street}, {order.ShippingAddress.City}");
}
Entidades insertadas
En Cosmos, las entidades en propiedad se insertan en el mismo elemento que el propietario. Para cambiar el
nombre de una propiedad, use ToJsonProperty:
modelBuilder.Entity<Order>().OwnsOne(
o => o.ShippingAddress,
sa =>
{
sa.ToJsonProperty("Address");
sa.Property(p => p.Street).ToJsonProperty("ShipsToStreet");
sa.Property(p => p.City).ToJsonProperty("ShipsToCity");
});
Con esta configuración, el pedido del ejemplo anterior se almacena de esta manera:
{
"Id": 1,
"PartitionKey": "1",
"TrackingNumber": null,
"id": "1",
"Address": {
"ShipsToCity": "London",
"ShipsToStreet": "221 B Baker St"
},
"_rid": "6QEKAM+BOOABAAAAAAAAAA==",
"_self": "dbs/6QEKAA==/colls/6QEKAM+BOOA=/docs/6QEKAM+BOOABAAAAAAAAAA==/",
"_etag": "\"00000000-0000-0000-683c-692e763901d5\"",
"_attachments": "attachments/",
"_ts": 1568163674
}
Las colecciones de entidades en propiedad también se insertan. En el ejemplo siguiente, usaremos la clase
Distributor con una colección de StreetAddress :
public class Distributor

{
public ICollection<StreetAddress> ShippingCenters { get; set; }
}
No es necesario que las entidades en propiedad proporcionen valores de clave explícitos que se deban almacenar:
var distributor = new Distributor

{
Id = 1,
ShippingCenters = new HashSet<StreetAddress> {
new StreetAddress { City = "Phoenix", Street = "500 S 48th Street" },
new StreetAddress { City = "Anaheim", Street = "5650 Dolly Ave" }
}
};

{
context.Add(distributor);
}
Se conservarán de esta manera:

{
"Id": 1,
"Discriminator": "Distributor",
"id": "Distributor|1",
"ShippingCenters": [
{
"City": "Phoenix",
"Street": "500 S 48th Street"
},
{
"City": "Anaheim",
"Street": "5650 Dolly Ave"
}
],
"_rid": "6QEKANzISj0BAAAAAAAAAA==",
"_self": "dbs/6QEKAA==/colls/6QEKANzISj0=/docs/6QEKANzISj0BAAAAAAAAAA==/",
"_etag": "\"00000000-0000-0000-683c-7b2b439701d5\"",
"_ts": 1568163705
}
De manera interna, EF Core siempre debe tener valores de clave únicos para todas las entidades sometidas a
seguimiento. La clave principal creada de manera predeterminada para las colecciones de tipos en propiedad
consta de las propiedades de clave externa que apuntan al propietario y una propiedad int correspondiente al
índice de la matriz JSON. Para recuperar estos valores, se podría usar la API de entrada:

{
var firstDistributor = await context.Distributors.FirstAsync();
Console.WriteLine($"Number of shipping centers: {firstDistributor.ShippingCenters.Count}");
var addressEntry = context.Entry(firstDistributor.ShippingCenters.First());

var addressPKProperties = addressEntry.Metadata.FindPrimaryKey().Properties;
Console.WriteLine($"First shipping center PK:

({addressEntry.Property(addressPKProperties[0].Name).CurrentValue},
{addressEntry.Property(addressPKProperties[1].Name).CurrentValue})");
}
TIP
Cuando sea necesario, se puede cambiar la clave principal predeterminada para los tipos de entidad en propiedad, pero los
valores de clave se deben proporcionar de manera explícita.
Trabajo con entidades desconectadas

Cada elemento debe tener un valor id único para la clave de partición específica. De manera predeterminada, EF
Core genera el valor mediante la concatenación de los valores de discriminador y de clave principal, con "|" como
delimitador. Los valores de clave solo se generan cuando una entidad entra en el estado Added . Esto podría
suponer un problema al adjuntar entidades si no tienen una propiedad id en el tipo .NET para almacenar el valor.
Para evitar esta limitación, se podría crear y establecer el valor id de manera manual o marcar la entidad como
agregada y, luego, cambiarla al estado deseado:
{
var distributorEntry = context.Add(distributor);
distributorEntry.State = EntityState.Unchanged;
distributor.ShippingCenters.Remove(distributor.ShippingCenters.Last());
}

{
var firstDistributor = await context.Distributors.FirstAsync();
Console.WriteLine($"Number of shipping centers is now: {firstDistributor.ShippingCenters.Count}");
var distributorEntry = context.Entry(firstDistributor);

var idProperty = distributorEntry.Property<string>("id");
Console.WriteLine($"The distributor 'id' is: {idProperty.CurrentValue}");
}
Este es el JSON resultante:
{
"Id": 1,
"Discriminator": "Distributor",
"id": "Distributor|1",
"ShippingCenters": [
{
"City": "Phoenix",
"Street": "500 S 48th Street"
}
],
"_rid": "JBwtAN8oNYEBAAAAAAAAAA==",
"_self": "dbs/JBwtAA==/colls/JBwtAN8oNYE=/docs/JBwtAN8oNYEBAAAAAAAAAA==/",
"_etag": "\"00000000-0000-0000-9377-d7a1ae7c01d5\"",
"_ts": 1572917100
}
Trabajar con datos no estructurados en EF Core
proveedor de Azure Cosmos DB
EF Core se diseñó para facilitar el trabajo con datos que siguen un esquema definido en el modelo. Sin embargo,
uno de los puntos fuertes de Azure Cosmos DB es la flexibilidad en la forma de los datos almacenados.
Acceso a JSON sin formato

Es posible obtener acceso a las propiedades de las que no se realiza un seguimiento EF Core a través de una
propiedad especial en el Estado de sombra denominado "__jObject" que contiene un JObject que representa los
datos recibidos del almacén y los datos que se almacenan:

{
await context.Database.EnsureDeletedAsync();
await context.Database.EnsureCreatedAsync();
var order = new Order

{
Id = 1,
ShippingAddress = new StreetAddress { City = "London", Street = "221 B Baker St" },
PartitionKey = "1"
};
context.Add(order);
}

{
var orderEntry = context.Entry(order);
var jsonProperty = orderEntry.Property<JObject>("__jObject");

jsonProperty.CurrentValue["BillingAddress"] = "Clarence House";
orderEntry.State = EntityState.Modified;
}

{
var orderEntry = context.Entry(order);
var jsonProperty = orderEntry.Property<JObject>("__jObject");
Console.WriteLine($"First order will be billed to: {jsonProperty.CurrentValue["BillingAddress"]}");

}
{
"Id": 1,
"PartitionKey": "1",
"TrackingNumber": null,
"id": "1",
"Address": {
"ShipsToCity": "London",
"ShipsToStreet": "221 B Baker St"
},
"_rid": "eLMaAK8TzkIBAAAAAAAAAA==",
"_self": "dbs/eLMaAA==/colls/eLMaAK8TzkI=/docs/eLMaAK8TzkIBAAAAAAAAAA==/",
"_etag": "\"00000000-0000-0000-683e-0a12bf8d01d5\"",
"BillingAddress": "Clarence House",
"_ts": 1568164374
}
WARNING
La propiedad "__jObject" forma parte de la infraestructura de EF Core y solo se debe utilizar como último recurso, ya que
es probable que tenga un comportamiento diferente en versiones futuras.
NOTE
Los cambios en la entidad invalidarán los valores almacenados en "__jObject" durante SaveChanges .
Usar CosmosClient
Para desacoplar completamente de EF Core obtener el objeto CosmosClient que forma parte del SDK de Azure
Cosmos dB de DbContext :

{
var cosmosClient = context.Database.GetCosmosClient();
var database = cosmosClient.GetDatabase("OrdersDB");
var container = database.GetContainer("Orders");
var resultSet = container.GetItemQueryIterator<JObject>(new QueryDefinition("select * from o"));

var order = (await resultSet.ReadNextAsync()).First();
Console.WriteLine($"First order JSON: {order}");
order.Remove("TrackingNumber");
await container.ReplaceItemAsync(order, order["id"].ToString());

}
Faltan valores de propiedad

En el ejemplo anterior, se ha quitado la propiedad "TrackingNumber" del pedido. Debido a cómo funciona la
indexación en Cosmos DB, las consultas que hacen referencia a la propiedad que falta en otro lugar y en la
proyección podrían devolver resultados inesperados. Por ejemplo:
{
var orders = await context.Orders.ToListAsync();
var sortedOrders = await context.Orders.OrderBy(o => o.TrackingNumber).ToListAsync();
Console.WriteLine($"Number of orders: {orders.Count}");

Console.WriteLine($"Number of sorted orders: {sortedOrders.Count}");
}
La consulta ordenada realmente no devuelve ningún resultado. Esto significa que debe tener cuidado de rellenar
siempre las propiedades asignadas por EF Core al trabajar directamente con el almacén.
NOTE
Este comportamiento puede cambiar en versiones futuras de Cosmos. Por ejemplo, actualmente, si la Directiva de indexación
define el índice compuesto {ID/? ASC, TrackingNumber/? ASC)}, una consulta que tiene ' ORDER BY c.Id ASC, c. Discriminator
ASC ' devolvería elementos a los que les falta la propiedad "TrackingNumber" .
Limitaciones del proveedor de Azure Cosmos DB de
EF Core
El proveedor de Cosmos tiene una serie de limitaciones. Muchas de estas limitaciones son consecuencia de las
limitaciones del motor de base de datos de Cosmos subyacente y no son específicas de EF. Pero la mayoría no se ha
implementado todavía.
Limitaciones temporales
Incluso si solo hay un tipo de entidad sin herencia asignada a un contenedor, todavía tiene una propiedad
discriminadora.
Los tipos de entidad con claves de partición no funcionan correctamente en algunos escenarios
no se admiten llamadas Include
no se admiten llamadas Join
Limitaciones del SDK de Azure Cosmos DB

Solo se proporcionan métodos asincrónicos
WARNING
Dado que no hay ninguna versión de sincronización de los métodos de nivel bajo EF Core se basa en, la funcionalidad
correspondiente se implementa actualmente llamando a .Wait() en el Task devuelto. Esto significa que el uso de métodos
como SaveChanges , o ToList en lugar de sus homólogos asincrónicos podría provocar un interbloqueo en la aplicación
Limitaciones de Azure Cosmos DB

Puede ver la información general completa de Azure Cosmos dB características admitidas, estas son las diferencias
más importantes en comparación con una base de datos relacional:
No se admiten las transacciones iniciadas por el cliente
Algunas consultas entre particiones no se admiten o son mucho más lentas en función de los operadores
implicados
Proveedor de base de datos InMemory para EF Core
Este proveedor de base de datos permite usar Entity Framework Core con una base de datos en memoria. Puede
resultar útil en el caso de pruebas, aunque es posible que el proveedor SQLite del modo en memoria sea un
reemplazo de pruebas más adecuado para bases de datos relacionales. Este proveedor se mantiene como parte
del proyecto Entity Framework Core.
Instalar
Instale el paquete NuGet Microsoft.EntityFrameworkCore.InMemory.
CLI de .NET Core
Visual Studio
dotnet add package Microsoft.EntityFrameworkCore.InMemory
Introducción
Los siguientes recursos le ayudarán a empezar a trabajar con este proveedor.
Pruebas de la aplicación de ejemplo UnicornStore

Base de datos de memoria en proceso (diseñada para pruebas únicamente)
Escritura de un proveedor de base de datos
Para obtener información sobre cómo escribir un proveedor de bases de datos de Entity Framework Core, consulte
para que pueda escribir un proveedor de EF Core por Arthur Vickers.
NOTE
Estos envíos no se han actualizado desde EF Core 1,1 y ha habido cambios significativos desde que se produjo el error 681 al
realizar un seguimiento de las actualizaciones de esta documentación.
La EF Core código base es de código abierto y contiene varios proveedores de bases de datos que se pueden
utilizar como referencia. Puede encontrar el código fuente en https://github.com/aspnet/EntityFrameworkCore.
También puede ser útil examinar el código para proveedores de terceros de uso frecuente, como Npgsql, Pomelo
MySQLy SQL Server Compact. En concreto, estos proyectos se configuran para extender desde y ejecutar pruebas
funcionales que publicamos en NuGet. Se recomienda encarecidamente este tipo de instalación.
Mantenerse al día con los cambios del proveedor

A partir del trabajo después de la versión 2,1, hemos creado un registro de cambios que pueden necesitar cambios
correspondientes en el código del proveedor. Esto está pensado para ayudarle a actualizar un proveedor existente
para que funcione con una nueva versión de EF Core.
Antes de 2,1, usamos las etiquetas providers-beware y providers-fyi en nuestros problemas de Github y
solicitudes de incorporación de cambios para un propósito similar. Vamos a usar estas etiquetas en los problemas
para proporcionar una indicación de qué elementos de trabajo de una versión determinada también pueden
requerir que el trabajo se realice en los proveedores. Una etiqueta de providers-beware normalmente significa que
la implementación de un elemento de trabajo puede interrumpir los proveedores, mientras que una etiqueta de
providers-fyi normalmente significa que los proveedores no se interrumpirán, pero puede que sea necesario
cambiar el código, por ejemplo, para habilitar la nueva funcionalidad.
Nombres sugeridos de proveedores de terceros

Se recomienda usar la siguiente nomenclatura para los paquetes NuGet. Esto es coherente con los nombres de los
paquetes proporcionados por el equipo de EF Core.
<Optional project/company name>.EntityFrameworkCore.<Database engine name>
Por ejemplo:
Npgsql.EntityFrameworkCore.PostgreSQL
EntityFrameworkCore.SqlServerCompact40
Cambios que afectan al proveedor
Esta página contiene vínculos a las solicitudes de incorporación de cambios realizadas en el repositorio de EF Core
que puede requerir que reaccionen los autores de otros proveedores de bases de datos. La intención es
proporcionar un punto de partida para los autores de proveedores de bases de datos de terceros existentes al
actualizar su proveedor a una nueva versión.
Estamos iniciando este registro con los cambios de 2,1 a 2,2. Antes de 2,1 usamos las etiquetas providers-beware
y providers-fyi en nuestros problemas y solicitudes de incorporación de cambios.
2.2 ---> 3.0

Tenga en cuenta que muchos de los cambios importantes en el nivel de la aplicación también afectarán a los
proveedores.
https://github.com/aspnet/EntityFrameworkCore/pull/14022
Se han quitado las API obsoletas y las sobrecargas de parámetros opcionales contraídas
Se quitó DatabaseColumn. GetUnderlyingStoreType ()
Se han quitado las API obsoletas
Es posible que las subclases de CharTypeMapping se hayan interrumpido debido a cambios de
comportamiento necesarios para corregir un par de errores en la implementación base.
Se ha agregado una clase base para IDatabaseModelFactory y se ha actualizado para usar un objeto de
parámetro para mitigar los saltos futuros.
Usó objetos de parámetro en MigrationsSqlGenerator para mitigar los saltos futuros.
La configuración explícita de los niveles de registro requiere algunos cambios en las API que los
proveedores pueden estar usando. En concreto, si los proveedores usan la infraestructura de registro
directamente, este cambio puede interrumpir ese uso. Además, los proveedores que usan la
infraestructura (que será pública) al avanzar deberán derivar de LoggingDefinitions o
RelationalLoggingDefinitions . Para obtener ejemplos, vea los SQL Server y los proveedores en
memoria.
Las cadenas de recursos Core, relacional y abstracciones son ahora públicas.
CoreLoggerExtensions y RelationalLoggerExtensions son ahora públicos. Los proveedores deben usar
estas API al registrar eventos definidos en el nivel básico o relacional. No tener acceso a los recursos de
registro directamente; todavía son internas.
IRawSqlCommandBuilder ha cambiado de un servicio singleton a un servicio con ámbito
IMigrationsSqlGenerator ha cambiado de un servicio singleton a un servicio con ámbito
La infraestructura para la creación de comandos relacionales se ha convertido en pública, de modo que
los proveedores pueden utilizarla de forma segura y refactorizar ligeramente.
ILazyLoader ha cambiado de un servicio con ámbito a un servicio transitorio
IUpdateSqlGenerator ha cambiado de un servicio con ámbito a un servicio singleton
Además, se ha quitado ISingletonUpdateSqlGenerator
Una gran cantidad de código interno que usaban los proveedores ahora se ha hecho público
Ya no debe ser necssary para hacer referencia a IndentedStringBuilder porque se ha factorizado fuera
de los lugares que lo exponían
Los usos de NonCapturingLazyInitializer deben reemplazarse por LazyInitializer de la BCL
Este cambio está totalmente incluido en el documento sobre cambios importantes de la aplicación. En el
caso de los proveedores, esto puede ser más impactante, ya que la prueba de EF Core a menudo puede
dar lugar a este problema, por lo que la infraestructura de prueba ha cambiado para que sea menos
probable.
https://github.com/aspnet/EntityFrameworkCore/issues/13961
EntityMaterializerSource se ha simplificado
La traducción StartsWith ha cambiado de manera que los proveedores pueden querer o deben
reaccionar
Los servicios del conjunto de convenciones han cambiado. Los proveedores ahora deben heredar de
"ProviderConventionSet" o "RelationalConventionSet".
Las personalizaciones se pueden agregar a través de IConventionSetCustomizer Services, pero está
pensada para que las usen otras extensiones, no los proveedores.
Las convenciones que se usan en tiempo de ejecución se deben resolver desde IConventionSetBuilder .
La propagación de datos se ha refactorizado en una API pública para evitar la necesidad de usar tipos
internos. Esto solo debe afectar a los proveedores no relacionales, puesto que la propagación se controla
mediante la clase relacional base para todos los proveedores relacionales.
2.1 ---> 2.2

Cambios de solo prueba
https://github.com/aspnet/EntityFrameworkCore/pull/12057: permitir delimitadores de SQL personalizables en
las pruebas
Comprobar los cambios que permiten comparaciones de punto flotante no estrictas en
BuiltInDataTypesTestBase
Probar los cambios que permiten que las pruebas de consulta se vuelvan a usar con diferentes
delimitadores de SQL
https://github.com/aspnet/EntityFrameworkCore/pull/12072: agregar pruebas DbFunction a las pruebas de
especificación relacionales
De este modo, estas pruebas se pueden ejecutar en todos los proveedores de bases de datos
https://github.com/aspnet/EntityFrameworkCore/pull/12362: limpieza de pruebas asincrónicas
Quitar llamadas Wait , Async innecesario y cambiar el nombre de algunos métodos de prueba
https://github.com/aspnet/EntityFrameworkCore/pull/12666: unificar la infraestructura de prueba de registro
Se ha agregado CreateListLoggerFactory y se ha quitado una infraestructura de registro anterior, que
requerirá que los proveedores que usan estas pruebas reaccionen
https://github.com/aspnet/EntityFrameworkCore/pull/12500: ejecutar más pruebas de consulta de forma
sincrónica y asincrónica
Los nombres de prueba y la factorización han cambiado, lo que requerirá que los proveedores usen
estas pruebas para reaccionar
https://github.com/aspnet/EntityFrameworkCore/pull/12766: cambiar el nombre de las navegaciones en el
modelo ComplexNavigations
Es posible que los proveedores que usan estas pruebas tengan que reaccionar
https://github.com/aspnet/EntityFrameworkCore/pull/12141: devolver el contexto al grupo en lugar de
desecharlo en pruebas funcionales
Este cambio incluye alguna refactorización de prueba que puede requerir que los proveedores
reaccionen
Cambios de código de prueba y de producto
https://github.com/aspnet/EntityFrameworkCore/pull/12109: consolidar métodos RelationalTypeMapping.
Clone
Se permiten cambios en 2,1 en RelationalTypeMapping para una simplificación en las clases derivadas.
No creemos que esto se interrumpiera en los proveedores, pero los proveedores pueden aprovechar
este cambio en sus clases derivadas de asignación de tipos.
consultas etiquetadas o con nombre https://github.com/aspnet/EntityFrameworkCore/pull/12069
Agrega la infraestructura para etiquetar las consultas LINQ y hacer que esas etiquetas se muestren
como comentarios en SQL. Esto puede requerir que los proveedores reaccionen en la generación de
SQL.
https://github.com/aspnet/EntityFrameworkCore/pull/13115: compatibilidad con datos espaciales a través de
NTS
Permite que las asignaciones de tipos y los traductores de miembros se registren fuera del proveedor.
Los proveedores deben llamar a base. FindMapping () en su implementación de
ITypeMappingSource para que funcione
Siga este patrón para agregar compatibilidad espacial a su proveedor que sea coherente entre los
proveedores.
https://github.com/aspnet/EntityFrameworkCore/pull/13199: agregar depuración mejorada para la creación de
proveedores de servicios
Permite a DbContextOptionsExtensions implementar una nueva interfaz que puede ayudar a los
usuarios a entender por qué se vuelve a crear el proveedor de servicios internos.
https://github.com/aspnet/EntityFrameworkCore/pull/13289: agrega la API CanConnect para su uso por las
comprobaciones de estado
Este PR agrega el concepto de CanConnect que se usará en las comprobaciones de estado de ASP.NET
Core para determinar si la base de datos está disponible. De forma predeterminada, la implementación
relacional solo llama a Exist , pero los proveedores pueden implementar algo diferente si es necesario.
Los proveedores no relacionales deberán implementar la nueva API para poder usar la comprobación de
estado.
https://github.com/aspnet/EntityFrameworkCore/pull/13306: actualizar RelationalTypeMapping base para no
establecer el tamaño de DbParameter
Deje de establecer el tamaño de forma predeterminada, ya que puede provocar el truncamiento. Los
proveedores pueden necesitar agregar su propia lógica si es necesario establecer el tamaño.
https://github.com/aspnet/EntityFrameworkCore/pull/13372-RevEng: especificar siempre el tipo de columna
para las columnas decimales
Configure siempre el tipo de columna para las columnas decimales en código con scaffolding en lugar
de configurar por Convención.
Los proveedores no deben requerir cambios en su extremo.
https://github.com/aspnet/EntityFrameworkCore/pull/13469: agrega CaseExpression para generar expresiones
CASE de SQL.
https://github.com/aspnet/EntityFrameworkCore/pull/13648: agrega la capacidad de especificar las
asignaciones de tipos en SqlFunctionExpression para mejorar la inferencia de tipos de almacén de argumentos
y resultados.
Herramientas y extensiones de EF Core
Estas herramientas y extensiones proporcionan más funcionalidades para Entity Framework Core 2.1 y versiones
posteriores.
IMPORTANT
Las extensiones están compiladas a partir de una gran variedad de orígenes, por lo que su mantenimiento no está incluido en
el proyecto Entity Framework Core. En lo que respecta a las extensiones de terceros y para asegurarse de que cumplan sus
requisitos, no se olvide de evaluar la calidad, las licencias, la compatibilidad, el soporte técnico, etc. En concreto, es posible que
sea necesario actualizar una extensión compilada para una versión anterior de EF Core para que funcione con las versiones
más recientes.
Herramientas
LLBLGen Pro
LLBLGen Pro es una solución de modelado de entidad compatible con Entity Framework y Entity Framework Core.
Permite definir fácilmente el modelo de entidad y asignarlo a la base de datos mediante Database First o Model
First, de modo que pueda empezar a escribir consultas de inmediato. Para EF Core: 2.
Sitio web
Devart Entity Developer
Entity Developer es un potente diseñador ORM para ADO.NET Entity Framework, NHibernate, LinqConnect, Telerik
Data Access y LINQ to SQL. Permite diseñar modelos EF Core de forma visual mediante los enfoques Database First
y Model First, así como generar código C# y de Visual Basic. Para EF Core: 2.
Sitio web
nHydrate ORM para Entity Framework
ORM que crea clases extensibles y fuertemente tipadas para Entity Framework. El código generado es
Entity Framework Core. No hay ninguna diferencia. Esto no es un reemplazo de EF ni un ORM personalizado. Es
una capa de modelado visual que permite a un equipo administrar esquemas de base de datos complejos.
Funciona bien con software SCM como GIT, lo que permite el acceso de varios usuarios al modelo con conflictos
mínimos. El instalador realiza un seguimiento de los cambios del modelo y crea scripts de actualización. Para EF
Core: 3.
Sitio de GitHub
EF Core Power Tools
EF Core Power Tools es una extensión de Visual Studio que expone varias tareas de tiempo de diseño de EF Core en
una interfaz de usuario sencilla. Incluye técnicas de ingeniería inversa de DbContext y clases de entidades a partir
de bases de datos existentes y DACPAC de SQL Server, así como la administración de la migración de bases de
datos y la visualización de modelos. Para EF Core: 2, 3.
Wiki de GitHub
Editor visual de Entity Framework
El Editor de objetos visuales de Entity Framework es una extensión de Visual Studio que agrega un diseñador ORM
que permite generar objetos visuales de las clases EF 6 y EF Core. El código se genera mediante plantillas T4, por lo
que se puede personalizar. Asimismo, admite enumeraciones y asociaciones de herencia, unidireccionales y
bidireccionales, y permite asignar colores a las clases y agregar bloques de texto para explicar ciertas partes del
diseño que puedan resultar difíciles de comprender. Para EF Core: 2.
Marketplace
CatFactory
CatFactory es un motor de scaffolding para .NET Core que permite automatizar la generación de clases DbContext,
entidades, opciones de configuración de la asignación y clases de repositorios de una base de datos SQL Server.
Para EF Core: 2.
Repositorio de GitHub
LoreSoft's Entity Framework Core Generator
Entity Framework Core Generator (efg) es una herramienta de la CLI de .NET Core que permite generar modelos EF
Core a partir de una base de datos existente. Es similar a dotnet ef dbcontext scaffold , pero también admite la
regeneración de código seguro mediante el reemplazo de la región o el análisis de los archivos de asignación.
Asimismo, la herramienta permite generar modelos de vista, efectuar la validación y crear el código de los
asignadores de objetos. Para EF Core: 2.
Tutorial Documentación
Extensiones
Microsoft.EntityFrameworkCore.AutoHistory
Biblioteca de extensiones que permite registrar automáticamente los cambios en los datos realizados por EF Core e
incluirlos en una tabla a modo de historial. Para EF Core: 2.
EFSecondLevelCache.Core
Extensión que permite almacenar los resultados de las consultas EF Core en una caché de segundo nivel. De este
modo, al volver a ejecutar las mismas cadenas, se pueden recuperar los datos directamente de la caché sin acceder
a la base de datos. Para EF Core: 2.
Geco
Geco (Generator Console) es un generador de código muy sencillo que se basa en un proyecto de consola. Para
generar el código, se ejecuta en .NET Core y utiliza cadenas C# interpoladas. Geco incluye un generador de modelos
de ingeniería inversa para EF Core que admite la pluralización, la singularización y las plantillas editables. También
proporciona un generador de scripts de datos semilla, un ejecutor de scripts y una herramienta para limpiar las
bases de datos. Para EF Core: 2.
EntityFrameworkCore.Scaffolding.Handlebars
Permite la personalización de clases con ingeniería inversa a partir de una base de datos existente mediante la
cadena de herramientas de Entity Framework Core con las plantillas de Handlebars. Para EF Core: 2, 3.
NeinLinq.EntityFrameworkCore
NeinLinq amplía las características de proveedores LINQ como Entity Framework para permitir la reutilización de
las funciones, la reescritura de las consultas y la creación de consultas dinámicas mediante selectores y predicados
traducibles. Para EF Core: 2, 3.
Microsoft.EntityFrameworkCore.UnitOfWork
Extensión de Microsoft.EntityFrameworkCore para admitir los repositorios, los patrones de unidades de trabajo y
varias bases de datos compatibles con las transacciones distribuidas. Para EF Core: 2.
EFCore.BulkExtensions
Extensiones de EF Core para operaciones masivas (Insert, Update y Delete). Para EF Core: 2, 3.
Bricelam.EntityFrameworkCore.Pluralizer
Agrega pluralización en tiempo de diseño. Para EF Core: 2.
Toolbelt.EntityFrameworkCore.IndexAttribute
Recuperación del atributo [Index] (con extensión para la creación de modelos). Para EF Core: 2, 3.
EfCore.InMemoryHelpers
Proporciona un contenedor alrededor del proveedor de la base de datos en memoria de EF Core. Así, hace que
actúe de una forma más similar a la de un proveedor relacional. Para EF Core: 2.
EFCore.TemporalSupport
Implementación de compatibilidad temporal. Para EF Core: 2.
EfCoreTemporalTable
Realice consultas temporales fácilmente en su base de datos favorita con los métodos de extensión incorporados:
AsTemporalAll() , AsTemporalAsOf(date) , AsTemporalFrom(startDate, endDate) ,
AsTemporalBetween(startDate, endDate) , AsTemporalContained(startDate, endDate) . Para EF Core: 3.
EFCore.TimeTraveler
Permita consultas completas de Entity Framework Core en el historial temporal de SQL Server mediante el código
de EF Core, las entidades y las asignaciones que ya ha definido. Para viajar a través del tiempo, encapsule el código
en using (TemporalQuery.AsOf(targetDateTime)) {...} . Para EF Core: 3.
EntityFrameworkCore.TemporalTables
Biblioteca de extensiones para Entity Framework Core que permite a los desarrolladores que usan SQL Server
utilizar fácilmente tablas temporales. Para EF Core: 2.
EntityFrameworkCore.Cacheable
Caché de consulta de segundo nivel y alto rendimiento. Para EF Core: 2.
Entity Framework Plus
Amplía su DbContext con características como: Incluir filtro, Auditoría, Cache, Consulta de futuro, Batch Delete,
Actualización por lotes y más. Para EF Core: 2, 3.
Sitio web Repositorio de GitHub
Extensiones de Entity Framework
Extiende su DbContext con operaciones masivas de alto rendimiento: BulkSaveChanges, BulkInsert, BulkUpdate,
BulkDelete, BulkMerge y más. Para EF Core: 2, 3.
Sitio web
Expressionify
Agregue compatibilidad para llamar a métodos de extensión en expresiones lambda LINQ. Para EF Core: 3.1
XLinq
Tecnología Language Integrated Query (LINQ) para bases de datos relacionales. Permite usar C# para escribir
consultas fuertemente tipadas. Para EF Core: 3.1
Compatibilidad total de C# con la creación de consultas: varias instrucciones dentro de lambda, variables,
funciones, etc.
Sin vacío semántico con SQL. XLinq declara instrucciones SQL (como SELECT , FROM , WHERE ) como métodos de
C# de primera clase, combinando la sintaxis conocida con IntelliSense, seguridad de tipos y refactorización.
Como resultado, SQL se convierte en "otra" biblioteca de clases que expone su API localmente, literalmente
"Language Integrated SQL" .
Sitio web
Referencia sobre las herramientas de Entity
Framework Core
Las herramientas de Entity Framework Core ayudan con las tareas de desarrollo en tiempo de diseño. Se usan
principalmente para administrar migraciones y para aplicar scaffolding a DbContext y a tipos de entidad
mediante utilización de técnicas de ingeniería inversa en el esquema de una base de datos.
Las herramientas de la Consola del Administrador de paquetes de EF Core se ejecutan en la Consola del
Administrador de paquetes de Visual Studio.
Las herramientas de la interfaz de la línea de comandos (CLI) de EF Core .NET son una extensión de las
herramientas de la CLI de .NET Core multiplataforma. Estas herramientas necesitan un proyecto de SDK de
.NET Core (uno con Sdk="Microsoft.NET.Sdk" o similar en el archivo de proyecto).
Ambas herramientas exponen la misma funcionalidad. Si está desarrollando en Visual Studio, se recomienda usar
las herramientas de la Consola del Administrador de paquetes , ya que proporcionan una experiencia más
integrada.
Pasos siguientes
Referencia sobre las herramientas de la Consola del Administrador de paquetes de EF Core
Referencia sobre las herramientas de la CLI de EF Core .NET
Referencia de herramientas de Entity Framework
Core: consola del administrador de paquetes en
Visual Studio
Las herramientas de la consola del administrador de paquetes (PMC) para Entity Framework Core realizar
tareas de desarrollo en tiempo de diseño. Por ejemplo, se crean migraciones, se aplican migraciones y se
genera código para un modelo basado en una base de datos existente. Los comandos se ejecutan dentro de
Visual Studio mediante la consola del administrador de paquetes. Estas herramientas funcionan con proyectos
de .NET Framework y .NET Core.
Si no usa Visual Studio, se recomienda usar en su lugar las herramientas de línea de comandos de EF Core . Las
herramientas de la CLI son multiplataforma y se ejecutan en un símbolo del sistema.
Instalación de las herramientas

Los procedimientos para instalar y actualizar las herramientas difieren entre ASP.NET Core 2.1 + y versiones
anteriores u otros tipos de proyecto.
ASP.NET Core versión 2,1 y versiones posteriores
Las herramientas se incluyen automáticamente en un proyecto de ASP.NET Core 2.1 + porque el paquete de
Microsoft.EntityFrameworkCore.Tools se incluye en el metapaquete Microsoft. AspNetCore. app.
Por lo tanto, no tiene que hacer nada para instalar las herramientas, pero tiene que:
Restaure los paquetes antes de usar las herramientas en un nuevo proyecto.
Instale un paquete para actualizar las herramientas a una versión más reciente.
Para asegurarse de que está obteniendo la versión más reciente de las herramientas, se recomienda que realice
también el siguiente paso:
Edite el archivo . csproj y agregue una línea que especifique la versión más reciente del paquete
Microsoft. EntityFrameworkCore. Tools . Por ejemplo, el archivo . csproj podría incluir un ItemGroup que
tiene este aspecto:
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.App" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="2.1.3" />
<PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design" Version="2.1.1" />
</ItemGroup>
Actualice las herramientas cuando reciba un mensaje similar al del ejemplo siguiente:
La versión de herramientas de EF Core ' 2.1.1-RTM-30846 ' es anterior a la del runtime ' 2.1.3-RTM-32065 '.
Actualice las herramientas para las últimas características y correcciones de errores.
Para actualizar las herramientas:

Instale la SDK de .NET Core más reciente.
Actualice Visual Studio a la versión más reciente.
Edite el archivo . csproj para que incluya una referencia de paquete al paquete de herramientas más reciente,
como se mostró anteriormente.
Otras versiones y tipos de proyecto
Instale las herramientas de la consola del administrador de paquetes ejecutando el siguiente comando en la
consola del administrador de paquetes :
Install-Package Microsoft.EntityFrameworkCore.Tools
Actualice las herramientas ejecutando el siguiente comando en la consola del administrador de paquetes .
Update-Package Microsoft.EntityFrameworkCore.Tools
Comprobación de la instalación
Ejecute este comando para comprobar que las herramientas están instaladas:
Get-Help about_EntityFrameworkCore
La salida tiene el siguiente aspecto (no indica qué versión de las herramientas está usando):
_/\__
---==/ \\
___ ___ |. \|\
| __|| __| | ) \\\
| _| | _| \_/ | //|\\
|___||_| / \\\/\\
TOPIC
about_EntityFrameworkCore
SHORT DESCRIPTION
Provides information about the Entity Framework Core Package Manager Console Tools.
<A list of available commands follows, omitted here.>
Uso de las herramientas

Antes de usar las herramientas:
Comprenda la diferencia entre el proyecto de destino y el de inicio.
Aprenda a usar las herramientas con .NET Standard bibliotecas de clases.
En el caso de los proyectos de ASP.NET Core, establezca el entorno.
Proyecto de destino e inicio
Los comandos hacen referencia a un proyecto y un proyecto de inicio.
El proyecto también se conoce como proyecto de destino porque es donde los comandos agregan o
quitan archivos. De forma predeterminada, el proyecto predeterminado seleccionado en la consola
del administrador de paquetes es el proyecto de destino. Puede especificar otro proyecto como
proyecto de destino mediante la opción --project .
El proyecto de inicio es el que las herramientas compilan y ejecutan. Las herramientas tienen que
ejecutar código de aplicación en tiempo de diseño para obtener información sobre el proyecto, como la
cadena de conexión a la base de datos y la configuración del modelo. De forma predeterminada, el
proyecto de inicio en Explorador de soluciones es el proyecto de inicio. Puede especificar otro
proyecto como proyecto de inicio mediante la opción --startup-project .
El proyecto de inicio y el proyecto de destino suelen ser el mismo proyecto. Un escenario típico en el que se
trata de proyectos independientes es cuando:
El contexto de EF Core y las clases de entidad se encuentran en una biblioteca de clases de .NET Core.
Una aplicación de consola de .NET Core o una aplicación web hace referencia a la biblioteca de clases.
También es posible colocar el código de las migraciones en una biblioteca de clases independiente del contexto
de EF Core.
Otras plataformas de destino
Las herramientas de la consola del administrador de paquetes funcionan con proyectos de .NET Core o .NET
Framework. Es posible que las aplicaciones que tienen el modelo de EF Core en una biblioteca de clases .NET
Standard no tengan un proyecto de .NET Core o .NET Framework. Por ejemplo, esto es cierto para las
aplicaciones Xamarin y Plataforma universal de Windows. En tales casos, puede crear un proyecto de aplicación
de consola de .NET Core o .NET Framework cuyo único propósito es actuar como proyecto de inicio para las
herramientas. El proyecto puede ser un proyecto ficticio sin código real — solo es necesario para proporcionar
un destino para las herramientas.
¿Por qué es necesario un proyecto ficticio? Como se mencionó anteriormente, las herramientas tienen que
ejecutar código de aplicación en tiempo de diseño. Para ello, deben usar .NET Core o .NET Framework Runtime.
Cuando el modelo de EF Core está en un proyecto que tiene como destino .NET Core o .NET Framework, las
herramientas de EF Core toman prestado el tiempo de ejecución del proyecto. No pueden hacerlo si el modelo
de EF Core está en una biblioteca de clases .NET Standard. El .NET Standard no es una implementación real de
.NET; es una especificación de un conjunto de API que las implementaciones de .NET deben admitir. Por lo tanto
.NET Standard no es suficiente para que las herramientas de EF Core ejecuten código de aplicación. El proyecto
ficticio que cree para usarlo como proyecto de inicio proporciona una plataforma de destino concreta en la que
las herramientas pueden cargar la biblioteca de clases de .NET Standard.
Entorno de ASP.NET Core
Para especificar el entorno de ASP.NET Core proyectos, establezca env: ASPNETCORE_ENVIRONMENT antes
de ejecutar los comandos.
Parámetros comunes
En la tabla siguiente se muestran los parámetros que son comunes a todos los comandos EF Core:
PA RÁ M ET RO DESC RIP C IÓ N
-Context <cadena > La clase DbContext que se va a usar. Nombre de clase solo
o completo con espacios de nombres. Si se omite este
parámetro, EF Core encuentra la clase de contexto. Si hay
varias clases de contexto, este parámetro es obligatorio.
-Project <cadena > Proyecto de destino. Si se omite este parámetro, el

proyecto predeterminado de la consola del
administrador de paquetes se utiliza como proyecto de
destino.
-Proyecto <cadena > Proyecto de inicio. Si se omite este parámetro, el proyecto

de inicio de las propiedades de la solución se usa como
proyecto de destino.
-Verbose Mostrar resultado detallado.
Para mostrar información de ayuda sobre un comando, use el comando Get-Help de PowerShell.
TIP
Los parámetros context, Project y proyecto admiten la expansión de pestañas.
Agregar-migración
Agrega una nueva migración.
Parámetros:
Nombre <cadena > El nombre de la migración. Este es un parámetro posicional

y es obligatorio.
-OutputDir <cadena > Directorio (y subespacio de nombres) que se va a usar. Las

rutas de acceso son relativas al directorio del proyecto de
destino. El valor predeterminado es "migraciones".
Drop-Database
Quita la base de datos.
Parámetros:
-WhatIf Mostrar la base de datos que se va a quitar, pero no

quitarla.
Get-DbContext
Obtiene información sobre un tipo de DbContext .
Remove-Migration
Quita la última migración (revierte los cambios de código que se realizaron para la migración).
Parámetros:
-Force Revertir la migración (revertir los cambios que se aplicaron a

la base de datos).
Scaffold-DbContext
Genera código para un DbContext y tipos de entidad para una base de datos. Para que Scaffold-DbContext
genere un tipo de entidad, la tabla de base de datos debe tener una clave principal.
Parámetros:
-Connection <cadena > La cadena de conexión a la base de datos. En el caso de los

proyectos de ASP.NET Core 2. x, el valor puede ser Name =
<nombre de la cadena de conexión > . En ese caso, el
nombre procede de los orígenes de configuración que se
configuran para el proyecto. Este es un parámetro posicional
y es obligatorio.
-Provider <cadena > Proveedor que se va a usar. Normalmente, es el nombre del

paquete de NuGet, por ejemplo:
Microsoft.EntityFrameworkCore.SqlServer . Este es un
parámetro posicional y es obligatorio.
-OutputDir <cadena > Directorio en el que se colocarán los archivos. Las rutas de
acceso son relativas al directorio del proyecto.
-ContextDir <cadena > Directorio en el que se va a colocar el archivo de

DbContext . Las rutas de acceso son relativas al directorio
del proyecto.
-Context <cadena > Nombre de la clase DbContext que se va a generar.
-Schemas <String [] > Esquemas de las tablas para las que se van a generar tipos
de entidad. Si se omite este parámetro, se incluyen todos los
esquemas.
-Tables <String [] > Tablas para las que se van a generar tipos de entidad. Si se
omite este parámetro, se incluyen todas las tablas.
-DataAnnotations Use los atributos para configurar el modelo (siempre que

sea posible). Si se omite este parámetro, solo se usa la API
fluida.
-UseDatabaseNames Utilice nombres de tabla y columna exactamente como

aparecen en la base de datos. Si se omite este parámetro,
los nombres de base de datos se cambian para C# ajustarse
mejor a las convenciones de estilo de nombre.
-Force Sobrescribe los archivos existentes.
Ejemplo:
Microsoft.EntityFrameworkCore.SqlServer -OutputDir Models
Ejemplo que scaffolding solo selecciona tablas y crea el contexto en una carpeta independiente con un nombre
especificado:
Microsoft.EntityFrameworkCore.SqlServer -OutputDir Models -Tables "Blog","Post" -ContextDir Context -
Context BlogContext
Script: migración
Genera un script SQL que aplica todos los cambios de una migración seleccionada a otra migración
seleccionada.
Parámetros:
-Desde <cadena > La migración inicial. Las migraciones pueden identificarse por
nombre o por identificador. El número 0 es un caso especial
que significa antes de la primera migración. El valor
predeterminado es 0.
-Para <cadena > La migración final. Tiene como valor predeterminado la

última migración.
-Idempotente Generar un script que se puede usar en una base de datos

en cualquier migración.
-OUTPUT <cadena > Archivo en el que se va a escribir el resultado. Si se omite

este parámetro, el archivo se crea con un nombre generado
en la misma carpeta en que se crean los archivos en tiempo
de ejecución de la aplicación, por ejemplo:
/obj/Debug/netcoreapp2.1/ghbkztfz.SQL/ .
TIP
Los parámetros para, de y de salida admiten la expansión de pestañas.
En el ejemplo siguiente se crea un script para la migración de InitialCreate con el nombre de la migración.
Script-Migration -To InitialCreate
En el ejemplo siguiente se crea un script para todas las migraciones después de la migración de InitialCreate
con el identificador de migración.
Script-Migration -From 20180904195021_InitialCreate
Actualizar base de datos

Actualiza la base de datos a la última migración o a una migración especificada.
-<de la cadena de migración > La migración de destino. Las migraciones pueden

identificarse por nombre o por identificador. El número 0 es
un caso especial que significa antes de la primera migración
y hace que se reviertan todas las migraciones. Si no se
especifica ninguna migración, el comando toma como valor
predeterminado la última migración.
TIP
El parámetro Migration admite la expansión de pestañas.
En el ejemplo siguiente se revierten todas las migraciones.
Update-Database -Migration 0
En los siguientes ejemplos se actualiza la base de datos a una migración especificada. El primero usa el nombre
de la migración y el segundo usa el identificador de migración:
Update-Database -Migration InitialCreate

Update-Database -Migration 20180904195021_InitialCreate
Migraciones
Ingeniería inversa
Referencia de herramientas de Entity Framework
Core: CLI de .NET
Las herramientas de la interfaz de la línea de comandos (CLI) para Entity Framework Core realizar tareas de
desarrollo en tiempo de diseño. Por ejemplo, se crean migraciones, se aplican migraciones y se genera código
para un modelo basado en una base de datos existente. Los comandos son una extensión del comando dotnet
multiplataforma, que forma parte de la SDK de .net Core. Estas herramientas funcionan con proyectos de .NET
Core.
Si usa Visual Studio, se recomienda usar en su lugar las herramientas de la consola del administrador de
paquetes :
Funcionan automáticamente con el proyecto actual seleccionado en la consola del administrador de
paquetes sin necesidad de cambiar manualmente los directorios.
Abren automáticamente los archivos generados por un comando una vez completado el comando.
Instalación de las herramientas

El procedimiento de instalación depende del tipo y la versión del proyecto:
EF Core 3. x
ASP.NET Core versión 2,1 y versiones posteriores
EF Core 2. x
EF Core 1. x
EF Core 3. x
dotnet ef debe instalarse como una herramienta global o local. La mayoría de los desarrolladores
instalarán dotnet ef como una herramienta global con el siguiente comando:
dotnet tool install --global dotnet-ef
También puede usar dotnet ef como herramienta local. Para usarlo como una herramienta local,
restaure las dependencias de un proyecto que la declara como una dependencia de herramientas
mediante un archivo de manifiestode la herramienta.
Instale el SDK de .NET Core.
Instale el paquete de Microsoft.EntityFrameworkCore.Design más reciente.
ASP.NET Core 2.1 +

Instale el SDK de .net Coreactual. El SDK debe estar instalado incluso si dispone de la versión más
reciente de Visual Studio 2017.
Esto es todo lo que se necesita para ASP.NET Core 2.1 + porque el paquete de
Microsoft.EntityFrameworkCore.Design se incluye en el metapaquete Microsoft. AspNetCore. app.
EF Core 2. x (no ASP.NET Core )
Los comandos de dotnet ef se incluyen en el SDK de .NET Core, pero para habilitar los comandos que tiene
para instalar el paquete de Microsoft.EntityFrameworkCore.Design .
Instale el SDK de .net Coreactual. El SDK debe instalarse incluso si tiene la versión más reciente de Visual
Studio.
Instale el paquete de Microsoft.EntityFrameworkCore.Design estable más reciente.
EF Core 1. x
Instale la versión SDK de .NET Core 2.1.200. Las versiones posteriores no son compatibles con las
herramientas de la CLI para EF Core 1,0 y 1,1.
Configure la aplicación para que use la versión del SDK de 2.1.200 modificando su archivo global. JSON .
Este archivo se incluye normalmente en el directorio de la solución (uno encima del proyecto).
Edite el archivo de proyecto y agregue Microsoft.EntityFrameworkCore.Tools.DotNet como un elemento
de DotNetCliToolReference . Especifique la versión más reciente de 1. x, por ejemplo: 1.1.6. Vea el ejemplo
de archivo de proyecto al final de esta sección.
Instale la versión 1. x más reciente del paquete de Microsoft.EntityFrameworkCore.Design , por ejemplo:
dotnet add package Microsoft.EntityFrameworkCore.Design -v 1.1.6
Con las referencias de paquete agregadas, el archivo de proyecto tiene un aspecto similar al siguiente:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp1.1</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.EntityFrameworkCore.Design"
Version="1.1.6"
PrivateAssets="All" />
</ItemGroup>
<ItemGroup>
<DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet"
Version="1.1.6" />
</ItemGroup>
</Project>
Una referencia de paquete con PrivateAssets="All" no se expone a los proyectos que hacen referencia
a este proyecto. Esta restricción es especialmente útil para los paquetes que normalmente se usan solo
durante el desarrollo.
Comprobar la instalación
Ejecute los siguientes comandos para comprobar que las herramientas de la CLI de EF Core están instaladas
correctamente:
dotnet restore
dotnet ef
La salida del comando identifica la versión de las herramientas en uso:

_/\__
---==/ \\
___ ___ |. \|\
| __|| __| | ) \\\
| _| | _| \_/ | //|\\
|___||_| / \\\/\\
Entity Framework Core .NET Command-line Tools 2.1.3-rtm-32065
<Usage documentation follows, not shown.>
Uso de las herramientas

Antes de usar las herramientas, puede que tenga que crear un proyecto de inicio o establecer el entorno.
Proyecto de destino y proyecto de inicio
Los comandos hacen referencia a un proyecto y un proyecto de inicio.
El proyecto también se conoce como proyecto de destino porque es donde los comandos agregan o
quitan archivos. De forma predeterminada, el proyecto en el directorio actual es el proyecto de destino.
Puede especificar otro proyecto como proyecto de destino mediante la opción --project .
El proyecto de inicio es el que las herramientas compilan y ejecutan. Las herramientas tienen que
ejecutar código de aplicación en tiempo de diseño para obtener información sobre el proyecto, como la
cadena de conexión a la base de datos y la configuración del modelo. De forma predeterminada, el
proyecto en el directorio actual es el proyecto de inicio. Puede especificar otro proyecto como proyecto
de inicio mediante la opción --startup-project .
El proyecto de inicio y el proyecto de destino suelen ser el mismo proyecto. Un escenario típico en el que se
trata de proyectos independientes es cuando:
El contexto de EF Core y las clases de entidad se encuentran en una biblioteca de clases de .NET Core.
Una aplicación de consola de .NET Core o una aplicación web hace referencia a la biblioteca de clases.
También es posible colocar el código de las migraciones en una biblioteca de clases independiente del contexto
de EF Core.
Otras plataformas de destino
Las herramientas de la CLI funcionan con proyectos de .NET Core y proyectos de .NET Framework. Es posible
que las aplicaciones que tienen el modelo de EF Core en una biblioteca de clases .NET Standard no tengan un
proyecto de .NET Core o .NET Framework. Por ejemplo, esto es cierto para las aplicaciones Xamarin y
Plataforma universal de Windows. En tales casos, puede crear un proyecto de aplicación de consola de .NET
Core cuyo único propósito es actuar como proyecto de inicio para las herramientas. El proyecto puede ser un
proyecto ficticio sin código real — solo es necesario para proporcionar un destino para las herramientas.
¿Por qué es necesario un proyecto ficticio? Como se mencionó anteriormente, las herramientas tienen que
ejecutar código de aplicación en tiempo de diseño. Para ello, deben usar el tiempo de ejecución de .NET Core.
Cuando el modelo de EF Core está en un proyecto que tiene como destino .NET Core o .NET Framework, las
herramientas de EF Core toman prestado el tiempo de ejecución del proyecto. No pueden hacerlo si el modelo
de EF Core está en una biblioteca de clases .NET Standard. El .NET Standard no es una implementación real de
.NET; es una especificación de un conjunto de API que las implementaciones de .NET deben admitir. Por lo tanto
.NET Standard no es suficiente para que las herramientas de EF Core ejecuten código de aplicación. El proyecto
ficticio que cree para usarlo como proyecto de inicio proporciona una plataforma de destino concreta en la que
las herramientas pueden cargar la biblioteca de clases de .NET Standard.
Entorno de ASP.NET Core
Para especificar el entorno de ASP.NET Core proyectos, establezca la variable de entorno
ASPNETCORE_ENVIRONMENT antes de ejecutar los comandos.
Opciones comunes
O P C IÓ N DESC RIP C IÓ N
--json Muestra la salida JSON.
-c --context <DBCONTEXT> La clase DbContext que se va a usar.

Nombre de clase solo o completo con
espacios de nombres. Si se omite esta
opción, EF Core buscará la clase de
contexto. Si hay varias clases de
contexto, se requiere esta opción.
-p --project <PROJECT> Ruta de acceso relativa a la carpeta de

proyecto del proyecto de destino. El
valor predeterminado es la carpeta
actual.
-s --startup-project <PROJECT> Ruta de acceso relativa a la carpeta de

proyecto del proyecto de inicio. El
valor predeterminado es la carpeta
actual.
--framework <FRAMEWORK> Moniker de la plataforma de destino

para la plataforma de destino. Use
cuando el archivo del proyecto
especifique varias plataformas de
destino y desee seleccionar una de
ellas.
--configuration <CONFIGURATION> La configuración de compilación, por

ejemplo: Debug o Release .
--runtime <IDENTIFIER> Identificador del Runtime de destino

para el que se van a restaurar los
paquetes. Para obtener una lista de
identificadores de tiempo de ejecución
(RID), consulte el catálogo de RID.
-h --help Mostrar información de la ayuda.
-v --verbose Mostrar resultado detallado.
--no-color No colorear la salida.
--prefix-output Prefijo de salida con nivel.
eliminación de base de datos de dotnet EF

Quita la base de datos.
Opciones:
-f --force No confirme.
--dry-run Mostrar la base de datos que se va a

quitar, pero no quitarla.
actualización de la base de datos de dotnet EF

Actualiza la base de datos a la última migración o a una migración especificada.
Argumentos:
A RGUM EN TO DESC RIP C IÓ N
<MIGRATION> La migración de destino. Las migraciones pueden

identificarse por nombre o por identificador. El número 0 es
un caso especial que significa antes de la primera migración
y hace que se reviertan todas las migraciones. Si no se
especifica ninguna migración, el comando toma como valor
predeterminado la última migración.
En los siguientes ejemplos se actualiza la base de datos a una migración especificada. El primero usa el nombre
de la migración y el segundo usa el identificador de migración:
dotnet ef database update InitialCreate

dotnet ef database update 20180904195021_InitialCreate
información de dbcontext de dotnet EF

Obtiene información sobre un tipo de DbContext .
lista de dbcontext de dotnet EF

Enumera los tipos de DbContext disponibles.
scaffold de dbcontext de dotnet EF

Genera código para un DbContext y tipos de entidad para una base de datos. Para que este comando genere
un tipo de entidad, la tabla de base de datos debe tener una clave principal.
Argumentos:
<CONNECTION> La cadena de conexión a la base de datos. En el caso de los

proyectos de ASP.NET Core 2. x, el valor puede ser Name =
<nombre de la cadena de conexión > . En ese caso, el
nombre procede de los orígenes de configuración que se
configuran para el proyecto.
<PROVIDER> Proveedor que se va a usar. Normalmente, es el nombre del

paquete de NuGet, por ejemplo:
Microsoft.EntityFrameworkCore.SqlServer .
Opciones:
-d --data-annotations Use los atributos para configurar el

modelo (siempre que sea posible). Si
se omite esta opción, solo se usa la
API fluida.
-c --context <NAME> Nombre de la clase DbContext que

se va a generar.
--context-dir <PATH> Directorio en el que se va a colocar el

archivo de clase de DbContext . Las
rutas de acceso son relativas al
directorio del proyecto. Los espacios
de nombres se derivan de los nombres
de carpeta.
-f --force Sobrescribe los archivos existentes.
-o --output-dir <PATH> Directorio en el que se colocarán los

archivos de clase de entidad. Las rutas
de acceso son relativas al directorio del
proyecto.
--schema <SCHEMA_NAME>... Esquemas de las tablas para las que se

van a generar tipos de entidad. Para
especificar varios esquemas, repita
--schema para cada uno. Si se omite
esta opción, se incluyen todos los
esquemas.
-t --table <TABLE_NAME> ... Tablas para las que se van a generar

tipos de entidad. Para especificar varias
tablas, repita -t o --table para
cada una de ellas. Si se omite esta
opción, se incluyen todas las tablas.
--use-database-names Utilice nombres de tabla y columna

exactamente como aparecen en la
base de datos. Si se omite esta opción,
los nombres de base de datos se
cambian para C# ajustarse mejor a las
convenciones de estilo de nombre.
En el ejemplo siguiente se scaffoldingan todos los esquemas y las tablas y se colocan los nuevos archivos en la
carpeta Models .

Microsoft.EntityFrameworkCore.SqlServer -o Models
En el ejemplo siguiente se scaffolding solo las tablas seleccionadas y se crea el contexto en una carpeta
independiente con un nombre especificado:
Microsoft.EntityFrameworkCore.SqlServer -o Models -t Blog -t Post --context-dir Context -c BlogContext
Migraciones de dotnet EF Add

Agrega una nueva migración.
Argumentos:
<NAME> El nombre de la migración.
Opciones:
-o --output-dir <PATH> Directorio (y subespacio de nombres)

que se va a usar. Las rutas de acceso
son relativas al directorio del proyecto.
El valor predeterminado es
"migraciones".
lista de migraciones de dotnet EF

Muestra las migraciones disponibles.
Migraciones de dotnet EF quitar

Quita la última migración (revierte los cambios de código que se realizaron para la migración).
Opciones:
-f --force Revertir la migración (revertir los

cambios que se aplicaron a la base de
datos).
script de migraciones de dotnet EF

Genera un script SQL a partir de las migraciones.
Argumentos:
<FROM> La migración inicial. Las migraciones pueden identificarse

por nombre o por identificador. El número 0 es un caso
especial que significa antes de la primera migración. El valor
predeterminado es 0.
<TO> La migración final. Tiene como valor predeterminado la

última migración.
Opciones:
-o --output <FILE> Archivo en el que se va a escribir el

script.
-i --idempotent Generar un script que se puede usar

en una base de datos en cualquier
migración.
En el ejemplo siguiente se crea un script para la migración de InitialCreate:
dotnet ef migrations script 0 InitialCreate
En el ejemplo siguiente se crea un script para todas las migraciones después de la migración de InitialCreate.
dotnet ef migrations script 20180904195021_InitialCreate
Migraciones
Ingeniería inversa
Creación de DbContext en tiempo de diseño
Algunos de los comandos de herramientas de EF Core (por ejemplo, los comandos de migración ) requieren que se
cree una instancia de DbContext derivada en tiempo de diseño para recopilar detalles sobre los tipos de entidad de
la aplicación y cómo se asignan a un esquema de base de datos. En la mayoría de los casos, es conveniente que el
DbContext creado se configure de forma similar a como se configuraría en tiempo de ejecución.
Hay varias maneras en las que las herramientas intentan crear el DbContext :
De servicios de aplicación
Si el proyecto de inicio usa el host de Web ASP.net Core o el host genérico de .net Core, las herramientas intentan
obtener el objeto DbContext del proveedor de servicios de la aplicación.
En primer lugar, las herramientas intentan obtener el proveedor de servicios invocando
Program.CreateHostBuilder() , llamando a Build() y, a continuación, accediendo a la propiedad Services .
public class Program

{
public static void Main(string[] args)
=> CreateHostBuilder(args).Build().Run();
// EF Core uses this method at design time to access the DbContext

public static IHostBuilder CreateHostBuilder(string[] args)
=> Host.CreateDefaultBuilder(args)
.ConfigureWebHostDefaults(
webBuilder => webBuilder.UseStartup<Startup>());
}
public class Startup

{
=> services.AddDbContext<ApplicationDbContext>();
}
public class ApplicationDbContext : DbContext

{
public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}
}
NOTE
Cuando se crea una nueva aplicación de ASP.NET Core, este enlace se incluye de forma predeterminada.
El propio DbContext y las dependencias de su constructor deben registrarse como servicios en el proveedor de
servicios de la aplicación. Esto se puede lograr fácilmente si se tiene un constructor en el DbContext que toma una
instancia de DbContextOptions<TContext> como argumento y mediante el método AddDbContext<TContext> .
Usar un constructor sin parámetros

Si DbContext no se puede obtener del proveedor de servicios de aplicación, las herramientas buscan el tipo de
DbContext derivado dentro del proyecto. A continuación, intentan crear una instancia mediante un constructor sin
parámetros. Este puede ser el constructor predeterminado si el DbContext se configura mediante el método
OnConfiguring .
Desde un generador en tiempo de diseño

También puede indicar a las herramientas cómo crear su DbContext implementando la interfaz
IDesignTimeDbContextFactory<TContext> : Si una clase que implementa esta interfaz se encuentra en el mismo
proyecto que el DbContext derivado o en el proyecto de inicio de la aplicación, las herramientas omiten las otras
formas de crear el DbContext y usar en su lugar el generador en tiempo de diseño.
using Microsoft.EntityFrameworkCore.Design;
using Microsoft.EntityFrameworkCore.Infrastructure;
namespace MyProject
{
public class BloggingContextFactory : IDesignTimeDbContextFactory<BloggingContext>
{
public BloggingContext CreateDbContext(string[] args)
{
var optionsBuilder = new DbContextOptionsBuilder<BloggingContext>();
return new BloggingContext(optionsBuilder.Options);

}
}
}
NOTE
El parámetro args no se usa actualmente. Existe un problema al realizar el seguimiento de la capacidad de especificar
argumentos en tiempo de diseño desde las herramientas.
Un generador en tiempo de diseño puede ser especialmente útil si necesita configurar DbContext de forma
diferente en tiempo de diseño que en tiempo de ejecución, si el constructor DbContext toma parámetros
adicionales que no están registrados en DI, si no usa DI en absoluto, o si por alguna razón prefiere no tener un
método BuildWebHost en la clase Main de la aplicación ASP.NET Core.
Servicios en tiempo de diseño
Algunos servicios usados por las herramientas solo se usan en tiempo de diseño. Estos servicios se administran de
forma independiente de los servicios en tiempo de ejecución de EF Core para evitar que se implementen con la
aplicación. Para invalidar uno de estos servicios (por ejemplo, el servicio para generar archivos de migración),
agregue una implementación de IDesignTimeServices al proyecto de inicio.
class MyDesignTimeServices : IDesignTimeServices

{
public void ConfigureDesignTimeServices(IServiceCollection services)
=> services.AddSingleton<IMigrationsCodeGenerator, MyMigrationsCodeGenerator>();
}
Entity Framework 6
Entity Framework 6 (EF6) es un asignador relacional de objetos (O/RM) probado para .NET con muchos años de
desarrollo de características y estabilización.
Como O/RM, EF6 reduce la discordancia de impedancia entre los mundos relacionales y orientados a objetos, lo
que permite a los desarrolladores escribir aplicaciones que interactúan con datos almacenados en bases de datos
relacionales con objetos .NET fuertemente tipados que representan el dominio de la aplicación, y eliminar la
necesidad de una gran parte del código de "mecánica" de acceso de datos que normalmente deben escribir.
EF6 implementa muchas características de O/RM populares:
Asignación de clases de entidad POCO que no dependen de ningún tipo de EF
Seguimiento de cambios automático
Resolución de identidad y unidad de trabajo
Carga diligente, diferida y explícita
Traducción de consultas fuertemente tipadas con LINQ (Language Integrated Query)
Capacidades de asignación enriquecidas que incluyen compatibilidad con:
Relaciones de uno a uno, de uno a varios y entre varios
Herencia (tabla por jerarquía, tabla por tipo y tabla por clase concreta)
Tipos complejos
Procedimientos almacenados
Un diseñador visual para crear modelos de entidad.
Una experiencia "Code First" para crear modelos de entidad mediante la escritura de código.
Los modelos pueden generarse a partir de bases de datos existentes y luego editarse manualmente, o bien se
pueden crear desde cero y luego usarse para generar nuevas bases de datos.
Integración con modelos de aplicación de .NET Framework, incluido ASP.NET, y mediante enlace de datos, con
WPF y WinForms.
Conectividad de base de datos basada en ADO.NET y varios proveedores disponibles para conectarse a
SQL Server, Oracle, MySQL, SQLite, PostgreSQL, DB2, etc.
¿Debo usar EF6 o EF Core?

EF Core es una versión más moderna, ligera y extensible de Entity Framework que tiene capacidades y ventajas
muy similares a EF6. EF Core es una reescritura completa y contiene muchas características nuevas que no están
disponibles en EF6, aunque todavía carece de algunas de las funcionalidades más avanzadas de asignación de EF6.
Considere el uso de EF Core en las aplicaciones nuevas si el conjunto de características se ajusta a los requisitos. En
Comparar EF Core y EF6 se examina el proceso de elección más detalladamente.
Primeros pasos
Agregue el paquete NuGet de EntityFramework al proyecto o instale Entity Framework Tools para Visual Studio.
Luego, vea vídeos, lea tutoriales y consulte documentación avanzada, que le ayudarán a sacar el máximo partido
de EF6.
Versiones anteriores de Entity Framework

Esta es la documentación de la versión más reciente de Entity Framework 6, aunque la mayor parte también se
aplica a las versiones anteriores. Vea Novedades y Versiones anteriores para obtener una lista completa de las
versiones de EF y las características incluidas.
Novedades de EF6
Se recomienda encarecidamente usar la versión más reciente de Entity Framework para asegurarse de obtener las
últimas características y la mayor estabilidad. Pero es posible que deba usar una versión anterior o que quiera
experimentar con las nuevas mejoras de la última versión preliminar. Para instalar versiones concretas de EF, vea
Get Entity Framework (Obtener Entity Framework).
EF 6.4.0
El runtime de EF 6.4.0 para NuGet se publicó en diciembre de 2019. El objetivo principal de EF 6.4 es perfeccionar
las características y los escenarios que se ofrecieron en EF 6.3. Consulte la lista de correcciones importantes en
Github.
EF 6.3.0
El runtime de EF 6.3.0 para NuGet se publicó en septiembre de 2019. El objetivo principal de esta versión era
facilitar la migración de las aplicaciones existentes que usan EF 6 a .NET Core 3.0. La comunidad también ha
contribuido con varias correcciones de errores y mejoras. Consulte los problemas cerrados en cada hito de la
versión 6.3.0 para información detallada. Estos son algunos de los más importantes:
Compatibilidad con .NET Core 3.0.
El paquete EntityFramework ahora tiene como destino .NET Standard 2.1 además de
.NET Framework 4.x.
Esto significa que EF 6.3 es multiplataforma y se admite en otros sistemas operativos además de
Windows, como Linux y macOS.
Se han vuelto a escribir los comandos de migración para ejecutarlos fuera de proceso y que trabajen
con proyectos de estilo de SDK.
Compatibilidad con HierarchyId de SQL Server.
Compatibilidad mejorada con PackageReference de Roslyn y NuGet.
Se agregó la utilidad ef6.exe para habilitar, agregar, generar scripts y aplicar migraciones desde los
ensamblados. Reemplaza a migrate.exe .
Compatibilidad con el diseñador de EF
Actualmente no se admite el uso del diseñador de EF directamente en proyectos de .NET Core o .NET Standard o
en un proyecto de .NET Framework de estilo SDK.
Puede solucionar esta limitación agregando el archivo EDMX y las clases generadas para las entidades y
DbContext como archivos vinculados a un proyecto de .NET Core 3.0 o .NET Standard 2.1 en la misma solución.
Los archivos vinculados tendrían el aspecto siguiente:
<ItemGroup>
<EntityDeploy Include="..\EdmxDesignHost\Entities.edmx" Link="Model\Entities.edmx" />
<Compile Include="..\EdmxDesignHost\Entities.Context.cs" Link="Model\Entities.Context.cs" />
<Compile Include="..\EdmxDesignHost\Thing.cs" Link="Model\Thing.cs" />
<Compile Include="..\EdmxDesignHost\Person.cs" Link="Model\Person.cs" />
</ItemGroup>
Tenga en cuenta que el archivo EDMX está vinculado con la acción de compilación EntityDeploy. Se trata de una
tarea especial de MSBuild (ahora incluida en el paquete EF 6.3) que se encarga de agregar el modelo EF en el
ensamblado de destino como recursos incrustados (o de copiarlo como archivos en la carpeta de salida, en
función de la configuración de procesamiento de artefactos de metadatos en EDMX). Para más información sobre
cómo configurar esta configuración, consulte nuestro ejemplo de .NET Core de EDMX.
Advertencia: Asegúrese de que el estilo antiguo (es decir, no SDK) del proyecto de .NET Framework que define el
archivo. edmx "real" se incluye antes del proyecto que define el vínculo dentro del archivo. sln. De lo contrario, al
abrir el archivo. edmx en el diseñador, verá el mensaje de error "The Entity Framework is not available in the target
framework currently specified for the project. You can change the target framework of the project or edit the
model in the XmlEditor" ("Entity Framework no está disponible en la plataforma de destino especificada
actualmente para el proyecto. Puede cambiar la plataforma de destino del proyecto o editar el modelo en
XmlEditor").
La página Versiones anteriores contiene un archivo de todas las versiones anteriores de EF y de las características
principales incluidas en cada versión.
Versiones anteriores de Entity Framework
La primera versión de Entity Framework se lanzó en 2008, como parte de .NET Framework 3,5 SP1 y Visual Studio
2008 SP1.
A partir de la versión EF 4.1, se ha distribuido como el paquete NuGet EntityFramework , actualmente uno de los
paquetes más populares en NuGet.org.
Entre las versiones 4,1 y 5,0, el paquete NuGet EntityFramework amplió las bibliotecas de EF que se incluían como
parte de .NET Framework.
A partir de la versión 6, EF se convirtió en un proyecto de código abierto y también se movía completamente
fuera de banda desde el .NET Framework. Esto significa que cuando se agrega el paquete NuGet de la versión 6 de
EntityFramework a una aplicación, se obtiene una copia completa de la biblioteca EF que no depende de los bits EF
que se incluyen como parte de .NET Framework. Esto ayudó en cierto modo a acelerar el ritmo del desarrollo y la
entrega de nuevas características.
En junio de 2016, se publicó EF Core 1,0. EF Core se basa en un nuevo código base y está diseñado como una
versión más ligera y extensible de EF. Actualmente EF Core es el principal enfoque del desarrollo para el equipo de
Entity Framework en Microsoft. Esto significa que no hay nuevas características principales planeadas para EF6.
Sin embargo, EF6 se sigue manteniendo como un proyecto de código abierto y un producto de Microsoft
compatible.
Esta es la lista de versiones anteriores, en orden cronológico inverso, con información sobre las nuevas
características que se introdujeron en cada versión.
Actualización de EF Tools para Visual Studio 2017 15.7

En mayo de 2018 se publicó una versión actualizada de EF6 Tools como parte de Visual Studio 2017 15.7. Incluye
mejoras para algunas de las áreas problemáticas más habituales:
Correcciones de varios errores de accesibilidad de la interfaz de usuario
Solución alternativa para la regresión del rendimiento de SQL Server al generar modelos a partir de bases de
datos existentes #4
Compatibilidad para la actualización de modelos más grandes en SQL Server #185
Otra mejora de esta versión nueva de EF Tools es que ahora instala el runtime de EF 6.2 al crear un modelo en un
proyecto nuevo. Con versiones anteriores de Visual Studio, es posible usar el runtime de EF 6.2 (así como
cualquier versión anterior de EF) mediante la instalación de la versión correspondiente del paquete NuGet.
EF 6.2.0
El runtime de EF 6.2 para NuGet se publicó en octubre de 2017. Gracias en gran medida a los esfuerzos de la
comunidad de colaboradores de código abierto, EF 6.2 incluye bastantes correcciones de errores y mejoras de
producto.
Esta es una breve lista de los cambios más importantes que afectan al runtime de EF 6.2:
Reducción del tiempo de inicio al cargar los primeros modelos de código finalizados desde una caché
persistente #275
API fluida para definir índices #274
DbFunctions.Like() para habilitar la escritura de consultas LINQ que se traducen en LIKE en SQL #241
Migrate.exe ahora admite la opción -script #240
EF6 ahora puede trabajar con valores de clave generados por una secuencia en SQL Server #165
Lista de actualización de errores transitorios de la estrategia de ejecución de SQL Azure #83
Error: al volver a intentar consultas o comandos SQL, se produce un error "SqlParameter ya está incluido en
otro elemento SqlParameterCollection" #81
Error: la evaluación de DbQuery.ToString() a menudo agota el tiempo de espera en el depurador #73
EF 6.1.3
El tiempo de ejecución de EF 6.1.3 se lanzó a NuGet en octubre de 2015. Esta versión solo contiene correcciones
para los defectos de alta prioridad y las regresiones detectadas en la versión 6.1.2. Las correcciones incluyen:
Consulta: regresión en EF 6.1.2: aplicación externa introducida y consultas más complejas para 1:1 relaciones y
la cláusula "Let"
Problema de TPT al ocultar la propiedad de clase base en la clase heredada
Error de DbMigration. SQL cuando la palabra ' Go ' está contenida en el texto
Crear marca de compatibilidad para la compatibilidad con el acoplamiento de UnionAll y Intersect
La consulta con varios includes no funciona en 6.1.2 (trabajando en 6.1.1)
"Hay un error en la sintaxis de SQL" excepción después de actualizar de EF 6.1.1 a 6.1.2
EF 6.1.2
El tiempo de ejecución de EF 6.1.2 se lanzó a NuGet en diciembre de 2014. Esta versión está principalmente
relacionada con las correcciones de errores. También hemos aceptado un par de cambios notables de los
miembros de la comunidad:
Los parámetros de la caché de consulta se pueden configurar desde el archivo App/web.
Configuration.
<entityFramework>
<queryCache size='1000' cleaningIntervalInSeconds='-1'/>
</entityFramework>
Los métodos SqlFile y SqlResource de DbMigration permiten ejecutar un script SQL almacenado como
un archivo o un recurso incrustado.
EF 6.1.1
El tiempo de ejecución de EF 6.1.1 se lanzó a NuGet en junio de 2014. Esta versión contiene correcciones para los
problemas que ha encontrado un número de personas. Entre otras:
Diseñador: error al abrir edmx EF5 con precisión decimal en el diseñador de EF6
La lógica de detección de instancia predeterminada para LocalDB no funciona con SQL Server 2014
EF 6.1.0
El tiempo de ejecución de EF 6.1.0 se lanzó a NuGet en marzo de 2014. Esta actualización secundaria incluye un
número significativo de características nuevas:
La consolidación de herramientas proporciona una manera coherente de crear un nuevo modelo EF. Esta
característica amplía el Asistente para Entity Data Model de ADO.net para admitir la creación de modelos Code
First, incluida la ingeniería inversa de una base de datos existente. Estas características estaban previamente
disponibles en calidad beta en las herramientas avanzadas de EF.
El control de los errores de confirmación de la transacción proporciona la CommitFailureHandler, que
hace uso de la nueva capacidad introducida para interceptar las operaciones de transacción.
CommitFailureHandler permite la recuperación automática de errores de conexión mientras se confirma una
transacción.
IndexAttribute permite especificar los índices colocando un atributo de [Index] en una propiedad (o
propiedades) en el modelo de Code First. A continuación, Code First creará un índice correspondiente en la
base de datos.
La API de asignación pública proporciona acceso a la información EF tiene sobre cómo se asignan las
propiedades y los tipos a las columnas y tablas de la base de datos. En las versiones anteriores, esta API era
interna.
La capacidad de configurar los interceptores mediante el archivo App/web. config permite agregar
interceptores sin volver a compilar la aplicación.
System. Data. Entity. Infrastructure. intercepción. DatabaseLogger es un nuevo interceptor que facilita
el registro de todas las operaciones de base de datos en un archivo. En combinación con la característica
anterior, esto le permite cambiar fácilmente el registro de las operaciones de base de datos para una aplicación
implementada, sin necesidad de volver a compilar.
La detección de cambios del modelo de migración se ha mejorado para que las migraciones con
scaffolding sean más precisas. también se ha mejorado el rendimiento del proceso de detección de cambios.
Mejoras en el rendimiento, incluidas las operaciones de base de datos reducidas durante la inicialización,
optimizaciones para la comparación de igualdad nula en consultas LINQ, generación más rápida de vistas
(creación de modelos) en más escenarios y materialización más eficaz de las entidades sometidas a
seguimiento con varias asociaciones.
EF 6.0.2
El tiempo de ejecución de EF 6.0.2 se lanzó a NuGet en diciembre de 2013. Esta versión de revisión se limita a
solucionar los problemas que se introdujeron en la versión EF6 (regresiones en rendimiento/comportamiento
desde EF5).
EF 6.0.1
El tiempo de ejecución de EF 6.0.1 se lanzó a NuGet en octubre de 2013 simultáneamente con EF 6.0.0, ya que este
último se incrustó en una versión de Visual Studio que se había bloqueado unos meses antes. Esta versión de
revisión se limita a solucionar los problemas que se introdujeron en la versión EF6 (regresiones en
rendimiento/comportamiento desde EF5). Los cambios más importantes fueron resolver algunos problemas de
rendimiento durante el calentamiento de los modelos EF. Esto era importante porque el rendimiento de la
preparación era un área de enfoque en EF6 y estos problemas eran la negación de algunas de las otras mejoras de
rendimiento realizadas en EF6.
EF 6,0
El tiempo de ejecución de EF 6.0.0 se lanzó a NuGet en octubre de 2013. Esta es la primera versión en la que se
incluye un tiempo de ejecución de EF completo en el paquete NuGet EntityFramework que no depende de los bits
EF que forman parte de la .NET Framework. Mover las partes restantes del tiempo de ejecución al paquete de
NuGet requirió un número de cambios importantes en el código existente. Consulte la sección sobre la
actualización a Entity Framework 6 para obtener más detalles sobre los pasos manuales necesarios para la
actualización.
Esta versión incluye numerosas características nuevas. Las siguientes características funcionan para los modelos
creados con Code First o el diseñador de EF:
Consulta asincrónica y guardar agrega compatibilidad con los patrones asincrónicos basados en tareas
que se introdujeron en .net 4,5.
La resistencia de la conexión permite la recuperación automática de errores de conexión transitorios.
La configuración basada en código ofrece la opción de realizar la configuración, que tradicionalmente se
llevó a cabo en un archivo de configuración, en el código.
La resolución de dependencias presenta compatibilidad con el patrón de localizador de servicio y hemos
factorizado algunas partes de la funcionalidad que se pueden reemplazar con implementaciones
personalizadas.
El registro de intercepción/SQL proporciona bloques de creación de bajo nivel para la interceptación de
operaciones EF con un registro de SQL simple basado en la parte superior.
Las mejoras en la capacidad de prueba facilitan la creación de dobles de pruebas para DbContext y DbSet
cuando se usa un marco ficticio o se escriben sus propios dobles de pruebas.
DbContext ahora se puede crear con un DbConnection que ya está abier to , lo que permite
escenarios en los que resultaría útil si la conexión pudiera estar abierta al crear el contexto (por ejemplo,
compartiendo una conexión entre los componentes en los que no se puede garantizar el estado de la
conexión).
La compatibilidad con transacciones mejorada proporciona compatibilidad con una transacción externa
al marco de trabajo, así como formas mejoradas de crear una transacción en el marco de trabajo.
Enumeraciones, un rendimiento espacial y mejor en .net 4,0 : moviendo los componentes principales
que solía haber en el .NET Framework al paquete de NUGET de EF, ahora podemos ofrecer compatibilidad con
enumeraciones, tipos de datos espaciales y mejoras de rendimiento de EF5 en .net 4,0.
Rendimiento mejorado de Enumerable. contiene en consultas LINQ .
Tiempo de preparación mejorado (generación de vistas) , especialmente para los modelos de gran
tamaño.
Pluralización acoplable & ser vicio de singularidad .
Ahora se admiten las implementaciones personalizadas de Equals o GetHashCode en las clases de
entidad.
DbSet. AddRange/RemoveRange proporciona una manera optimizada de agregar o quitar varias entidades
de un conjunto.
DbChangeTracker. HasChanges proporciona una manera sencilla y eficaz de ver si hay cambios pendientes
que guardar en la base de datos.
SqlCeFunctions proporciona un equivalente de SQL Compact a SqlFunctions.
Las siguientes características solo se aplican a Code First:
Las convenciones de Code First personalizadas permiten escribir sus propias convenciones para evitar
una configuración repetida. Proporcionamos una API simple para convenciones ligeras, así como algunos
bloques de creación más complejos para que pueda crear convenciones más complicadas.
Ahora se admite la asignación de Code First a los procedimientos almacenados de inserción,
actualización y eliminación .
Los scripts de migración idempotente permiten generar un script SQL que puede actualizar una base de
datos en cualquier versión hasta la versión más reciente.
La tabla de historial de migraciones configurable le permite personalizar la definición de la tabla de
historial de migraciones. Esto es especialmente útil para los proveedores de bases de datos que requieren los
tipos de datos adecuados, etc., para que la tabla de historial de migraciones funcione correctamente.
Varios contextos por base de datos quitan la limitación anterior de un modelo de Code First por base de
datos cuando se usan migraciones o cuando Code First crea automáticamente la base de datos.
DbModelBuilder. HasDefaultSchema es una nueva API de Code First que permite configurar el esquema de
la base de datos predeterminado para un modelo de Code First en un solo lugar. Anteriormente, el esquema
predeterminado Code First estaba codificado de forma rígida en "DBO" y la única manera de configurar el
esquema al que pertenecía una tabla era a través de la API de ToTable.
El método DbModelBuilder. Configurations. AddFromAssembly permite agregar fácilmente todas las clases
de configuración definidas en un ensamblado cuando se usan clases de configuración con la API fluida de Code
First.
Las operaciones de migración personalizadas le permitían agregar operaciones adicionales para usarlas
en las migraciones basadas en código.
El nivel de aislamiento de transacción predeterminado se cambia a
READ_COMMITTED_SNAPSHOT para las bases de datos creadas con Code First, lo que permite una mayor
escalabilidad y menos interbloqueos.
Los tipos de entidad y complejos ahora pueden ser clases nestedinside .
EF 5,0
El tiempo de ejecución de EF 5.0.0 se lanzó a NuGet en agosto de 2012. En esta versión se presentan algunas
características nuevas, como la compatibilidad con enumeraciones, las funciones con valores de tabla, los tipos de
datos espaciales y diversas mejoras de rendimiento.
En el Entity Framework Designer de Visual Studio 2012 también se incluye la compatibilidad con varios diagramas
por modelo, el color de las formas en la superficie de diseño y la importación por lotes de procedimientos
almacenados.
Esta es una lista de contenido que colocamos en concreto para la versión EF 5:
Publicación de la versión de EF 5
Nuevas características de EF5
Compatibilidad de enumeración en Code First
Compatibilidad de enumeración en EF Designer
Tipos de datos espaciales en Code First
Tipos de datos espaciales en EF Designer
Compatibilidad del proveedor con tipos espaciales
Funciones con valores de tabla
Varios diagramas por modelo
Configuración del modelo
Conexiones y modelos
Consideraciones de rendimiento
Trabajar con Microsoft SQL Azure
Configuración del archivo de configuración
Glosario
Code First
Code First a una nueva base de datos (tutorial y vídeo)
Code First a una base de datos existente (tutorial y vídeo)
Convenciones
API fluida: configuración/asignación de propiedades & tipos
API fluida: configuración de relaciones
API fluida con VB.NET
Migraciones de Code First
Migraciones de Code First automática
Migrate. exe
Definir DbSets
EF Designer
Model First (tutorial y vídeo)
Database First (tutorial y vídeo)
Tipos complejos
Asociaciones/relaciones
Patrón de herencia de TPT
Patrón de herencia TPH
Consulta con procedimientos almacenados
Procedimientos almacenados con varios conjuntos de resultados
INSERT, Update & Delete con procedimientos almacenados
Asignación de una entidad a varias tablas (División de entidades)
Asignar varias entidades a una tabla (División de tablas)
Definir consultas
Plantillas de generación de código
Revertir a ObjectContext
Uso del modelo
Consulta/búsqueda de entidades
Trabajar con relaciones
Carga de entidades relacionadas
Trabajar con datos locales
Aplicaciones de N niveles
Patrones de simultaneidad optimista
Trabajar con servidores proxy
Detección automática de cambios
Consultas sin seguimiento
Método de carga
Agregar, adjuntar y Estados de entidad
Trabajar con valores de propiedad
Enlace de datos con WPF (Windows Presentation Foundation)
Enlace de datos con WinForms (Windows Forms)
EF 4.3.1
El tiempo de ejecución de EF 4.3.1 se lanzó a NuGet en febrero de 2012 poco después de EF 4.3.0. Esta versión de
revisión incluyó algunas correcciones de errores en la versión EF 4,3 y presentó una mejor compatibilidad con
LocalDB para clientes que usan EF 4,3 con Visual Studio 2012.
Esta es una lista de contenido que colocamos en concreto para la versión EF 4.3.1. la mayor parte del contenido
proporcionado para EF 4,1 también se aplica también a EF 4,3:
Publicación de blog de la versión de EF 4.3.1
EF 4,3
El tiempo de ejecución de EF 4.3.0 se lanzó a NuGet en febrero de 2012. Esta versión incluye la nueva característica
Migraciones de Code First que permite cambiar incrementalmente una base de datos creada por Code First a
medida que el modelo de Code First evolucione.
Esta es una lista de contenido que colocamos en concreto para la versión EF 4,3, la mayor parte del contenido
proporcionado para EF 4,1 sigue siendo aplicable a EF 4,3 también:
Publicación de la versión de EF 4,3
Tutorial de migraciones basadas en código EF 4,3
Tutorial de migraciones automáticas de EF 4,3
EF 4,2
El tiempo de ejecución de EF 4.2.0 se lanzó a NuGet en noviembre de 2011. En esta versión se incluyen
correcciones de errores de la versión EF 4.1.1. Dado que esta versión solo incluye correcciones de errores, podría
haber sido la versión de revisión de EF 4.1.2 pero hemos optado por pasar a 4,2 para dejar de usar los números de
versión de revisión de fecha que usamos en las versiones 4.1. x y adoptar el estándar de control de versiones
semántico para el control de versiones semántico.
Esta es una lista de contenido que colocamos en concreto para la versión EF 4,2, el contenido proporcionado para
EF 4,1 todavía se aplica también a EF 4,2:
Code First tutorial
Tutorial de Database First de & de modelo
EF 4.1.1
El tiempo de ejecución de EF 4.1.10715 se lanzó a NuGet en julio de 2011. Además de las correcciones de errores,
esta versión de revisión incorporó algunos componentes para facilitar el trabajo de las herramientas en tiempo de
diseño con un modelo de Code First. Estos componentes se usan en Migraciones de Code First (incluido en EF 4,3)
y las herramientas avanzadas de EF.
Observará que el número de versión extraño 4.1.10715 del paquete. Usamos para usar versiones de revisión
basadas en fechas antes de decidir adoptar las versiones semánticas. Piense en esta versión como EF 4,1 patch 1
(o EF 4.1.1).
Esta es una lista de contenido que colocamos para la versión 4.1.1:
Publicación de la versión de EF 4.1.1
EF 4,1
El tiempo de ejecución de EF 4.1.10331 fue el primero en publicarse en NuGet, en abril de 2011. Esta versión
incluye la API de DbContext simplificada y el flujo de trabajo Code First.
Observará el número de versión extraño, 4.1.10331, que realmente debería ser 4,1. Además, hay una versión de
4.1.10311 que debe ser 4.1.0-RC (' RC ' significa ' Release Candidate '). Usamos para usar versiones de revisión
basadas en fechas antes de decidir adoptar las versiones semánticas.
Esta es una lista de contenido que colocamos juntos para la versión 4,1. Gran parte de este todavía se aplica a las
versiones posteriores de Entity Framework:
Code First tutorial
Tutorial de Database First de & de modelo
SQL Azure federaciones y el Entity Framework
EF 4,0
Esta versión se incluyó en .NET Framework 4 y Visual Studio 2010, en abril de 2010. Las nuevas características
importantes de esta versión incluyen compatibilidad POCO, asignación de claves externas, carga diferida, mejoras
en la capacidad de prueba, generación de código personalizable y el flujo de trabajo Model First.
Aunque era la segunda versión de Entity Framework, se llamaba EF 4 para que se alinee con la versión de .NET
Framework con la que se distribuyó. Después de esta versión, comenzamos a poner Entity Framework disponible
en NuGet y adoptamos las versiones semánticas, puesto que ya no se asociaron a la versión .NET Framework.
Tenga en cuenta que algunas versiones posteriores de .NET Framework se han incluido con actualizaciones
significativas de los bits EF incluidos. De hecho, muchas de las nuevas características de EF 5,0 se implementaron
como mejoras en estos bits. Sin embargo, para racionalizar el caso de control de versiones para EF, seguimos
haciendo referencia a los bits EF que forman parte de la .NET Framework como el tiempo de ejecución de EF 4,0,
mientras que todas las versiones más recientes están compuestas por el paquete NuGet EntityFramework.
EF 3,5
La versión inicial de Entity Framework se incluyó en .NET 3,5 Service Pack 1 y Visual Studio 2008 SP1, publicada
en agosto de 2008. Esta versión proporcionó compatibilidad básica con O/RM mediante el flujo de trabajo de
Database First.
Actualización a Entity Framework 6
En versiones anteriores de EF, el código se dividió entre las bibliotecas principales (principalmente System. Data.
Entity. dll) que se distribuyeron como parte de las bibliotecas de .NET Framework y fuera de banda (OOB)
(principalmente EntityFramework. dll) incluidas en un paquete NuGet. EF6 toma el código de las bibliotecas
principales y lo incorpora a las bibliotecas de OOB. Esto era necesario para permitir que EF se convirtió en código
abierto y para que pueda evolucionar a un ritmo diferente del .NET Framework. La consecuencia de esto es que las
aplicaciones deben volver a generarse con los tipos que se han descargado.
Esto debe ser sencillo para las aplicaciones que hacen uso de DbContext, tal y como se distribuyen en EF 4,1 y
versiones posteriores. Se requiere un poco más de trabajo para las aplicaciones que hacen uso de ObjectContext
pero que todavía no es difícil de hacer.
Esta es una lista de comprobación de las cosas que debe hacer para actualizar una aplicación existente a EF6.
1. Instale el paquete NuGet de EF6

Debe actualizar al nuevo tiempo de ejecución de Entity Framework 6.
1. Haga clic con el botón derecho en el proyecto y seleccione administrar paquetes NuGet...
2. En la pestaña en línea , seleccione EntityFramework y haga clic en instalar .
NOTE
Si se instaló una versión anterior del paquete NuGet EntityFramework, se actualizará a EF6.
Como alternativa, puede ejecutar el siguiente comando desde la consola del administrador de paquetes:
Install-Package EntityFramework
2. Asegúrese de que se quitan las referencias de ensamblado a System.

Data. Entity. dll
La instalación del paquete NuGet de EF6 debe quitar automáticamente del proyecto todas las referencias a System.
Data. Entity.
3. intercambiar modelos EF Designer (EDMX) para usar la generación

de código EF 6. x
Si tiene modelos creados con el diseñador de EF, deberá actualizar las plantillas de generación de código para
generar código compatible con EF6.
NOTE
Actualmente solo hay plantillas de generador de DbContext de EF 6. x disponibles para Visual Studio 2012 y 2013.
1. Elimine las plantillas de generación de código existentes. Normalmente, estos archivos se denominarán
<edmx_file_name>. TT y <edmx_file_name>. Context.tt y estar anidados en el archivo edmx en
explorador de soluciones. Puede seleccionar las plantillas en Explorador de soluciones y presionar la tecla
Supr para eliminarlas.
NOTE
En los proyectos de sitio web, las plantillas no se anidarán en el archivo edmx, sino que se enumeran en Explorador
de soluciones.
NOTE
En los proyectos de VB.NET, deberá habilitar "Mostrar todos los archivos" para poder ver los archivos de plantilla
anidados.
2. Agregue la plantilla de generación de código EF 6. x adecuada. Abra el modelo en EF Designer, haga clic con
el botón derecho en la superficie de diseño y seleccione Agregar elemento de generación de código.. .
Si usa la API DbContext (recomendado), el generador de dbcontext de EF 6. x estará disponible
en la pestaña datos .
NOTE
Si usa Visual Studio 2012, tendrá que instalar las herramientas de EF 6 para tener esta plantilla. Consulte
obtener Entity Framework para obtener más información.
Si usa la API de ObjectContext, tendrá que seleccionar la pestaña en línea y buscar el generador de
EntityObject EF 6. x .
3. Si ha aplicado cualquier personalización a las plantillas de generación de código, deberá volver a aplicarlas
a las plantillas actualizadas.
4. actualizar los espacios de nombres de los tipos de EF principales

utilizados
Los espacios de nombres de los tipos DbContext y Code First no han cambiado. Esto significa que para muchas
aplicaciones que usan EF 4,1 o posterior, no es necesario cambiar nada.
Los tipos como ObjectContext que anteriormente se encontraban en System. Data. Entity. dll se han migrado a
nuevos espacios de nombres. Esto significa que es posible que tenga que actualizar las directivas using o Import
para compilar en EF6.
La regla general para los cambios en el espacio de nombres es que cualquier tipo de System. Data. * se mueve a
System. Data. Entity. Core. *. En otras palabras, simplemente inserte Entity. Core. después de System. Data. Por
ejemplo:
System. Data. EntityException = > System. Data. Entity. Core . EntityException
System. Data. Objects. ObjectContext = > System. Data. Entity. Core . Objects. ObjectContext
System. Data. Objects. Classes. RelationshipManager = > System. Data. Entity. Core . Objects. Classes.
RelationshipManager
Estos tipos se encuentran en los espacios de nombres básicos porque no se usan directamente para la mayoría de
las aplicaciones basadas en DbContext. Algunos tipos que formaban parte de System. Data. Entity. dll se siguen
usando normalmente y directamente para aplicaciones basadas en DbContext, por lo que no se han pasado a los
espacios de nombres principales . Dichos componentes son:
System. Data. EntityState = > System. Data. Entidad . EntityState
System. Data. Objects. Classes. EdmFunctionAttribute = > System. Data. Entity. DbFunctionAttribute
NOTE
Se ha cambiado el nombre de esta clase; todavía existe una clase con el nombre anterior y funciona, pero ahora está
marcada como obsoleta.
System. Data. Objects. EntityFunctions = > System. Data. Entity. DbFunctions
NOTE
Se ha cambiado el nombre de esta clase; todavía existe una clase con el nombre antiguo y funciona, pero ahora está
marcada como obsoleta).
Las clases espaciales (por ejemplo, DbGeography, DbGeometry) se han pasado de System. Data. Spatial = >
System. Data. Entidad . PDF
NOTE
Algunos tipos del espacio de nombres System. Data están en System. Data. dll, que no es un ensamblado EF. Estos tipos no
se han cambiado y, por tanto, sus espacios de nombres permanecen inalterados.
Versiones de Visual Studio
Se recomienda usar siempre la versión más reciente de Visual Studio, ya que contiene las herramientas más
recientes para .NET, NuGet y Entity Framework. De hecho, los distintos ejemplos y tutoriales de la documentación
de Entity Framework suponen que está usando una versión reciente de Visual Studio.
Sin embargo, es posible usar versiones anteriores de Visual Studio con versiones diferentes de Entity Framework
siempre que tenga en cuenta algunas diferencias:
Visual Studio 2017 15,7 y versiones más recientes

Esta versión de Visual Studio incluye la versión más reciente de las herramientas de Entity Framework y el
tiempo de ejecución de EF 6,2 y no requiere pasos de configuración adicionales. Vea las novedades para
obtener más información sobre estas versiones.
Al agregar Entity Framework a los nuevos proyectos con las herramientas de EF, se agregará automáticamente
el paquete NuGet EF 6,2. Puede instalar o actualizar manualmente cualquier paquete de NuGet de EF disponible
en línea.
De forma predeterminada, la instancia de SQL Server disponible con esta versión de Visual Studio es una
instancia de LocalDB denominada MSSQLLocalDB. La sección del servidor de la cadena de conexión que se
debe usar es "(LocalDB)\MSSQLLocalDB". Recuerde usar una cadena textual con el prefijo @ o la doble barra
diagonal inversa "\\" al especificar una cadena de conexión en C# el código.
Visual Studio 2015 a Visual Studio 2017 15,6

Estas versiones de Visual Studio incluyen herramientas de Entity Framework y 6.1.3 en tiempo de ejecución. Vea
versiones anteriores para obtener más información sobre estas versiones.
Al agregar Entity Framework a los nuevos proyectos con las herramientas de EF, se agregará automáticamente
el paquete NuGet EF 6.1.3. Puede instalar o actualizar manualmente cualquier paquete de NuGet de EF
disponible en línea.
Visual Studio 2013

Esta versión de Visual Studio incluye y la versión anterior de las herramientas de Entity Framework y el tiempo
de ejecución. Se recomienda que actualice a Entity Framework Tools 6.1.3, mediante el instalador disponible en
el centro de descarga de Microsoft. Vea versiones anteriores para obtener más información sobre estas
versiones.
Al agregar Entity Framework a los nuevos proyectos mediante las herramientas de EF actualizadas, se agregará
automáticamente el paquete NuGet EF 6.1.3. Puede instalar o actualizar manualmente cualquier paquete de
NuGet de EF disponible en línea.
Visual Studio 2012
Esta versión de Visual Studio incluye y la versión anterior de las herramientas de Entity Framework y el tiempo
de ejecución. Se recomienda que actualice a Entity Framework Tools 6.1.3, mediante el instalador disponible en
el centro de descarga de Microsoft. Vea versiones anteriores para obtener más información sobre estas
versiones.
Al agregar Entity Framework a los nuevos proyectos mediante las herramientas de EF actualizadas, se agregará
automáticamente el paquete NuGet EF 6.1.3. Puede instalar o actualizar manualmente cualquier paquete de
NuGet de EF disponible en línea.
instancia de LocalDB denominada v 11.0. La sección del servidor de la cadena de conexión que se debe usar es "
(LocalDB)\v 11.0". Recuerde usar una cadena textual con el prefijo @ o la doble barra diagonal inversa "\\" al
especificar una cadena de conexión en C# el código.
Visual Studio 2010

La versión de Entity Framework Tools disponible con esta versión de Visual Studio no es compatible con el
tiempo de ejecución de Entity Framework 6 y no se puede actualizar.
De forma predeterminada, las herramientas de Entity Framework agregarán Entity Framework 4,0 a los
proyectos. Para crear aplicaciones con las versiones más recientes de EF, primero deberá instalar la extensión
del administrador de paquetes NuGet.
De forma predeterminada, toda la generación de código en la versión de las herramientas de EF se basa en
EntityObject y Entity Framework 4. Se recomienda cambiar la generación de código para que se base en
DbContext y Entity Framework 5, mediante la instalación de plantillas de generación de C# código DbContext
para o Visual Basic.
Una vez que haya instalado las extensiones del administrador de paquetes NuGet, puede instalar o actualizar
manualmente cualquier paquete de NuGet de EF disponible en línea y usar EF6 con Code First, que no requiere
un diseñador.
De forma predeterminada, la instancia de SQL Server disponible con esta versión de Visual Studio se SQL
Server Express denominada SQLEXPRESS. La sección del servidor de la cadena de conexión que se debe usar es
".\SQLEXPRESS ". Recuerde usar una cadena textual con el prefijo @ o la doble barra diagonal inversa "\\" al
especificar una cadena de conexión en C# el código.
Introducción a Entity Framework 6
En esta guía se recopilan vínculos a artículos de documentación, tutoriales y vídeos seleccionados que le pueden
ayudar a empezar rápidamente.
Aspectos básicos
Aquí obtendrá información sobre cómo agregar Entity Framework a sus aplicaciones y, si quiere usar EF
Designer, asegúrese de que lo instala en Visual Studio.
Creación de un modelo: Code First, EF Designer y Flujos de trabajo EF
¿Prefiere especificar un código de escritura de modelos de EF o líneas y cuadros de dibujo? ¿Va a usar EF
para asignar objetos a una base de datos existente o quiere que cree una base de datos específica para los
objetos? Aquí podrá obtener información sobre dos enfoques diferentes para usar EF6: EF Designer y Code
First. Asegúrese de seguir el debate y vea el vídeo sobre las diferencias.
DbContext es el primer tipo de EF y el más importante. Necesita conocerlo para saber cómo usarlo. Actúa
como plataforma para consultas de bases de datos y mantiene un seguimiento de los cambios que hace a
objetos, de modo que puedan persistir en la base de datos.
Formular una pregunta
Descubra cómo obtener ayuda de expertos y contribuya con sus respuestas a la comunidad.
Colaboracion
Entity Framework 6 usa un modelo de desarrollo abierto. Descubra cómo puede ayudar a asegurarse de que
EF sea aún mejor en nuestro repositorio de GitHub.
Recursos de Code First

Code First en un flujo de trabajo de base de datos existente
Code First en un nuevo flujo de trabajo de base de datos
Asignación de enumeraciones con Code First
Asignación de tipos espaciales con Code First
Creación de convenciones personalizadas e Code First
Usar la configuración de Fluent de Code First con Visual Basic
Code First Migrations in Team Environments (Migraciones de Code First en entornos de equipo)
Automatic Code First Migrations (Migraciones automáticas de Code First, ya no se recomienda)
Recursos de EF Designer
Flujo de trabajo de Database First
Flujo de trabajo de Model First
Asignación de enumeraciones
Asignación de tipos espaciales
Asignación de herencia de tabla por jerarquía
Asignación de herencia de tabla por tipo
Asignación de procedimientos almacenados para actualizaciones
Asignación de procedimientos almacenados para consultas
División de entidades
División de tablas
Defining Query (Definición de consultas, avanzado)
Table-Valued Functions (Funciones con valores de tabla, avanzado)
Otros recursos
Async Query and Save (Guardado y consultas asincrónicas)
Databinding with WinForms (Enlace de datos con WinForms)
Databinding with WPF (Enlace de datos con WPF)
Escenarios desconectados con entidades de autoseguimiento (ya no se recomienda)
Entity Framework está formado por EF Tools para Visual Studio y EF runtime.
EF Tools para Visual Studio

Entity Framework Tools para Visual Studio incluyen EF Designer y el EF Model Wizard y son necesarios para los
flujos de trabajo database first y model first. EF Tools es includo en todas las versiones recientes de Visual Studio.
Si lleva a cabo una instalación personalizada de Visual Studio, deberá asegurarse el elemento "Entity Frameworks
6 Tools" está seleccionado eligiendo un workload que lo incluya o seleccionandolo como un componente
individual.
Para algunas versiones anteriores de Visual Studio, EF Tools actualizadas están disponibles como descarga.
Consulte versiones de Visual Studio para obtener instrucciones sobre cómo obtener la versión más reciente de
las herramientas de EF disponibles para su versión de Visual Studio.
EF runtime
La versión más reciente de Entity Framework está disponible como el paquete NuGet EntityFramework. Si no está
familiarizado con el administrador de paquetes NuGet, le recomendamos que lea la información general de
Nuget.
Instalar EF NuGet package
Para instalar el paquete EntityFramework, haga clic con el botón derecho en la carpeta referencias del proyecto
y seleccione administrar paquetes NuGet.. .
Instalación desde Package Manager Console

Como alternativa, puede instalar EntityFramework ejecutando el siguiente comando en la consola del
Administrador de paquetes.
Install-Package EntityFramework
Instalación de una versión específica de EF

Desde EF 4,1 en adelante, se han publicado nuevas versiones del tiempo de ejecución de EF como el paquete
NuGet EntityFramework. Cualquiera de esas versiones se puede Agregar a un proyecto basado en .NET
Framework ejecutando el siguiente comando en la consola del administrador de paquetesde Visual Studio:
Install-Package EntityFramework -Version <number>
Tenga en cuenta que <number> representa la versión específica de EF que se va a instalar. Por ejemplo, 6.2.0 es la
versión del número para EF 6,2.
Los EF runtimes anteriores a 4.1 formaban parte de .NET Framework y no se puede instalar por separado.
Instalación de la versión preliminar más reciente
Los métodos anteriores le proporcionarán la versión más reciente totalmente compatible con la versión de Entity
Framework. A menudo hay versiones preliminares disponibles de Entity Framework que nos encantaría que
probara y de las que puede enviarnos sus comentarios.
Para instalar la versión preliminar más reciente de EntityFramework, puede seleccionar incluir versión
preliminar en la ventana administrar paquetes NuGet. Si no hay ninguna versión preliminar disponible
automáticamente obtendrá la última versión compatible de Entity Framework.
Como alternativa, puede ejecutar el siguiente comando en la consola del administrador de paquetes.
Install-Package EntityFramework -Pre

Para usar Entity Framework para consultar, insertar, actualizar y eliminar datos mediante objetos .NET, primero
debe crear un modelo que asigne las entidades y relaciones que se definen en el modelo a las tablas de una base
de datos.
Una vez que tiene un modelo, la clase principal con la que interactúa la aplicación es System.Data.Entity.DbContext
(a menudo se conoce como la clase de contexto). Puede usar un DbContext asociado a un modelo para:
Escribir y ejecutar consultas
Materializar resultados de una consulta como objetos entidad
Realizar un seguimiento de los cambios realizados en esos objetos
Almacenar los cambios del objeto en la base de datos
Enlazar objetos en memoria a controles de interfaz de usuario
En esta página se proporcionan instrucciones sobre cómo administrar la clase de contexto.
Definir una clase derivada de DbContext

La manera recomendada para trabajar con el contexto es definir una clase que derive de DbContext y exponga las
propiedades DbSet que representan colecciones de las entidades especificadas en el contexto. Si está trabajando
con el diseñador de EF, el contexto se generará automáticamente. Si está trabajando con Code First, normalmente
usted mismo escribirá el contexto.
public class ProductContext : DbContext

{
public DbSet<Category> Categories { get; set; }
public DbSet<Product> Products { get; set; }
}
Una vez que tenga un contexto, debe consultar, agregar (mediante métodos Add o Attach ) o quitar (mediante
Remove ) entidades en el contexto mediante estas propiedades. El acceso a una propiedad de DbSet en un objeto
de contexto representa una consulta de inicio que devuelve todas las entidades del tipo especificado. Tenga en
cuenta acceder a la propiedad no ejecutará la consulta. Una consulta se ejecuta cuando:
Se enumera mediante una instrucción foreach (C#) o For Each (Visual Basic).
Se enumera mediante una operación de recopilación como ToArray , ToDictionary o ToList .
Los operadores de LINQ como First o Any se especifican en la parte más externa de la consulta.
Se llama a uno de los métodos siguientes: el método de extensión Load , DbEntityEntry.Reload ,
Database.ExecuteSqlCommand y DbSet<T>.Find , si no se encuentra una entidad con la clave especificada en el
contexto.
Vigencia
La duración del contexto comienza cuando se crea y finaliza cuando la instancia se elimina o es recogida por el
recolector de basura. Use el uso de si desea que todos los recursos que controla el contexto se eliminen al final del
bloque. Cuando se usa con , el compilador crea automáticamente un bloque try/finally y llama a Dispose en el
bloque Finally .
public void UseProducts()
{
using (var context = new ProductContext())
{
// Perform data access using the context
}
}
Estas son algunas directrices generales a la hora de decidir la duración del contexto:
Al trabajar con aplicaciones Web, use una instancia de contexto por solicitud.
Al trabajar con Windows Presentation Foundation (WPF) o Windows Forms, utilice una instancia de contexto
por formulario. Esto le permite usar la funcionalidad de seguimiento de cambios que proporciona el contexto.
Si la instancia de contexto se crea un contenedor de inyección de dependencia, normalmente es
responsabilidad del contenedor el eliminar el contexto.
Si el contexto se crea en el código de la aplicación, no olvide eliminar el contexto cuando ya no sea necesario.
Al trabajar con un contexto de ejecución prolongada, tenga en cuenta lo siguiente:
A medida que se cargan más objetos y sus referencias en la memoria, el consumo de memoria del
contexto puede aumentar rápidamente. lo que puede ocasionar problemas de rendimiento.
El contexto no es seguro para subprocesos, por lo tanto no debe compartirse entre varios subprocesos
que realizan el trabajo en él al mismo tiempo.
Si una excepción provoca que el contexto entre en un estado irrecuperable, puede finalizar toda la
aplicación.
Las posibilidades de que haya problemas relacionados con la simultaneidad se incrementan a medida
que aumenta la distancia entre el momento en que se consultan los datos y el momento en que se
actualizan.
Conexiones
De forma predeterminada, el contexto administra las conexiones a la base de datos. El contexto abre y cierra las
conexiones según sea necesario. Por ejemplo, el contexto abre una conexión para ejecutar una consulta y, a
continuación, cierra la conexión cuando se han procesado todos los conjuntos de resultados.
Hay casos en los que se desea más control sobre el momento en que se abre y cierra la conexión. Por ejemplo, al
trabajar con SQL Server Compact, a menudo se recomienda mantener una conexión abierta independiente con la
base de datos mientras dure la aplicación para mejorar el rendimiento. Puede administrar este proceso
manualmente mediante la propiedad Connection .
Relaciones, propiedades de navegación y claves
externas
En este artículo se proporciona información general sobre cómo Entity Framework administra las relaciones entre
entidades. También proporciona instrucciones sobre cómo asignar y manipular relaciones.
Relaciones en EF
En las bases de datos relacionales, las relaciones (también denominadas asociaciones) entre las tablas se definen
mediante claves externas. Una clave externa (FK) es una columna o combinación de columnas que se utiliza para
establecer y exigir un vínculo entre los datos de dos tablas. Por lo general, hay tres tipos de relaciones: uno a uno,
uno a varios y varios a varios. En una relación de uno a varios, la clave externa se define en la tabla que representa
el extremo de la relación. La relación de varios a varios implica definir una tercera tabla (denominada tabla de
unión o de combinación), cuya clave principal se compone de las claves externas de ambas tablas relacionadas. En
una relación uno a uno, la clave principal actúa además como clave externa y no hay ninguna columna de clave
externa independiente para cualquiera de las tablas.
En la imagen siguiente se muestran dos tablas que participan en una relación de uno a varios. La tabla Course es
la tabla dependiente porque contiene la columna depar tmentId que la vincula a la tabla Depar tment .
En Entity Framework, una entidad se puede relacionar con otras entidades a través de una asociación o relación.
Cada relación contiene dos extremos que describen el tipo de entidad y la multiplicidad del tipo (uno, cero o uno o
varios) para las dos entidades de esa relación. La relación se puede gobernar por una restricción referencial, que
describe qué extremo de la relación es un rol principal y que es un rol dependiente.
Las propiedades de navegación proporcionan una manera de navegar por una asociación entre dos tipos de
entidad. Cada objeto puede tener una propiedad de navegación para cada relación en la que participa. Las
propiedades de navegación permiten navegar y administrar las relaciones en ambas direcciones, devolviendo un
objeto de referencia (si la multiplicidad es uno o cero o uno) o una colección (si la multiplicidad es muchas).
También puede optar por tener una navegación unidireccional, en cuyo caso definirá la propiedad de navegación
solo en uno de los tipos que participan en la relación y no en ambos.
Se recomienda incluir las propiedades en el modelo que se asignan a las claves externas en la base de datos. Con
las propiedades de clave externa incluidas, puede crear o cambiar una relación modificando el valor de clave
externa sobre un objeto dependiente. Este tipo de asociación se denomina asociación de clave externa. El uso de
claves externas es incluso más importante cuando se trabaja con entidades desconectadas. Tenga en cuenta que al
trabajar con de 1 a 1 o de 1 a 0. 1 relaciones, no hay ninguna columna de clave externa independiente, la
propiedad de clave principal actúa como clave externa y siempre se incluye en el modelo.
Cuando las columnas de clave externa no se incluyen en el modelo, la información de asociación se administra
como un objeto independiente. Se realiza un seguimiento de las relaciones a través de referencias de objeto en
lugar de propiedades de clave externa. Este tipo de asociación se denomina asociación independiente. La manera
más común de modificar una asociación independiente es modificar las propiedades de navegación que se
generan para cada entidad que participa en la asociación.
Puede decidir entre utilizar uno o ambos tipos de asociaciones en su modelo. Sin embargo, si tiene una relación de
varios a varios pura que está conectada mediante una tabla de combinación que solo contiene claves externas, el
EF usará una asociación independiente para administrar dicha relación de varios a varios.
La siguiente imagen muestra un modelo conceptual que se creó con el Entity Framework Designer. El modelo
contiene dos entidades que participan en una relación de uno a varios. Ambas entidades tienen propiedades de
navegación. Course es la entidad dependiente y tiene definida la propiedad de clave externa depar tmentId .
En el fragmento de código siguiente se muestra el mismo modelo que se creó con Code First.
public class Course

{
public int CourseID { get; set; }
public int Credits { get; set; }
public int DepartmentID { get; set; }
public virtual Department Department { get; set; }
}
public class Department

{
public Department()
{
this.Courses = new HashSet<Course>();
}
public decimal Budget { get; set; }
public DateTime StartDate { get; set; }
public int? Administrator {get ; set; }
public virtual ICollection<Course> Courses { get; set; }
}
Configurar o asignar relaciones

En el resto de esta página se explica cómo obtener acceso a los datos y cómo manipularlos mediante relaciones.
Para obtener información sobre cómo configurar las relaciones en el modelo, vea las páginas siguientes.
Para configurar relaciones en Code First, vea anotaciones de datos y API fluida: relaciones.
Para configurar relaciones mediante el Entity Framework Designer, consulte relaciones con el diseñador de EF.
Crear y modificar relaciones

En una Asociación de clave externa, al cambiar la relación, el estado de un objeto dependiente con un estado de
EntityState.Unchanged cambia a EntityState.Modified . En una relación independiente, al cambiar la relación no
se actualiza el estado del objeto dependiente.
En los siguientes ejemplos se muestra cómo usar las propiedades de clave externa y las propiedades de
navegación para asociar los objetos relacionados. Con las asociaciones de clave externa, puede usar cualquiera de
los métodos para cambiar, crear o modificar las relaciones. Con asociaciones independientes, no puede utilizar la
propiedad de clave externa.
Mediante la asignación de un nuevo valor a una propiedad de clave externa, como en el ejemplo siguiente.
course.DepartmentID = newCourse.DepartmentID;
En el código siguiente se quita una relación estableciendo la clave externa en null . Tenga en cuenta que la
propiedad de clave externa debe admitir valores NULL.
course.DepartmentID = null;
NOTE
Si la referencia se encuentra en el estado Added (en este ejemplo, el objeto Course), la propiedad de navegación
Reference no se sincronizará con los valores de clave de un nuevo objeto hasta que se llame a SaveChanges. La
sincronización no se produce porque el contexto del objeto no contiene claves permanentes para objetos agregados
hasta que se guardan. Si debe tener nuevos objetos sincronizados completamente en cuanto establezca la relación,
use uno de los métodos siguientes. *
Asignando un nuevo objeto a una propiedad de navegación. En el código siguiente se crea una relación
entre un curso y un department . Si los objetos están asociados al contexto, el course también se agrega a
la colección department.Courses y la propiedad de clave externa correspondiente en el objeto course se
establece en el valor de la propiedad clave del Departamento.
course.Department = department;
Para eliminar la relación, establezca la propiedad de navegación en null . Si está trabajando con Entity
Framework basado en .NET 4,0, el extremo relacionado debe cargarse antes de establecerlo en NULL. Por
ejemplo:
context.Entry(course).Reference(c => c.Department).Load();

course.Department = null;
A partir de Entity Framework 5,0, que se basa en .NET 4,5, puede establecer la relación en NULL sin cargar
el extremo relacionado. También puede establecer el valor actual en NULL mediante el método siguiente.
context.Entry(course).Reference(c => c.Department).CurrentValue = null;
Eliminando o agregando un objeto en una colección de entidades. Por ejemplo, puede Agregar un objeto de
tipo Course a la colección department.Courses . Esta operación crea una relación entre un curso
determinado y un department determinado. Si los objetos están asociados al contexto, la referencia de
departamento y la propiedad de clave externa del objeto Course se establecerán en el department
adecuado.
department.Courses.Add(newCourse);
Mediante el método ChangeRelationshipState para cambiar el estado de la relación especificada entre dos
objetos entidad. Este método se utiliza normalmente cuando se trabaja con aplicaciones de N niveles y una
asociación independiente (no se puede usar con una asociación de clave externa). Además, para utilizar este
método debe desplegar en ObjectContext , como se muestra en el ejemplo siguiente.
En el ejemplo siguiente, hay una relación de varios a varios entre instructores y cursos. Llamar al método
ChangeRelationshipState y pasar el parámetro EntityState.Added , permite al SchoolContext saber que se
ha agregado una relación entre los dos objetos:
((IObjectContextAdapter)context).ObjectContext.
ObjectStateManager.
ChangeRelationshipState(course, instructor, c => c.Instructor, EntityState.Added);
Tenga en cuenta que si está actualizando (no solo agregando) una relación, debe eliminar la relación
anterior después de agregar la nueva:
((IObjectContextAdapter)context).ObjectContext.
ObjectStateManager.
ChangeRelationshipState(course, oldInstructor, c => c.Instructor, EntityState.Deleted);
Sincronizar los cambios entre las claves externas y las propiedades de

navegación
Al cambiar la relación de los objetos adjuntos al contexto mediante uno de los métodos descritos anteriormente,
Entity Framework necesita mantener sincronizadas las claves externas, las referencias y las colecciones. Entity
Framework administra automáticamente esta sincronización (también conocida como corrección de relación) para
las entidades POCO con servidores proxy. Para obtener más información, consulte trabajar con servidores proxy.
Si usa entidades POCO sin proxy, debe asegurarse de que se llama al método DetectChanges para sincronizar
los objetos relacionados en el contexto. Tenga en cuenta que las siguientes API desencadenan automáticamente
una llamada a DetectChanges .
DbSet.Add
DbSet.AddRange
DbSet.Remove
DbSet.RemoveRange
DbSet.Find
DbSet.Local
DbContext.SaveChanges
DbSet.Attach
DbContext.GetValidationErrors
DbContext.Entry
DbChangeTracker.Entries
Ejecutar una consulta LINQ en un DbSet
Cargar objetos relacionados

En Entity Framework normalmente se usan las propiedades de navegación para cargar entidades relacionadas con
la entidad devuelta por la Asociación definida. Para obtener más información, vea cargar objetos relacionados.
NOTE
En una asociación de clave externa, al cargar un extremo relacionado de un objeto dependiente, el objeto relacionado se
cargará dependiendo del valor de clave externa del objeto dependiente actualmente en memoria:
// Get the course where currently DepartmentID = 2.

Course course2 = context.Courses.First(c=>c.DepartmentID == 2);
// Use DepartmentID foreign key property

// to change the association.
course2.DepartmentID = 3;
// Load the related Department where DepartmentID = 3

context.Entry(course).Reference(c => c.Department).Load();
En una asociación independiente, se consulta el extremo relacionado de un objeto dependiente de acuerdo con el
valor de clave externa actualmente en la base de datos. Sin embargo, si se modificó la relación y la propiedad
Reference del objeto dependiente apunta a un objeto principal diferente que se carga en el contexto del objeto,
Entity Framework intentará crear una relación tal y como se define en el cliente.
Administrar la simultaneidad
En las asociaciones de clave externa e independiente, las comprobaciones de simultaneidad se basan en las claves
de entidad y otras propiedades de entidad que se definen en el modelo. Al usar EF Designer para crear un modelo,
establezca el atributo ConcurrencyMode en fixed para especificar que se debe comprobar la simultaneidad de la
propiedad. Al utilizar Code First para definir un modelo, use la anotación ConcurrencyCheck en las propiedades
cuya simultaneidad desea comprobar. Al trabajar con Code First también puede usar la anotación TimeStamp para
especificar que se debe comprobar la simultaneidad de la propiedad. Solo puede tener una propiedad timestamp
en una clase determinada. Code First asigna esta propiedad a un campo que no acepta valores NULL en la base de
datos.
Se recomienda usar siempre la Asociación de clave externa al trabajar con entidades que participan en la
comprobación de simultaneidad y la resolución.
Para obtener más información, vea controlar los conflictos de simultaneidad.
Trabajar con claves superpuestas

Las claves superpuestas son claves compuestas en las que algunas propiedades de la clave también forman parte
de otra clave de la entidad. No es posible tener una clave superpuesta en una asociación independiente. Para
cambiar una asociación de clave externa que incluya claves superpuestas, recomendamos modificar los valores de
clave externa en lugar de utilizar las referencias a objetos.
Consulta asincrónica y guardar
NOTE
Solo EF6 y versiones posteriores : las características, las API, etc. que se tratan en esta página se han incluido a partir de
Entity Framework 6. Si usa una versión anterior, no se aplica parte o la totalidad de la información.
EF6 presentó la compatibilidad con la consulta asincrónica y la guarda con las palabras clave Async y Await que se
introdujeron en .net 4,5. Aunque no todas las aplicaciones pueden beneficiarse de asincronía, se puede usar para
mejorar la capacidad de respuesta del cliente y la escalabilidad del servidor al administrar tareas de ejecución
prolongada, de red o enlazadas a e/s.
Cuándo usar realmente Async

El propósito de este tutorial es presentar los conceptos de Async de una manera que facilite la observación de la
diferencia entre la ejecución de programas asincrónica y sincrónica. Este tutorial no pretende ilustrar ninguno de
los escenarios clave donde la programación asincrónica proporciona ventajas.
La programación asincrónica se centra principalmente en liberar el subproceso administrado actual (subproceso
que ejecuta código .NET) para realizar otro trabajo mientras espera una operación que no requiere tiempo de
proceso de un subproceso administrado. Por ejemplo, mientras el motor de base de datos está procesando una
consulta, no hay nada que hacer por código .NET.
En las aplicaciones cliente (WinForms, WPF, etc.), el subproceso actual se puede usar para mantener la capacidad
de respuesta de la interfaz de usuario mientras se realiza la operación asincrónica. En las aplicaciones de servidor
(ASP.NET etc.), el subproceso se puede usar para procesar otras solicitudes entrantes; esto puede reducir el uso de
memoria o aumentar el rendimiento del servidor.
En la mayoría de las aplicaciones que usan Async no tendrá ventajas apreciables e incluso podría ser perjudicial.
Use las pruebas, la generación de perfiles y el sentido común para medir el impacto de Async en su escenario
concreto antes de confirmarlo.
Estos son algunos recursos adicionales para obtener información sobre Async:
Información general de Brandon Bray de Async/Await en .NET 4,5
Páginas de programación asincrónicas en MSDN Library
Cómo crear aplicaciones Web de ASP.net mediante Async (incluye una demostración del aumento del
rendimiento del servidor)
Creación del modelo

Usaremos el flujo de trabajo Code First para crear nuestro modelo y generar la base de datos; sin embargo, la
funcionalidad asincrónica funcionará con todos los modelos EF, incluidos los creados con el diseñador EF.
Crear una aplicación de consola y llamarla AsyncDemo
Adición del paquete NuGet de EntityFramework
En Explorador de soluciones, haga clic con el botón derecho en el proyecto AsyncDemo
Seleccione administrar paquetes NuGet.. .
En el cuadro de diálogo administrar paquetes NuGet, seleccione la pestaña en línea y elija el paquete
EntityFramework
Haga clic en Instalar .
Agregue una clase Model.CS con la siguiente implementación
using System.Data.Entity;
namespace AsyncDemo
{
{
}
public class Blog

{
public virtual List<Post> Posts { get; set; }

}
public class Post

{

}
}
Crear un programa sincrónico

Ahora que tenemos un modelo EF, vamos a escribir código que lo usa para realizar algún acceso a los datos.
Reemplace el contenido de Program.CS por el código siguiente.
using System;
using System.Linq;
namespace AsyncDemo
{
class Program
{
static void Main(string[] args)
{
PerformDatabaseOperations();
Console.WriteLine("Quote of the day");

Console.WriteLine(" Don't worry about the world coming to an end today... ");
Console.WriteLine(" It's already tomorrow in Australia.");
Console.WriteLine("Press any key to exit...");
Console.ReadKey();
}
public static void PerformDatabaseOperations()

{
{
// Create a new blog and save it
db.Blogs.Add(new Blog
{
Name = "Test Blog #" + (db.Blogs.Count() + 1)
});
Console.WriteLine("Calling SaveChanges.");
db.SaveChanges();
Console.WriteLine("SaveChanges completed.");
// Query for all blogs ordered by name

Console.WriteLine("Executing query.");
var blogs = (from b in db.Blogs
orderby b.Name
select b).ToList();
// Write all blogs out to Console

Console.WriteLine("Query completed with following results:");
foreach (var blog in blogs)
{
Console.WriteLine(" " + blog.Name);
}
}
}
}
}
Este código llama al método PerformDatabaseOperations , que guarda un nuevo blog en la base de datos y, a
continuación, recupera todos los blogs de la base de datos y los imprime en la consola . Después, el programa
escribe una comilla del día en la consola .
Dado que el código es sincrónico, podemos observar el siguiente flujo de ejecución al ejecutar el programa:
1. SaveChanges comienza a introducir el nuevo blog en la base de datos
2. SaveChanges completado
3. La consulta de todos los blogs se envía a la base de datos
4. Las devoluciones de consultas y los resultados se escriben en la consola
5. La oferta del día se escribe en la consola
Convertirlo en asincrónico
Ahora que tenemos nuestro programa en funcionamiento, podemos empezar a usar las nuevas palabras clave
Async y Await. Hemos realizado los siguientes cambios en Program.cs
1. Línea 2: la instrucción using del espacio de nombres System. Data. Entity nos permite acceder a los métodos
de extensión de EF Async.
2. Línea 4: la instrucción using del espacio de nombres System. Threading. Tasks nos permite usar el tipo de
tarea .
3. Línea 12 & 18: estamos capturando como tarea que supervisa el progreso de
PerformSomeDatabaseOperations (línea 12) y, después, bloqueando la ejecución del programa para que
esta tarea se complete una vez que todo el trabajo para el programa se haya realizado (línea 18).
4. Línea 25: hemos actualizado PerformSomeDatabaseOperations para que se marque como Async y
devuelva una tarea .
5. Línea 35: ahora se llama a la versión asincrónica de SaveChanges y se espera su finalización.
6. Línea 42: ahora se llama a la versión asincrónica de ToList y se espera en el resultado.
Para obtener una lista completa de los métodos de extensión disponibles en el espacio de nombres System. Data.
Entity, consulte la clase QueryableExtensions. También deberá agregar "Using System. Data. Entity" a las
instrucciones using.
using System;
using System.Linq;
using System.Threading.Tasks;
namespace AsyncDemo
{
class Program
{
{
var task = PerformDatabaseOperations();
Console.WriteLine("Quote of the day");

Console.WriteLine(" Don't worry about the world coming to an end today... ");
Console.WriteLine(" It's already tomorrow in Australia.");
task.Wait();
Console.ReadKey();
}
public static async Task PerformDatabaseOperations()

{
{
// Create a new blog and save it
db.Blogs.Add(new Blog
{
Name = "Test Blog #" + (db.Blogs.Count() + 1)
});
Console.WriteLine("Calling SaveChanges.");
await db.SaveChangesAsync();
Console.WriteLine("SaveChanges completed.");
// Query for all blogs ordered by name

Console.WriteLine("Executing query.");
var blogs = await (from b in db.Blogs
orderby b.Name
select b).ToListAsync();
// Write all blogs out to Console

Console.WriteLine("Query completed with following results:");
{
Console.WriteLine(" - " + blog.Name);
}
}
}
}
}
Ahora que el código es asincrónico, podemos observar otro flujo de ejecución cuando se ejecuta el programa:
1. SaveChanges comienza a introducir el nuevo blog en la base de datos
Una vez que el comando se envía a la base de datos, no se necesita más tiempo de proceso en el subproceso
administrado actual. El método PerformDatabaseOperations devuelve (aunque no ha terminado de
ejecutarse) y continúa el flujo del programa en el método Main.
2. La ofer ta del día se escribe en la consola
Dado que no hay más trabajo que hacer en el método Main, el subproceso administrado se bloquea en la
llamada de espera hasta que se completa la operación de base de datos. Una vez que se completa, se ejecutará
el resto de PerformDatabaseOperations .
3. SaveChanges completado
4. La consulta de todos los blogs se envía a la base de datos
De nuevo, el subproceso administrado es gratuito para realizar otro trabajo mientras la consulta se procesa en
la base de datos. Dado que el resto de la ejecución se ha completado, el subproceso se detendrá simplemente
en la llamada de espera.
5. Las devoluciones de consultas y los resultados se escriben en la consola
La ventaja
Ahora hemos visto lo fácil que es hacer uso de los métodos asincrónicos de EF. Aunque es posible que las ventajas
de Async no sean muy evidentes con una aplicación de consola sencilla, se pueden aplicar estas mismas
estrategias en situaciones en las que las actividades de ejecución prolongada o enlazadas a la red podrían
bloquear la aplicación, o provocar que un gran número de subprocesos aumentar la superficie de memoria.
Configuración basada en código
NOTE
Solo EF6 y versiones posteriores : las características, las API, etc. que se tratan en esta página se han incluido a partir
de Entity Framework 6. Si usa una versión anterior, no se aplica parte o la totalidad de la información.
La configuración de una aplicación Entity Framework se puede especificar en un archivo de configuración (App.
config/Web. config) o mediante código. Este último se conoce como configuración basada en código.
La configuración de un archivo de configuración se describe en un artículo independiente. El archivo de
configuración tiene prioridad sobre la configuración basada en código. En otras palabras, si se establece una
opción de configuración en el código y en el archivo de configuración, se usa la configuración del archivo de
configuración.
Usar DbConfiguration
La configuración basada en código en EF6 y versiones posteriores se consigue mediante la creación de una
subclase de System. Data. Entity. config. DbConfiguration. Se deben seguir las siguientes directrices para crear
subclases de DbConfiguration:
Cree solo una clase DbConfiguration para la aplicación. Esta clase especifica la configuración de todo el
dominio de aplicación.
Coloque la clase DbConfiguration en el mismo ensamblado que la clase DbContext. (Consulte la sección
mover DbConfiguration si desea cambiar esto).
Asigne a la clase DbConfiguration un constructor sin parámetros público.
Establezca las opciones de configuración llamando a métodos DbConfiguration protegidos desde dentro de
este constructor.
Si sigue estas instrucciones, EF podrá detectar y usar la configuración automáticamente con las herramientas que
necesiten tener acceso a su modelo y cuando se ejecute la aplicación.
Ejemplo
Una clase derivada de DbConfiguration podría tener el siguiente aspecto:
using System.Data.Entity.Infrastructure;
using System.Data.Entity.SqlServer;
namespace MyNamespace
{
public class MyConfiguration : DbConfiguration
{
public MyConfiguration()
{
SetExecutionStrategy("System.Data.SqlClient", () => new SqlAzureExecutionStrategy());
SetDefaultConnectionFactory(new LocalDbConnectionFactory("mssqllocaldb"));
}
}
}
Esta clase establece EF para usar la estrategia de ejecución de SQL Azure: para reintentar automáticamente las
operaciones de base de datos con errores y para usar la base de datos local para las bases de datos creadas por
Convención desde Code First.
Mover DbConfiguration
Hay casos en los que no es posible colocar la clase DbConfiguration en el mismo ensamblado que la clase
DbContext. Por ejemplo, puede tener dos clases DbContext cada una en ensamblados distintos. Hay dos opciones
para controlar esto.
La primera opción es usar el archivo de configuración para especificar la instancia de DbConfiguration que se va
a usar. Para ello, establezca el atributo codeConfigurationType de la sección entityFramework. Por ejemplo:
<entityFramework codeConfigurationType="MyNamespace.MyDbConfiguration, MyAssembly">

...Your EF config...
</entityFramework>
El valor de codeConfigurationType debe ser el ensamblado y el nombre completo del espacio de nombres de la
clase DbConfiguration.
La segunda opción consiste en colocar DbConfigurationTypeAttribute en la clase de contexto. Por ejemplo:
[DbConfigurationType(typeof(MyDbConfiguration))]
public class MyContextContext : DbContext
{
}
El valor que se pasa al atributo puede ser el tipo DbConfiguration, como se muestra arriba, o el ensamblado y el
nombre de espacio de nombres de tipo completo String. Por ejemplo:
[DbConfigurationType("MyNamespace.MyDbConfiguration, MyAssembly")]
public class MyContextContext : DbContext
{
}
Establecer DbConfiguration explícitamente

Hay algunas situaciones en las que puede ser necesaria la configuración antes de que se haya usado cualquier
tipo DbContext. Estos son algunos ejemplos:
Usar DbModelBuilder para compilar un modelo sin un contexto
Usar algún otro código de la utilidad o del marco de trabajo que usa un DbContext donde ese contexto se usa
antes de que se use el contexto de la aplicación
En estas situaciones, EF no puede detectar la configuración automáticamente y, en su lugar, debe realizar una de
las siguientes acciones:
Establezca el tipo DbConfiguration en el archivo de configuración, como se describe en la sección anterior
DbConfiguration
Llame al método estático DbConfiguration. SetConfiguration durante el inicio de la aplicación.
Invalidar DbConfiguration
Hay algunas situaciones en las que es necesario invalidar el conjunto de configuración en DbConfiguration.
Normalmente, no lo hacen los desarrolladores de aplicaciones, sino los proveedores y complementos de terceros
que no pueden usar una clase derivada de DbConfiguration.
Para ello, EntityFramework permite registrar un controlador de eventos que puede modificar la configuración
existente justo antes de que se bloquee. También proporciona un método de azúcar específico para reemplazar
cualquier servicio devuelto por el localizador del servicio EF. Así es como se pretende usar:
En el inicio de la aplicación (antes de que se use EF), el complemento o el proveedor deben registrar el método
de control de eventos para este evento. (Tenga en cuenta que esto debe ocurrir antes de que la aplicación use
EF).
El controlador de eventos realiza una llamada a ReplaceService para cada servicio que debe reemplazarse.
Por ejemplo, para reemplazar IDbConnectionFactory y DbProviderService, debe registrar un controlador similar
al siguiente:
DbConfiguration.Loaded += (_, a) =>

{
a.ReplaceService<DbProviderServices>((s, k) => new MyProviderServices(s));
a.ReplaceService<IDbConnectionFactory>((s, k) => new MyConnectionFactory(s));
};
En el código anterior MyProviderServices y MyConnectionFactory se representan las implementaciones del

servicio.
También puede agregar controladores de dependencia adicionales para obtener el mismo efecto.
Tenga en cuenta que también puede incluir DbProviderFactory de esta manera, pero esto solo afectará a EF y no
usará el DbProviderFactory fuera de EF. Por esta razón, es probable que desee seguir ajustando
DbProviderFactory como antes.
También debe tener en cuenta los servicios que se ejecutan externamente en la aplicación; por ejemplo, cuando se
ejecutan migraciones desde la consola del administrador de paquetes. Al ejecutar la migración desde la consola,
intentará encontrar su DbConfiguration. Sin embargo, tanto si obtendrá el servicio ajustado como si no depende
de dónde se registró el controlador de eventos. Si se registra como parte de la construcción de DbConfiguration,
el código debe ejecutarse y el servicio debe ajustarse. Normalmente, este no es el caso y esto significa que las
herramientas no obtendrán el servicio ajustado.
Configuración del archivo de configuración
Entity Framework permite especificar una serie de valores desde el archivo de configuración. En general, EF sigue
un comportamiento de "Convención sobre configuración": todos los valores de configuración descritos en esta
publicación tienen un comportamiento predeterminado, solo tiene que preocuparse por cambiar el valor cuando
el valor predeterminado ya no satisface sus requisitos.
Una alternativa basada en código

Todos estos valores también se pueden aplicar mediante código. A partir de EF6, se presentó la configuración
basada en código, que proporciona una manera centralizada de aplicar la configuración desde el código. Antes de
EF6, todavía se puede aplicar la configuración desde el código, pero es necesario usar varias API para configurar
distintas áreas. La opción del archivo de configuración permite cambiar fácilmente esta configuración durante la
implementación sin necesidad de actualizar el código.
La sección de configuración Entity Framework

A partir de EF 4.1, podría establecer el inicializador de base de datos para un contexto mediante la sección
appSettings del archivo de configuración. En EF 4,3, se presentó la sección entityFramework personalizada
para controlar la nueva configuración. Entity Framework seguirá reconociendo los inicializadores de base de
datos establecidos con el formato antiguo, pero se recomienda pasar al nuevo formato siempre que sea posible.
La sección entityFramework se agregó automáticamente al archivo de configuración del proyecto al instalar el
paquete NuGet entityFramework.
<?xml version="1.0" encoding="utf-8"?>

<configuration>
<configSections>

<section name="entityFramework"
type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=4.3.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089" />
</configSections>
</configuration>
En esta página se proporcionan más detalles sobre cómo Entity Framework determina la base de datos que se va
a usar, incluidas las cadenas de conexión en el archivo de configuración.
Las cadenas de conexión van en el elemento connectionStrings estándar y no requieren la sección
entityFramework .
Los modelos basados en Code First usan cadenas de conexión ADO.NET normales. Por ejemplo:
<connectionStrings>
<add name="BlogContext"
providerName="System.Data.SqlClient"
connectionString="Server=.\SQLEXPRESS;Database=Blogging;Integrated Security=True;"/>
Los modelos basados en el diseñador EF usan cadenas de conexión EF especiales. Por ejemplo:
<connectionStrings>
<add name="BlogContext"
connectionString=
"metadata=
res://*/BloggingModel.csdl|
res://*/BloggingModel.ssdl|
res://*/BloggingModel.msl;
provider=System.Data.SqlClient;
provider connection string=
"data source=(localdb)\mssqllocaldb;
initial catalog=Blogging;
integrated security=True;
multipleactiveresultsets=True;""
providerName="System.Data.EntityClient" />
Tipo de configuración basada en código (EF6 en adelante)

A partir de EF6, puede especificar el DbConfiguration para EF que se va a usar para la configuración basada en
código en la aplicación. En la mayoría de los casos, no es necesario especificar esta configuración, ya que EF
detectará automáticamente el DbConfiguration. Para obtener detalles sobre Cuándo es posible que tenga que
especificar DbConfiguration en el archivo de configuración, consulte la sección mover DbConfiguration de
configuración basada en código.
Para establecer un tipo DbConfiguration, especifique el nombre del tipo calificado con el ensamblado en el
elemento codeConfigurationType .
NOTE
Un nombre completo de ensamblado es el nombre completo del espacio de nombres, seguido de una coma, el ensamblado
en el que reside el tipo. También puede especificar la versión del ensamblado, la referencia cultural y el token de clave
pública.
<entityFramework codeConfigurationType="MyNamespace.MyConfiguration, MyAssembly">

</entityFramework>
Proveedores de bases de datos de EF (EF6 en adelante)

Antes de EF6, los elementos específicos de Entity Framework de un proveedor de base de datos debían incluirse
como parte del proveedor ADO.NET básico. A partir de EF6, las partes específicas de EF ahora se administran y
registran por separado.
Normalmente no necesitará registrar los proveedores. Esto lo realiza normalmente el proveedor cuando se
instala.
Los proveedores se registran mediante la inclusión de un elemento de proveedor en la sección de proveedores
secundarios de la sección entityFramework . Hay dos atributos necesarios para una entrada de proveedor:
invariantName identifica el proveedor ADO.net principal al que se destina este proveedor EF
Type es el nombre de tipo calificado con el ensamblado de la implementación del proveedor EF
NOTE
pública.
Como ejemplo, aquí se muestra la entrada que se crea para registrar el proveedor de SQL Server predeterminado
al instalar Entity Framework.
<providers>
<provider invariantName="System.Data.SqlClient" type="System.Data.Entity.SqlServer.SqlProviderServices,
EntityFramework.SqlServer" />
</providers>
Interceptores (EF 6.1 y versiones posteriores)

A partir de EF 6.1, puede registrar los interceptores en el archivo de configuración. Los interceptores permiten
ejecutar lógica adicional cuando EF realiza ciertas operaciones, como la ejecución de consultas de base de datos,
la apertura de conexiones, etc.
Los interceptores se registran mediante la inclusión de un elemento interceptor en la sección de interceptores
secundaria de la sección entityFramework . Por ejemplo, la configuración siguiente registra el interceptor de
DatabaseLogger integrado que registrará todas las operaciones de base de datos en la consola.
<interceptors>
<interceptor type="System.Data.Entity.Infrastructure.Interception.DatabaseLogger, EntityFramework"/>
</interceptors>
Registro de operaciones de base de datos en un archivo (EF 6.1 en adelante )

El registro de los interceptores mediante el archivo de configuración es especialmente útil si desea agregar el
registro a una aplicación existente para ayudar a depurar un problema. DatabaseLogger admite el registro en
un archivo proporcionando el nombre de archivo como un parámetro de constructor.
<interceptors>
<interceptor type="System.Data.Entity.Infrastructure.Interception.DatabaseLogger, EntityFramework">
<parameters>
<parameter value="C:\Temp\LogOutput.txt"/>
</parameters>
</interceptor>
</interceptors>
De forma predeterminada, esto hará que el archivo de registro se sobrescriba con un nuevo archivo cada vez que
se inicie la aplicación. En su lugar, anexe al archivo de registro si ya existe, use algo parecido a:
<interceptors>
<parameters>
<parameter value="C:\Temp\LogOutput.txt"/>
<parameter value="true" type="System.Boolean"/>
</parameters>
</interceptor>
</interceptors>
Para obtener información adicional sobre DatabaseLogger y el registro de interceptores, consulte la entrada de
blog EF 6,1: activar el registro sin volver a compilar.
Code First factoría de conexión predeterminada

La sección configuración permite especificar un generador de conexiones predeterminado que Code First debe
usar para buscar una base de datos que se utilizará para un contexto. El generador de conexiones
predeterminado solo se usa cuando no se ha agregado ninguna cadena de conexión al archivo de configuración
para un contexto.
Al instalar el paquete de NuGet de EF, se registró una factoría de conexión predeterminada que señala a SQL
Express o a LocalDB, en función de la que haya instalado.
Para establecer un generador de conexiones, especifique el nombre del tipo calificado con el ensamblado en el
elemento defaultConnectionFactor y .
NOTE
pública.
A continuación se muestra un ejemplo de configuración de su propio generador de conexiones predeterminado:
<entityFramework>
<defaultConnectionFactory type="MyNamespace.MyCustomFactory, MyAssembly"/>
</entityFramework>
En el ejemplo anterior se requiere que el generador personalizado tenga un constructor sin parámetros. Si es
necesario, puede especificar parámetros de constructor mediante el elemento Parameters .
Por ejemplo, SqlCeConnectionFactory, que se incluye en Entity Framework, requiere que proporcione un nombre
invariable de proveedor al constructor. El nombre invariable del proveedor identifica la versión de SQL Compact
que quiere usar. La configuración siguiente hará que los contextos usen SQL Compact versión 4,0 de forma
predeterminada.
<entityFramework>
<defaultConnectionFactory type="System.Data.Entity.Infrastructure.SqlCeConnectionFactory, EntityFramework">
<parameters>
<parameter value="System.Data.SqlServerCe.4.0" />
</parameters>
</defaultConnectionFactory>
</entityFramework>
Si no establece un generador de conexiones predeterminado, Code First usa SqlConnectionFactory, que apunta a
.\SQLEXPRESS . SqlConnectionFactory también tiene un constructor que permite invalidar partes de la cadena de
conexión. Si desea utilizar una instancia de SQL Server distinta de .\SQLEXPRESS puede usar este constructor para
establecer el servidor.
La configuración siguiente hará que Code First use MyDatabaseSer ver para los contextos que no tienen un
conjunto de cadenas de conexión explícitas.
<entityFramework>
<defaultConnectionFactory type="System.Data.Entity.Infrastructure.SqlConnectionFactory, EntityFramework">
<parameters>
<parameter value="Data Source=MyDatabaseServer; Integrated Security=True;
MultipleActiveResultSets=True" />
</parameters>
</defaultConnectionFactory>
</entityFramework>
De forma predeterminada, se supone que los argumentos del constructor son del tipo cadena. Puede usar el
atributo type para cambiar esto.
<parameter value="2" type="System.Int32" />
Inicializadores de base de datos

Los inicializadores de base de datos se configuran en función del contexto. Se pueden establecer en el archivo de
configuración mediante el elemento de contexto . Este elemento usa el nombre completo del ensamblado para
identificar el contexto que se está configurando.
De forma predeterminada, Code First contextos se configuran para usar el inicializador
CreateDatabaseIfNotExists. Hay un atributo disableDatabaseInitialization en el elemento de contexto que se
puede usar para deshabilitar la inicialización de la base de datos.
Por ejemplo, la siguiente configuración deshabilita la inicialización de la base de datos para el contexto blog.
BlogContext definido en myAssembly. dll.
<contexts>
<context type=" Blogging.BlogContext, MyAssembly" disableDatabaseInitialization="true" />
</contexts>
Puede usar el elemento databaseInitializer para establecer un inicializador personalizado.
<contexts>
<context type=" Blogging.BlogContext, MyAssembly">
<databaseInitializer type="Blogging.MyCustomBlogInitializer, MyAssembly" />
</context>
</contexts>
Los parámetros de constructor utilizan la misma sintaxis que los generadores de conexiones predeterminados.
<contexts>
<context type=" Blogging.BlogContext, MyAssembly">
<databaseInitializer type="Blogging.MyCustomBlogInitializer, MyAssembly">
<parameters>
<parameter value="MyConstructorParameter" />
</parameters>
</databaseInitializer>
</context>
</contexts>
Puede configurar uno de los inicializadores de base de datos genéricos que se incluyen en Entity Framework. El
atributo Type utiliza el formato de .NET Framework para los tipos genéricos.
Por ejemplo, si usa Migraciones de Code First, puede configurar la base de datos que se va a migrar
automáticamente mediante el inicializador de
MigrateDatabaseToLatestVersion<TContext, TMigrationsConfiguration> .
<contexts>
<context type="Blogging.BlogContext, MyAssembly">
<databaseInitializer type="System.Data.Entity.MigrateDatabaseToLatestVersion`2[[Blogging.BlogContext,
MyAssembly], [Blogging.Migrations.Configuration, MyAssembly]], EntityFramework" />
</context>
</contexts>
Cadenas de conexión y modelos
En este tema se explica cómo Entity Framework detecta qué conexión de base de datos se va a usar y cómo se
puede cambiar. Los modelos creados con Code First y EF Designer se describen en este tema.
Normalmente, una aplicación Entity Framework usa una clase derivada de DbContext. Esta clase derivada llamará
a uno de los constructores de la clase base DbContext para controlar:
Cómo se conectará el contexto a una base de datos, es decir, cómo se encuentra o se usa una cadena de
conexión
Si el contexto usará calcular un modelo con Code First o cargar un modelo creado con el diseñador de EF
Opciones avanzadas adicionales
Los siguientes fragmentos muestran algunas de las formas en que se pueden usar los constructores DbContext.
Usar Code First con conexión por Convención

Si no ha realizado ninguna otra configuración en la aplicación, la llamada al constructor sin parámetros en
DbContext hará que DbContext se ejecute en modo de Code First con una conexión de base de datos creada por
Convención. Por ejemplo:
namespace Demo.EF
{
{
// C# will call base class parameterless constructor by default
{
}
}
}
En este ejemplo DbContext usa el nombre completo del espacio de nombres de la clase de contexto derivada
(demo. EF. BloggingContext) como nombre de la base de datos y crea una cadena de conexión para esta base de
datos mediante SQL Express o LocalDB. Si ambos están instalados, se usará SQL Express.
Visual Studio 2010 incluye SQL Express de forma predeterminada y Visual Studio 2012 y versiones posteriores
incluyen LocalDB. Durante la instalación, el paquete NuGet de EntityFramework comprueba qué servidor de base
de datos está disponible. Después, el paquete NuGet actualizará el archivo de configuración estableciendo el
servidor de base de datos predeterminado que Code First usa al crear una conexión por Convención. Si SQL
Express se está ejecutando, se usará. Si SQL Express no está disponible, LocalDB se registrará como
predeterminado en su lugar. No se realiza ningún cambio en el archivo de configuración si ya contiene un valor
para el generador de conexiones predeterminado.
Usar Code First con la conexión por Convención y el nombre de base

de datos especificado
Si no ha realizado ninguna otra configuración en la aplicación, la llamada al constructor de cadena en DbContext
con el nombre de la base de datos que desea usar hará que DbContext se ejecute en modo de Code First con una
conexión de base de datos creada por Convención en la base de datos de ese nombre. Por ejemplo:
{
: base("BloggingDatabase")
{
}
}
En este ejemplo DbContext usa "BloggingDatabase" como nombre de la base de datos y crea una cadena de
conexión para esta base de datos mediante SQL Express (instalado con Visual Studio 2010) o LocalDB (instalado
con Visual Studio 2012). Si ambos están instalados, se usará SQL Express.
Usar Code First con una cadena de conexión en el archivo app.

config/Web. config
Puede optar por colocar una cadena de conexión en el archivo app. config o Web. config. Por ejemplo:
<configuration>
<connectionStrings>
<add name="BloggingCompactDatabase"
providerName="System.Data.SqlServerCe.4.0"
connectionString="Data Source=Blogging.sdf"/>
</configuration>
Esta es una manera fácil de indicar a DbContext que use un servidor de base de datos que no sea SQL Express o
LocalDB; el ejemplo anterior especifica una base de datos de SQL Server Compact Edition.
Si el nombre de la cadena de conexión coincide con el nombre del contexto (ya sea con o sin calificación de
espacio de nombres), DbContext lo buscará cuando se use el constructor sin parámetros. Si el nombre de la
cadena de conexión es diferente del nombre del contexto, puede indicar a DbContext que use esta conexión en el
modo Code First pasando el nombre de la cadena de conexión al constructor DbContext. Por ejemplo:

{
: base("BloggingCompactDatabase")
{
}
}
Como alternativa, puede usar el formato "Name =<nombre de cadena de conexión>" para la cadena que se pasa
al constructor DbContext. Por ejemplo:

{
: base("name=BloggingCompactDatabase")
{
}
}
Este formulario hace que sea explícito esperar que la cadena de conexión se encuentre en el archivo de
configuración. Se producirá una excepción si no se encuentra una cadena de conexión con el nombre especificado.
Base de datos/Model First con una cadena de conexión en el archivo
app. config/Web. config
Los modelos creados con EF Designer son diferentes de Code First en que el modelo ya existe y no se genera a
partir del código cuando se ejecuta la aplicación. El modelo normalmente existe como archivo EDMX en el
proyecto.
El diseñador agregará una cadena de conexión de EF al archivo app. config o Web. config. Esta cadena de conexión
es especial, ya que contiene información sobre cómo encontrar la información en el archivo EDMX. Por ejemplo:
<configuration>
<connectionStrings>
<add name="Northwind_Entities"
connectionString="metadata=res://*/Northwind.csdl|
res://*/Northwind.ssdl|
res://*/Northwind.msl;
provider=System.Data.SqlClient;
provider connection string=
"Data Source=.\sqlexpress;
Initial Catalog=Northwind;
Integrated Security=True;
MultipleActiveResultSets=True""
providerName="System.Data.EntityClient"/>
</configuration>
El diseñador de EF también generará código que indica a DbContext que use esta conexión pasando el nombre de
la cadena de conexión al constructor DbContext. Por ejemplo:
public class NorthwindContext : DbContext

{
public NorthwindContext()
: base("name=Northwind_Entities")
{
}
}
DbContext sabe cargar el modelo existente (en lugar de usar Code First para calcularlo a partir del código) porque
la cadena de conexión es una cadena de conexión EF que contiene los detalles del modelo que se va a usar.
Otras opciones del constructor DbContext

La clase DbContext contiene otros constructores y patrones de uso que permiten algunos escenarios más
avanzados. Algunas de éstas son:
Puede usar la clase DbModelBuilder para crear un modelo de Code First sin crear instancias de una instancia de
DbContext. El resultado de este es un objeto DbModel. Después, puede pasar este objeto DbModel a uno de los
constructores DbContext cuando esté listo para crear la instancia de DbContext.
Puede pasar una cadena de conexión completa a DbContext en lugar de solo la base de datos o el nombre de la
cadena de conexión. De forma predeterminada, esta cadena de conexión se usa con el proveedor System. Data.
SqlClient; Esto se puede cambiar estableciendo una implementación diferente de IConnectionFactory en el
contexto. Database. DefaultConnectionFactory.
Puede usar un objeto DbConnection existente pasándolo a un constructor DbContext. Si el objeto de conexión
es una instancia de EntityConnection, se usará el modelo especificado en la conexión en lugar de calcular un
modelo mediante Code First. Si el objeto es una instancia de algún otro tipo (por ejemplo, SqlConnection), el
contexto lo utilizará para el modo de Code First.
Puede pasar un ObjectContext existente a un constructor DbContext para crear un DbContext que ajuste el
contexto existente. Se puede usar para las aplicaciones existentes que usan ObjectContext pero que desean
aprovechar DbContext en algunas partes de la aplicación.
Resolución de dependencias
NOTE
A partir de EF6, Entity Framework contiene un mecanismo de uso general para obtener implementaciones de
servicios que requiere. Es decir, cuando EF usa una instancia de algunas interfaces o clases base, solicitará una
implementación concreta de la interfaz o la clase base que se va a usar. Esto se logra mediante el uso de la interfaz
IDbDependencyResolver:
public interface IDbDependencyResolver

{
object GetService(Type type, object key);
}
EF normalmente llama al método GetService y se controla mediante una implementación de

IDbDependencyResolver proporcionada por EF o por la aplicación. Cuando se llama, el argumento de tipo es la
interfaz o el tipo de clase base del servicio que se solicita, y el objeto de clave es null o un objeto que proporciona
información contextual sobre el servicio solicitado.
A menos que se indique lo contrario, cualquier objeto devuelto debe ser seguro para subprocesos, ya que se
puede utilizar como singleton. En muchos casos, el objeto devuelto es un generador, en cuyo caso el propio
generador debe ser seguro para subprocesos, pero no es necesario que el objeto devuelto por el generador sea
seguro para subprocesos, ya que se solicita una nueva instancia desde el generador para cada uso.
En este artículo no se incluyen detalles completos sobre cómo implementar IDbDependencyResolver, sino que
actúa como referencia para los tipos de servicio (es decir, la interfaz y los tipos de clase base) para los que EF llama
a GetService y la semántica del objeto de clave para cada uno de estos llama.
System. Data. Entity. IDatabaseInitializer < TContext>

Versión introducida : EF 6.0.0
Objeto devuelto : inicializador de base de datos para el tipo de contexto especificado
Clave : no se utiliza; será null
FUNC < System. Data. Entity. Migrations. SQL. MigrationSqlGenerator>

Objeto devuelto : generador para crear un generador de SQL que se puede usar para las migraciones y otras
acciones que hacen que se cree una base de datos, como la creación de bases de datos con inicializadores de base
de datos.
Key : una cadena que contiene el nombre invariable del proveedor ADO.net que especifica el tipo de base de datos
para el que se generará SQL. Por ejemplo, se devuelve el generador de SQL Server SQL para la clave "System.
Data. SqlClient".
NOTE
Para obtener más información sobre los servicios relacionados con el proveedor en EF6, consulte la sección modelo de
proveedor EF6 .
System. Data. Entity. Core. Common. DbProviderServices

Objeto devuelto : el proveedor EF que se va a usar para un nombre invariable de proveedor determinado
Key : una cadena que contiene el nombre invariable del proveedor ADO.net que especifica el tipo de base de datos
para el que se necesita un proveedor. Por ejemplo, se devuelve el proveedor de SQL Server para la clave "System.
Data. SqlClient".
NOTE
proveedor EF6 .
System. Data. Entity. Infrastructure. IDbConnectionFactory

Objeto devuelto : el generador de conexión que se usará cuando EF cree una conexión de base de datos por
Convención. Es decir, cuando no se proporciona ninguna conexión o cadena de conexión a EF, y no se encuentra
ninguna cadena de conexión en App. config o Web. config, este servicio se usa para crear una conexión por
Convención. Cambiar el generador de conexiones puede permitir que EF use otro tipo de base de datos (por
ejemplo, SQL Server Compact Edition) de forma predeterminada.
NOTE
proveedor EF6 .
System. Data. Entity. Infrastructure. IManifestTokenService

Objeto devuelto : un servicio que puede generar un token del manifiesto del proveedor a partir de una conexión.
Este servicio se usa normalmente de dos maneras. En primer lugar, se puede usar para evitar Code First
conectarse a la base de datos al compilar un modelo. En segundo lugar, se puede usar para forzar Code First para
generar un modelo para una versión de base de datos específica, por ejemplo, para forzar un modelo para SQL
Server 2005 incluso si se usa a veces SQL Server 2008.
Duración del objeto : singleton: el mismo objeto se puede usar varias veces y simultáneamente en diferentes
subprocesos
System. Data. Entity. Infrastructure. IDbProviderFactoryService

Objeto devuelto : un servicio que puede obtener un generador de proveedores de una conexión determinada. En
.NET 4,5, el proveedor es accesible públicamente desde la conexión. En .NET 4, la implementación predeterminada
de este servicio usa algunas heurísticas para encontrar el proveedor coincidente. Si se produce un error, se puede
registrar una nueva implementación de este servicio para proporcionar una solución adecuada.
FUNC < DbContext, System. Data. Entity. Infrastructure.

IDbModelCacheKey>
Objeto devuelto : un generador que generará una clave de caché del modelo para un contexto determinado. De
forma predeterminada, EF almacena en caché un modelo por tipo DbContext por proveedor. Se puede usar una
implementación diferente de este servicio para agregar otra información, como el nombre de esquema, a la clave
de caché.
System. Data. Entity. Spatial. DbSpatialServices

Objeto devuelto : un proveedor espacial de EF que agrega compatibilidad con el proveedor de EF básico para los
tipos espaciales Geography y Geometry.
Clave : DbSptialServices se solicita de dos maneras. En primer lugar, se solicitan servicios espaciales específicos
del proveedor mediante un objeto DbProviderInfo (que contiene el nombre invariable y el token del manifiesto)
como clave. En segundo lugar, se puede solicitar a DbSpatialServices sin clave. Se usa para resolver el "proveedor
espacial global", que se usa al crear tipos independientes de DbGeography o DbGeometry.
NOTE
proveedor EF6 .
FUNC < System. Data. Entity. Infrastructure. IDbExecutionStrategy>

Objeto devuelto : generador para crear un servicio que permite a un proveedor implementar reintentos u otro
comportamiento cuando las consultas y los comandos se ejecutan en la base de datos. Si no se proporciona
ninguna implementación, EF simplemente ejecutará los comandos y propagará las excepciones que se produzcan.
Por SQL Server este servicio se utiliza para proporcionar una directiva de reintentos que es especialmente útil
cuando se ejecuta en servidores de bases de datos basados en la nube, como SQL Azure.
Key : un objeto ExecutionStrategyKey que contiene el nombre invariable del proveedor y, opcionalmente, un
nombre de servidor para el que se usará la estrategia de ejecución.
NOTE
proveedor EF6 .
FUNC < DbConnection, String, System. Data. Entity. Migrations. History.
HistoryContext>
Objeto devuelto : un generador que permite a un proveedor configurar la asignación de HistoryContext a la tabla
__MigrationHistory utilizada por las migraciones de EF. HistoryContext es un DbContext de Code First y se puede
configurar mediante la API fluida normal para cambiar aspectos como el nombre de la tabla y las especificaciones
de asignación de columnas.
NOTE
proveedor EF6 .
System. Data. Common. DbProviderFactory

Objeto devuelto : el proveedor ADO.net que se va a usar para un nombre invariable de proveedor determinado.
Key : una cadena que contiene el nombre invariable del proveedor ADO.net
NOTE
Normalmente, este servicio no se cambia directamente, ya que la implementación predeterminada usa el registro del
proveedor ADO.NET normal. Para obtener más información sobre los servicios relacionados con el proveedor en EF6,
consulte la sección modelo de proveedor EF6 .
System. Data. Entity. Infrastructure. IProviderInvariantName

Objeto devuelto : un servicio que se utiliza para determinar un nombre invariable de proveedor para un tipo
determinado de DbProviderFactory. La implementación predeterminada de este servicio utiliza el registro del
proveedor ADO.NET. Esto significa que si el proveedor ADO.NET no está registrado de la manera normal porque EF
está resolviendo DbProviderFactory, también será necesario para resolver este servicio.
Key : la instancia de DbProviderFactory para la que se requiere un nombre invariable.
NOTE
proveedor EF6 .
System. Data. Entity. Core. Mapping. ViewGeneration.

IViewAssemblyCache
Objeto devuelto : memoria caché de los ensamblados que contienen las vistas generadas previamente. Un
reemplazo se usa normalmente para permitir que EF sepa qué ensamblados contienen vistas generadas
previamente sin realizar ninguna detección.
System. Data. Entity. Infrastructure. pluralización. IPluralizationService

Objeto devuelto : un servicio utilizado por EF para pluralar y singularar los nombres. De forma predeterminada,
se usa un servicio de pluralización en inglés.
System. Data. Entity. Infrastructure. intercepción. IDbInterceptor

Objetos devueltos : todos los interceptores que se deben registrar cuando se inicia la aplicación. Tenga en cuenta
que estos objetos se solicitan mediante la llamada a GetServices y todos los interceptores devueltos por cualquier
solucionador de dependencias se registrarán.
Clave : no se utiliza; será null.
FUNC < System. Data. Entity. DbContext, Action < cadena>, System.
Data. Entity. Infrastructure. intercepción. DatabaseLogFormatter>
Objeto devuelto : un generador que se usará para crear el formateador del registro de base de datos que se
utilizará cuando el contexto. La propiedad Database. log está establecida en el contexto especificado.
Clave : no se utiliza; será null.
FUNC < System. Data. Entity. DbContext>

Objeto devuelto : un generador que se usará para crear instancias de contexto para las migraciones cuando el
contexto no tenga un constructor sin parámetros accesible.
Key : el objeto de tipo para el tipo de DbContext derivado para el que se necesita un generador.
FUNC < System. Data. Entity. Core. Metadata. Edm.

IMetadataAnnotationSerializer>
Objeto devuelto : un generador que se utilizará para crear serializadores para la serialización de anotaciones
personalizadas fuertemente tipadas de modo que se puedan serializar y desesterilizar en XML para su uso en
migraciones de Code First.
Key : nombre de la anotación que se va a serializar o deserializar.
FUNC < System. Data. Entity. Infrastructure. TransactionHandler>

Objeto devuelto : un generador que se usará para crear controladores para las transacciones, de modo que se
pueda aplicar un control especial para situaciones como el control de errores de confirmación.
Key : un objeto ExecutionStrategyKey que contiene el nombre invariable del proveedor y, opcionalmente, un
nombre de servidor para el que se usará el controlador de transacciones.
Administración de conexiones
En esta página se describe el comportamiento de Entity Framework con respecto a cómo pasar conexiones al
contexto y la funcionalidad de la API Database. Connection. Open () .
Pasar conexiones al contexto

Comportamiento de EF5 y versiones anteriores
Hay dos constructores que aceptan conexiones:
public DbContext(DbConnection existingConnection, bool contextOwnsConnection)

public DbContext(DbConnection existingConnection, DbCompiledModel model, bool contextOwnsConnection)
Es posible utilizarlos, pero tiene que solucionar un par de limitaciones:

1. Si pasa una conexión abierta a cualquiera de estas, la primera vez que el marco intenta utilizarla, se produce
una excepción InvalidOperationException que indica que no puede volver a abrir una conexión que ya está
abierta.
2. La marca contextOwnsConnection se interpreta para indicar si la conexión del almacén subyacente debe
desecharse cuando se desecha el contexto. Sin embargo, independientemente de esa configuración, la conexión
del almacén siempre se cierra cuando se desecha el contexto. Por lo tanto, si tiene más de un DbContext con la
misma conexión, el contexto que se elimine primero cerrará la conexión (de forma similar si ha mezclado una
conexión ADO.NET existente con un DbContext, DbContext siempre cerrará la conexión cuando se elimine). .
Es posible solucionar la primera limitación anterior si se pasa una conexión cerrada y solo se ejecuta código que la
abriría una vez que se han creado todos los contextos:
using System.Data.Common;
using System.Data.EntityClient;
using System.Linq;
namespace ConnectionManagementExamples
{
class ConnectionManagementExampleEF5
{
public static void TwoDbContextsOneConnection()
{
{
var conn =
((EntityConnection)
((IObjectContextAdapter)context1).ObjectContext.Connection)
.StoreConnection;
using (var context2 = new BloggingContext(conn, contextOwnsConnection: false))

{
context2.Database.ExecuteSqlCommand(
@"UPDATE Blogs SET Rating = 5" +
" WHERE Name LIKE '%Entity Framework%'");
var query = context1.Posts.Where(p => p.Blog.Rating > 5);

foreach (var post in query)
{
post.Title += "[Cool Blog]";
}
}
}
}
}
}
La segunda limitación solo significa que debe abstenerse de desechar cualquier objeto DbContext hasta que esté
listo para que se cierre la conexión.
Comportamiento en EF6 y versiones futuras
En EF6 y versiones futuras, DbContext tiene los mismos dos constructores, pero ya no requiere que la conexión
pasada al constructor se cierre cuando se reciba. Por lo tanto, ahora es posible:
using System.Data.SqlClient;
using System.Linq;
using System.Transactions;
{
class ConnectionManagementExample
{
public static void PassingAnOpenConnection()
{
using (var conn = new SqlConnection("{connectionString}"))
{
conn.Open();
var sqlCommand = new SqlCommand();

sqlCommand.Connection = conn;
sqlCommand.CommandText =
" WHERE Name LIKE '%Entity Framework%'";
sqlCommand.ExecuteNonQuery();
using (var context = new BloggingContext(conn, contextOwnsConnection: false))

{
var query = context.Posts.Where(p => p.Blog.Rating > 5);
{
}
}
var sqlCommand2 = new SqlCommand();

sqlCommand2.Connection = conn;
sqlCommand2.CommandText =
" WHERE Name LIKE '%Entity Framework Rocks%'";
sqlCommand2.ExecuteNonQuery();
}
}
}
}
Además, la marca contextOwnsConnection controla ahora si la conexión se cierra y se desecha cuando se desecha
el DbContext. Por lo tanto, en el ejemplo anterior, la conexión no se cierra cuando el contexto se desecha (línea 32)
tal y como se encontraba en versiones anteriores de EF, sino cuando se desecha la propia conexión (línea 40).
Por supuesto, sigue siendo posible que DbContext tome el control de la conexión (solo tiene que establecer
contextOwnsConnection en true o usar uno de los otros constructores) si así lo desea.
NOTE
Existen algunas consideraciones adicionales al usar transacciones con este nuevo modelo. Para obtener más información,
consulte trabajar con transacciones.
Database. Connection. Open ()

Comportamiento de EF5 y versiones anteriores
En EF5 y versiones anteriores hay un error que indica que ObjectContext. Connection. State no se actualizó
para reflejar el verdadero estado de la conexión del almacén subyacente. Por ejemplo, si ejecutó el código
siguiente, se puede devolver el estado cerrado aunque de hecho la conexión del almacén subyacente esté
abier ta .
((IObjectContextAdapter)context).ObjectContext.Connection.State
Por separado, si abre la conexión de base de datos mediante una llamada a Database. Connection. Open (), se
abrirá hasta la próxima vez que ejecute una consulta o llame a cualquier elemento que requiera una conexión de
base de datos (por ejemplo, SaveChanges ()) pero después de que el almacén subyacente la conexión se cerrará. El
contexto volverá a abrir y a cerrar la conexión cada vez que se requiera otra operación de base de datos:
using System;
using System.Data;
{
public class DatabaseOpenConnectionBehaviorEF5
{
public static void DatabaseOpenConnectionBehavior()
{
{
// At this point the underlying store connection is closed
context.Database.Connection.Open();
// Now the underlying store connection is open

// (though ObjectContext.Connection.State will report closed)
var blog = new Blog { /* Blog’s properties */ };

// The underlying store connection is still open
// After SaveChanges() the underlying store connection is closed

// Each SaveChanges() / query etc now opens and immediately closes
// the underlying store connection
blog = new Blog { /* Blog’s properties */ };

}
}
}
}
Comportamiento en EF6 y versiones futuras

En el caso de EF6 y versiones futuras, hemos tomado el enfoque que es si el código de llamada elige abrir la
conexión llamando al contexto. Database. Connection. Open () tiene una buena razón para hacerlo y el marco
asumirá que desea tener el control sobre la apertura y el cierre de la conexión y dejará de cerrar la conexión
automáticamente.
NOTE
Esto puede dar lugar a conexiones que están abiertas durante mucho tiempo, por lo que debe usarse con cuidado.
También se actualizó el código para que ObjectContext. Connection. State ahora realiza un seguimiento del estado
de la conexión subyacente correctamente.
using System;
using System.Data;
using System.Data.Entity.Core.EntityClient;
{
internal class DatabaseOpenConnectionBehaviorEF6
{
public static void DatabaseOpenConnectionBehavior()
{
{
// At this point the underlying store connection is closed
context.Database.Connection.Open();
// Now the underlying store connection is open and the

// ObjectContext.Connection.State correctly reports open too
var blog = new Blog { /* Blog’s properties */ };

// The underlying store connection remains open for the next operation
blog = new Blog { /* Blog’s properties */ };

// The underlying store connection is still open
} // The context is disposed – so now the underlying store connection is closed

}
}
}
Resistencia de conexión y lógica de reintento
NOTE
Las aplicaciones que se conectan a un servidor de base de datos siempre han sido vulnerables a las interrupciones
de conexión debido a errores de back-end y a la inestabilidad de red. Sin embargo, en un entorno basado en LAN
que trabaja con servidores de bases de datos dedicados, estos errores son lo suficientemente raros como para que
no se requiera la lógica adicional para controlar esos errores. Con el aumento de los servidores de bases de datos
basados en la nube, como Windows Azure SQL Database y las conexiones a través de redes menos confiables,
ahora es más común que se produzcan interrupciones de conexión. Esto puede deberse a técnicas defensivas que
usan las bases de datos en la nube para garantizar la equidad del servicio, como la limitación de la conexión o la
inestabilidad en la red, lo que produce tiempos de espera intermitentes y otros errores transitorios.
La resistencia de la conexión hace referencia a la capacidad de EF de reintentar automáticamente cualquier
comando que produzca un error debido a estas interrupciones de conexión.
Estrategias de ejecución
El reintento de conexión se realiza a través de una implementación de la interfaz IDbExecutionStrategy. Las
implementaciones de IDbExecutionStrategy serán responsables de aceptar una operación y, si se produce una
excepción, determinar si es adecuado y volver a intentar si es así. Hay cuatro estrategias de ejecución que se
incluyen con EF:
1. DefaultExecutionStrategy : esta estrategia de ejecución no vuelve a intentar ninguna operación, es el valor
predeterminado para las bases de datos que no sean SQL Server.
2. DefaultSqlExecutionStrategy : esta es una estrategia de ejecución interna que se utiliza de forma
predeterminada. Sin embargo, esta estrategia no vuelve a intentarlo, sino que encapsulará las excepciones que
podrían ser transitorias para informar a los usuarios de que pueden querer habilitar la resistencia de la
conexión.
3. DbExecutionStrategy : esta clase es adecuada como una clase base para otras estrategias de ejecución,
incluidas sus propias personalizaciones. Implementa una directiva de reintentos exponencial, donde el reintento
inicial se produce con un retraso de cero y el retraso aumenta exponencialmente hasta que se alcanza el
número máximo de reintentos. Esta clase tiene un método ShouldRetryOn abstracto que se puede implementar
en estrategias de ejecución derivadas para controlar las excepciones que se deben Reintentar.
4. SqlAzureExecutionStrategy : esta estrategia de ejecución hereda de DbExecutionStrategy y volverá a
intentarlo en las excepciones que se sabe que son posiblemente transitorias al trabajar con Azure SQL
Database.
NOTE
Las estrategias de ejecución 2 y 4 se incluyen en el proveedor de SQL Server que se incluye con EF, que está en el
ensamblado EntityFramework. SqlServer y están diseñados para funcionar con SQL Server.
Habilitar una estrategia de ejecución

La manera más sencilla de indicar a EF que use una estrategia de ejecución es con el método SetExecutionStrategy
de la clase DbConfiguration :

{
{
SetExecutionStrategy("System.Data.SqlClient", () => new SqlAzureExecutionStrategy());
}
}
Este código indica a EF que use SqlAzureExecutionStrategy al conectarse a SQL Server.
Configuración de la estrategia de ejecución

El constructor de SqlAzureExecutionStrategy puede aceptar dos parámetros, MaxRetryCount y MaxDelay. MaxRetry
Count es el número máximo de veces que se reintentará la estrategia. MaxDelay es un intervalo de tiempo que
representa el retraso máximo entre los reintentos que usará la estrategia de ejecución.
Para establecer el número máximo de reintentos en 1 y el retraso máximo en 30 segundos, ejecutaría lo siguiente:

{
{
SetExecutionStrategy(
"System.Data.SqlClient",
() => new SqlAzureExecutionStrategy(1, TimeSpan.FromSeconds(30)));
}
}
El SqlAzureExecutionStrategy se volverá a intentar de inmediato la primera vez que se produzca un error

transitorio, pero se retrasará más tiempo entre cada reintento hasta que se supere el límite máximo de reintentos
o hasta que el tiempo total alcanza el retraso máximo.
Las estrategias de ejecución solo volverán a intentar un número limitado de excepciones que normalmente son
transitorias; todavía tendrá que controlar otros errores, así como detectar la excepción RetryLimitExceeded para el
caso en el que un error no sea transitorio o tarde demasiado en resolverse. propio.
Hay algunas limitaciones conocidas al usar una estrategia de ejecución de reintento:
No se admiten las consultas de streaming

De forma predeterminada, EF6 y versiones posteriores almacenarán en búfer los resultados de la consulta en lugar
de transmitirlos por secuencias. Si desea que los resultados se transmitan, puede usar el método asstreaming para
cambiar una consulta de LINQ to Entities a streaming.

{
var query = (from b in db.Blogs
orderby b.Url
select b).AsStreaming();
}
}
No se admite la transmisión por secuencias cuando se registra una estrategia de ejecución de reintento. Esta
limitación existe porque la conexión podría quitar parte de los resultados que se devuelven. Cuando esto ocurre,
EF debe volver a ejecutar toda la consulta, pero no tiene una forma confiable de saber qué resultados se han
devuelto (los datos pueden haber cambiado desde que se envió la consulta inicial, por lo que los resultados
pueden volver a un orden diferente, por lo que los resultados no tienen un identificador único). , etc.).
No se admiten las transacciones iniciadas por el usuario

Cuando haya configurado una estrategia de ejecución que tenga como resultado reintentos, hay algunas
limitaciones sobre el uso de transacciones.
De forma predeterminada, EF realizará cualquier actualización de la base de datos dentro de una transacción. No
es necesario hacer nada para habilitarlo; EF siempre lo hace automáticamente.
Por ejemplo, en el código siguiente, se realiza automáticamente SaveChanges en una transacción. Si se produjera
un error de SaveChanges después de insertar uno de los nuevos sitios, la transacción se revertiría y no se aplicaría
ningún cambio en la base de datos. El contexto también se deja en un estado que permite llamar a SaveChanges
de nuevo para volver a aplicar los cambios.

{
db.Blogs.Add(new Site { Url = "http://msdn.com/data/ef" });
db.Blogs.Add(new Site { Url = "http://blogs.msdn.com/adonet" });
db.SaveChanges();
}
Cuando no se usa una estrategia de ejecución de reintento, se pueden ajustar varias operaciones en una sola
transacción. Por ejemplo, el código siguiente ajusta dos llamadas de SaveChanges en una sola transacción. Si se
produce un error en cualquier parte de cualquiera de las operaciones, no se aplica ninguno de los cambios.

{
using (var trn = db.Database.BeginTransaction())
{
db.Blogs.Add(new Site { Url = "http://msdn.com/data/ef" });
db.Blogs.Add(new Site { Url = "http://blogs.msdn.com/adonet" });
db.SaveChanges();
db.Blogs.Add(new Site { Url = "http://twitter.com/efmagicunicorns" });

db.SaveChanges();
trn.Commit();
}
}
Esto no se admite cuando se usa una estrategia de ejecución de reintento porque EF no es consciente de las
operaciones anteriores y cómo volver a intentarlo. Por ejemplo, si se produce un error en el segundo
SaveChanges, EF ya no tiene la información necesaria para volver a intentar la primera llamada a SaveChanges.
Solución: estrategia de ejecución de llamadas manualmente
La solución consiste en usar manualmente la estrategia de ejecución y darle todo el conjunto de lógica que se va a
ejecutar, de modo que pueda volver a intentar todo lo posible si se produce un error en una de las operaciones.
Cuando una estrategia de ejecución derivada de DbExecutionStrategy se está ejecutando, suspenderá la estrategia
de ejecución implícita usada en SaveChanges.
Tenga en cuenta que los contextos deben construirse dentro del bloque de código para que se vuelva a intentar.
Esto garantiza que se está iniciando con un estado limpio para cada reintento.
var executionStrategy = new SqlAzureExecutionStrategy();
executionStrategy.Execute(
() =>
{
{
using (var trn = db.Database.BeginTransaction())
{
db.Blogs.Add(new Blog { Url = "http://msdn.com/data/ef" });
db.Blogs.Add(new Blog { Url = "http://blogs.msdn.com/adonet" });
db.SaveChanges();
db.Blogs.Add(new Blog { Url = "http://twitter.com/efmagicunicorns" });

db.SaveChanges();
trn.Commit();
}
}
});
Control de errores de confirmación de transacción
NOTE
EF 6.1 en adelante solo : las características, las API, etc. que se describen en esta página se introdujeron en Entity
Framework 6,1. Si usa una versión anterior, no se aplica parte o la totalidad de la información.
Como parte de 6,1 estamos introduciendo una nueva característica de resistencia de conexión para EF: la
capacidad de detectar y recuperar automáticamente cuando los errores de conexión transitorios afecten a la
confirmación de confirmaciones de transacción. Los detalles completos del escenario se describen mejor en la
entrada de blog SQL Database la conectividad y el problema de Idempotencia. En Resumen, el escenario es que,
cuando se produce una excepción durante la confirmación de una transacción, hay dos causas posibles:
1. Error en la confirmación de la transacción en el servidor
2. La transacción se confirmó correctamente en el servidor pero un problema de conectividad impidió que la
notificación de éxito llegara al cliente
Cuando se produce la primera situación de la aplicación o el usuario puede reintentar la operación, pero cuando se
produce la segunda situación, se deben evitar los reintentos y la aplicación podría recuperarse automáticamente. El
reto es que sin la capacidad de detectar cuál fue el motivo real en el que se comunicó una excepción durante la
confirmación, la aplicación no puede elegir el curso de acción correcto. La nueva característica de EF 6,1 permite a
EF volver a comprobar con la base de datos si la transacción se ha realizado correctamente y realizar el curso
adecuado de acción de forma transparente.
Uso de la característica
Para habilitar la característica que necesita, incluya una llamada a SetTransactionHandler en el constructor de su
DbConfiguration . Si no está familiarizado con DbConfiguration , consulte configuración basada en código. Esta
característica se puede usar en combinación con los reintentos automáticos que se introdujeron en EF6, que
ayudan en la situación en la que la transacción realmente no pudo confirmarse en el servidor debido a un error
transitorio:
using System.Data.Entity.SqlServer;

{
{
SetTransactionHandler(SqlProviderServices.ProviderInvariantName, () => new CommitFailureHandler());
SetExecutionStrategy(SqlProviderServices.ProviderInvariantName, () => new SqlAzureExecutionStrategy());
}
}
Cómo se realiza el seguimiento de las transacciones

Cuando la característica está habilitada, EF agregará automáticamente una nueva tabla a la base de datos
denominada __Transactions . En esta tabla se inserta una nueva fila cada vez que EF crea una transacción y se
comprueba la existencia de esa fila si se produce un error de transacción durante la confirmación.
Aunque EF realizará el mejor esfuerzo para eliminar filas de la tabla cuando ya no se necesiten, la tabla puede
crecer si la aplicación se cierra prematuramente y, por ese motivo, es posible que necesite purgar la tabla
manualmente en algunos casos.
Cómo controlar los errores de confirmación con versiones anteriores

Antes de EF 6,1 no había ningún mecanismo para controlar los errores de confirmación en el producto EF. Hay
varias maneras de solucionar esta situación que se pueden aplicar a versiones anteriores de EF6:
Opción 1: no hacer nada
La probabilidad de que se produzca un error de conexión durante la confirmación de la transacción es baja,
por lo que puede ser aceptable que la aplicación no funcione correctamente si esta condición se produce
realmente.
Opción 2: usar la base de datos para restablecer el estado
1. Descartar el DbContext actual
2. Crear un nuevo DbContext y restaurar el estado de la aplicación desde la base de datos
3. Informe al usuario de que es posible que la última operación no se haya completado correctamente
Opción 3: realizar un seguimiento manual de la transacción
1. Agregue una tabla sin seguimiento a la base de datos utilizada para realizar el seguimiento del estado de
las transacciones.
2. Inserte una fila en la tabla al principio de cada transacción.
3. Si se produce un error en la conexión durante la confirmación, Compruebe la presencia de la fila
correspondiente en la base de datos.
Si la fila está presente, continúe normalmente, ya que la transacción se confirmó correctamente.
Si la fila no existe, use una estrategia de ejecución para volver a intentar la operación actual.
4. Si la confirmación se realiza correctamente, elimine la fila correspondiente para evitar el crecimiento de
la tabla.
Esta entrada de blog contiene código de ejemplo para realizar esta instalación en SQL Azure.
DataBinding con WinForms
En este tutorial paso a paso se muestra cómo enlazar tipos POCO a controles de formularios Windows Forms
(WinForms) en un formulario "principal-detalle". La aplicación utiliza Entity Framework para rellenar los objetos
con datos de la base de datos, realizar un seguimiento de los cambios y conservar los datos en la base de datos.
El modelo define dos tipos que participan en una relación de uno a varios: Category (principal\Master) y Product
(Dependent\Detail). A continuación, se usan las herramientas de Visual Studio para enlazar los tipos definidos en el
modelo con los controles de WinForms. El marco de enlace de datos de WinForms permite la navegación entre
objetos relacionados: la selección de filas en la vista maestra hace que la vista de detalles se actualice con los datos
secundarios correspondientes.
Las capturas de pantalla y las listas de código de este tutorial se han tomado de Visual Studio 2013 pero puede
completar este tutorial con Visual Studio 2012 o Visual Studio 2010.
Requisitos previos
Debe tener Visual Studio 2013, Visual Studio 2012 o Visual Studio 2010 instalado para completar este tutorial.
Si usa Visual Studio 2010, también tiene que instalar NuGet. Para obtener más información, consulte instalación de
NuGet.
Crear la aplicación
Abra Visual Studio.
Archivo-> nuevo proyecto de>....
Seleccione Windows en el panel izquierdo y Windows FormsApplication en el panel derecho.
Escriba WinFormswithEFSample como nombre
Seleccione Aceptar .
Instalar el paquete NuGet de Entity Framework

En Explorador de soluciones, haga clic con el botón derecho en el proyecto WinFormswithEFSample
Seleccione administrar paquetes NuGet. .
En el cuadro de diálogo administrar paquetes NuGet, seleccione la pestaña en línea y elija el paquete
EntityFramework
NOTE
Además del ensamblado EntityFramework, también se agrega una referencia a System. ComponentModel.
DataAnnotations. Si el proyecto tiene una referencia a System. Data. Entity, se quitará cuando se instale el paquete
EntityFramework. El ensamblado System. Data. Entity ya no se utiliza para las aplicaciones de Entity Framework 6.
Implementación de IListSource para colecciones

Las propiedades de colección deben implementar la interfaz IListSource para habilitar el enlace de datos
bidireccional con la ordenación al utilizar Windows Forms. Para ello, vamos a ampliar ObservableCollection para
agregar la funcionalidad IListSource.
Agregue una clase Obser vableListSource al proyecto:
Haga clic con el botón derecho en el nombre del proyecto
Seleccionar agregar> nuevo elemento
Seleccione clase y escriba Obser vableListSource para el nombre de clase.
Reemplace el código generado de forma predeterminada con el código siguiente:
Esta clase permite el enlace de datos bidireccional y la ordenación. La clase se deriva de ObservableCollection<T>
y agrega una implementación explícita de IListSource. El método GetList () de IListSource se implementa para
devolver una implementación de IBindingList que permanece sincronizada con ObservableCollection. La
implementación de IBindingList generada por ToBindingList admite la ordenación. El método de extensión
ToBindingList se define en el ensamblado EntityFramework.
using System.Collections;
using System.Collections.ObjectModel;
using System.ComponentModel;
using System.Diagnostics.CodeAnalysis;
namespace WinFormswithEFSample
{
public class ObservableListSource<T> : ObservableCollection<T>, IListSource
where T : class
{
private IBindingList _bindingList;
bool IListSource.ContainsListCollection { get { return false; } }
IList IListSource.GetList()
{
return _bindingList ?? (_bindingList = this.ToBindingList());
}
}
}
Definir un modelo
En este tutorial, puede elegir implementar un modelo mediante Code First o el diseñador de EF. Complete una de
las dos secciones siguientes.
Opción 1: definir un modelo con Code First
En esta sección se muestra cómo crear un modelo y su base de datos asociada mediante Code First. Vaya a la
sección siguiente (opción 2: definir un modelo con Database First) si prefiere usar Database First para
aplicar ingeniería inversa al modelo desde una base de datos mediante el diseñador de EF.
Al usar Code First desarrollo, normalmente comienza por escribir .NET Framework clases que definen el modelo
conceptual (de dominio).
Agregar una nueva clase de producto a Project
using System;
using System.Linq;
using System.Text;
{
public class Product
{
public int ProductId { get; set; }
public int CategoryId { get; set; }

public virtual Category Category { get; set; }
}
}
Agregue una clase de categoría al proyecto.

using System;
using System.Linq;
using System.Text;
{
public class Category
{
private readonly ObservableListSource<Product> _products =
new ObservableListSource<Product>();

public virtual ObservableListSource<Product> Products { get { return _products; } }
}
}
Además de definir entidades, debe definir una clase que derive de DbContext y exponga las propiedades de
DbSet<de la carpa> . Las propiedades DbSet permiten que el contexto sepa qué tipos desea incluir en el
modelo. Los tipos DbContext y DbSet se definen en el ensamblado EntityFramework.
Una instancia del tipo derivado de DbContext administra los objetos de entidad durante el tiempo de ejecución, lo
que incluye el rellenado de objetos con datos de una base de datos, el seguimiento de cambios y la persistencia de
datos en la base de datos.
Agregue una nueva clase ProductContext al proyecto.
using System;
using System.Linq;
using System.Text;
{
{
}
}
Compile el proyecto.
Opción 2: definir un modelo con Database First
En esta sección se muestra cómo usar Database First para aplicar ingeniería inversa al modelo desde una base de
datos mediante el diseñador de EF. Si ha completado la sección anterior (opción 1: definir un modelo con
Code First) , omita esta sección y vaya directamente a la sección de carga diferida .
Crear una base de datos existente
Normalmente, cuando el destino es una base de datos existente, ya se creará, pero para este tutorial es necesario
crear una base de datos para tener acceso a.
El servidor de base de datos que se instala con Visual Studio es diferente en función de la versión de Visual Studio
que haya instalado:
Si usa Visual Studio 2010, va a crear una base de datos de SQL Express.
Si usa Visual Studio 2012, va a crear una base de datos de LocalDB .
Vamos a generar la base de datos.
Explorador de ser vidores de> de vista
Haga clic con el botón derecho en conexiones de datos:> agregar conexión...
Si no se ha conectado a una base de datos desde Explorador de servidores antes de que tenga que
seleccionar Microsoft SQL Server como origen de datos
Conéctese a LocalDB o a SQL Express, en función de la que haya instalado y escriba Products como
nombre de la base de datos.
Seleccione Aceptar y se le preguntará si desea crear una nueva base de datos, seleccione sí .
La nueva base de datos aparecerá ahora en Explorador de servidores, haga clic con el botón derecho en ella
y seleccione nueva consulta .
Copie el siguiente código SQL en la nueva consulta, haga clic con el botón derecho en la consulta y
seleccione Ejecutar .
CREATE TABLE [dbo].[Categories] (
[CategoryId] [int] NOT NULL IDENTITY,
[Name] [nvarchar](max),
CONSTRAINT [PK_dbo.Categories] PRIMARY KEY ([CategoryId])
)
CREATE TABLE [dbo].[Products] (

[ProductId] [int] NOT NULL IDENTITY,
[CategoryId] [int] NOT NULL,
CONSTRAINT [PK_dbo.Products] PRIMARY KEY ([ProductId])
)
CREATE INDEX [IX_CategoryId] ON [dbo].[Products]([CategoryId])
ALTER TABLE [dbo].[Products] ADD CONSTRAINT [FK_dbo.Products_dbo.Categories_CategoryId] FOREIGN KEY

([CategoryId]) REFERENCES [dbo].[Categories] ([CategoryId]) ON DELETE CASCADE
Modelo de ingeniería inversa

Vamos a hacer uso de Entity Framework Designer, que se incluye como parte de Visual Studio, para crear nuestro
modelo.
Proyecto-> agregar nuevo elemento...
Seleccione datos en el menú de la izquierda y, a continuación, ADO.NET Entity Data Model
Escriba ProductModel como nombre y haga clic en Aceptar .
Se iniciará el Asistente para Entity Data Model
Seleccione generar desde la base de datos y haga clic en siguiente .
Seleccione la conexión a la base de datos creada en la primera sección, escriba ProductContext como
nombre de la cadena de conexión y haga clic en siguiente .
Haga clic en la casilla situada junto a "tablas" para importar todas las tablas y haga clic en "finalizar".
Una vez que se completa el proceso de ingeniería inversa, el nuevo modelo se agrega al proyecto y se abre para
que pueda verlo en el Entity Framework Designer. También se ha agregado un archivo app. config al proyecto con
los detalles de conexión de la base de datos.
Pasos adicionales en Visual Studio 2010
Si está trabajando en Visual Studio 2010, tendrá que actualizar el diseñador de EF para usar la generación de
código EF6.
Haga clic con el botón derecho en una zona vacía del modelo en el diseñador de EF y seleccione Agregar
elemento de generación de código. .
Seleccione plantillas en línea en el menú de la izquierda y busque DbContext
Seleccione el generador de DbContext de EF 6. x para C#, escriba ProductsModel como nombre y haga
clic en Agregar.
Actualizar la generación de código para el enlace de datos
EF genera código a partir del modelo mediante plantillas T4. Las plantillas que se incluyen con Visual Studio o que
se descargan de la galería de Visual Studio están pensadas para uso general. Esto significa que las entidades
generadas a partir de estas plantillas tienen propiedades simples de ICollection<T>. Sin embargo, cuando se
realiza el enlace de datos, es aconsejable tener propiedades de colección que implementen IListSource. Este es el
motivo por el que hemos creado la clase ObservableListSource anterior y ahora vamos a modificar las plantillas
para hacer uso de esta clase.
Abra el Explorador de soluciones y busque el archivo ProductModel. edmx.
Busque el archivo ProductModel.TT que se anidará en el archivo ProductModel. edmx.
Haga doble clic en el archivo ProductModel.tt para abrirlo en el editor de Visual Studio
Busque y reemplace las dos apariciones de "ICollection " por "Obser vableListSource ". Se encuentran en
aproximadamente las líneas 296 y 484.
Busque y reemplace la primera aparición de "HashSet " por "Obser vableListSource ". Esta repetición se
encuentra en aproximadamente la línea 50. No Reemplace la segunda aparición de HashSet que se
encuentra más adelante en el código.
Guarde el archivo ProductModel.tt. Esto debería hacer que se vuelva a generar el código para las entidades.
Si el código no se vuelve a generar automáticamente, haga clic con el botón derecho en ProductModel.tt y
elija "ejecutar herramienta personalizada".
Si ahora abre el archivo Category.cs (que está anidado en ProductModel.tt), debería ver que la colección Products
tiene el tipo Obser vableListSource<>de producto .
Carga diferida
La propiedad Products de la clase categoría y la propiedad categoría de la clase Product son propiedades de
navegación. En Entity Framework, las propiedades de navegación proporcionan una manera de navegar por una
relación entre dos tipos de entidad.
EF ofrece una opción para cargar automáticamente entidades relacionadas desde la base de datos la primera vez
que se tiene acceso a la propiedad de navegación. Con este tipo de carga (denominado carga diferida), tenga en
cuenta que la primera vez que se tiene acceso a cada propiedad de navegación se ejecutará una consulta
independiente en la base de datos si el contenido no está ya en el contexto.
Cuando se usan tipos de entidad POCO, EF consigue la carga diferida mediante la creación de instancias de tipos
de proxy derivados durante el tiempo de ejecución y, a continuación, la invalidación de las propiedades virtuales
en las clases para agregar el enlace de carga. Para obtener la carga diferida de los objetos relacionados, debe
declarar captadores de propiedades de navegación como Public y vir tual (reemplazable en Visual Basic) y la
clase no debe estar sellada (NotOverridable en Visual Basic). Cuando se usa Database First propiedades de
navegación se convierten automáticamente en virtual para habilitar la carga diferida. En la sección Code First
hemos optado por que las propiedades de navegación sean virtuales por la misma razón
Enlazar un objeto a controles

Agregue las clases que se definen en el modelo como orígenes de datos para esta aplicación de WinForms.
En el menú principal, seleccione proyecto-> agregar nuevo origen de datos. . (en Visual Studio 2010,
debe seleccionar datos-> agregar nuevo origen de datos... )
En la ventana elegir un tipo de origen de datos, seleccione objeto y haga clic en siguiente .
En el cuadro de diálogo Seleccionar los objetos de datos, WinFormswithEFSample dos veces y seleccione
categoría no es necesario seleccionar el origen de datos del producto, porque lo haremos a través de la
propiedad del producto en el origen de datos de la categoría.
Haga clic en Finish (Finalizar). Si la ventana orígenes de datos no aparece, seleccione Ver-> otros
orígenes de datos de> Windows .
Presione el icono de anclaje para que la ventana orígenes de datos no se oculte automáticamente. Es
posible que tenga que presionar el botón actualizar si la ventana ya estaba visible.
En Explorador de soluciones, haga doble clic en el archivo Form1.CS para abrir el formulario principal en el
diseñador.
Seleccione el origen de datos de la categoría y arrástrelo en el formulario. De forma predeterminada, se
agregan al diseñador un nuevo control DataGridView (categor yDataGridView ) y controles de la barra de
herramientas de navegación. Estos controles están enlazados a los componentes BindingSource
(categor yBindingSource ) y navegador de enlace (categor yBindingNavigator ) que también se crean.
Edite las columnas en el categor yDataGridView . Queremos establecer la columna Categor yID en solo
lectura. La base de datos genera el valor de la propiedad Categor yID después de guardar los datos.
Haga clic con el botón secundario en el control DataGridView y seleccione Editar columnas...
Seleccione la columna CategoryId y establezca ReadOnly en true.
Presione Aceptar
Seleccione productos en el origen de datos de la categoría y arrástrelos en el formulario.
ProductDataGridView y productBindingSource se agregan al formulario.
Edite las columnas en el productDataGridView. Queremos ocultar las columnas CategoryId y categoría y
establecer ProductId en solo lectura. La base de datos genera el valor de la propiedad ProductId después de
guardar los datos.
Haga clic con el botón secundario en el control DataGridView y seleccione Editar columnas. ...
Seleccione la columna ProductID y establezca ReadOnly en true .
Seleccione la columna Categor yID y presione el botón quitar . Haga lo mismo con la columna
categoría .
Presione Aceptar .
Hasta ahora, asociamos nuestros controles DataGridView a componentes BindingSource en el diseñador. En
la siguiente sección, agregaremos código al código subyacente para establecer categoryBindingSource.
DataSource en la colección de entidades cuyo seguimiento realiza actualmente DbContext. Cuando hemos
arrastrado y colocado productos desde la categoría, el WinForms se encarga de configurar la propiedad
productsBindingSource. DataSource en categoryBindingSource y la propiedad productsBindingSource.
DataMember en Products. Debido a este enlace, solo se mostrarán en el productDataGridView los
productos que pertenecen a la categoría seleccionada actualmente.
Habilite el botón Guardar en la barra de herramientas de navegación; para ello, haga clic con el botón
secundario del mouse y seleccione habilitado .
Agregue el controlador de eventos para el botón Guardar haciendo doble clic en el botón. Esto agregará el
controlador de eventos y le llevará al código subyacente para el formulario. El código del controlador de
eventos categor yBindingNavigatorSaveItem_click se agregará en la sección siguiente.
Agregar el código que controla la interacción de datos

Ahora agregaremos el código para usar el ProductContext para realizar el acceso a los datos. Actualice el código
para la ventana de formulario principal, como se muestra a continuación.
El código declara una instancia de ejecución prolongada de ProductContext. El objeto ProductContext se usa para
consultar y guardar datos en la base de datos. A continuación, se llama al método Dispose () en la instancia de
ProductContext desde el método de cierre de sesión reemplazado. Los comentarios de código proporcionan
detalles sobre lo que hace el código.
using System;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;
{
public partial class Form1 : Form
{
ProductContext _context;
public Form1()
{
InitializeComponent();
}
protected override void OnLoad(EventArgs e)

{
base.OnLoad(e);
_context = new ProductContext();
// Call the Load method to get the data for the given DbSet
// from the database.
// The data is materialized as entities. The entities are managed by
// the DbContext instance.
_context.Categories.Load();
// Bind the categoryBindingSource.DataSource to

// all the Unchanged, Modified and Added Category objects that
// are currently tracked by the DbContext.
// Note that we need to call ToBindingList() on the
// ObservableCollection<TEntity> returned by
// the DbSet.Local property to get the BindingList<T>
// in order to facilitate two-way binding in WinForms.
this.categoryBindingSource.DataSource =
_context.Categories.Local.ToBindingList();
_context.Categories.Local.ToBindingList();
}
private void categoryBindingNavigatorSaveItem_Click(object sender, EventArgs e)

{
this.Validate();
// Currently, the Entity Framework doesn’t mark the entities

// that are removed from a navigation property (in our example the Products)
// as deleted in the context.
// The following code uses LINQ to Objects against the Local collection
// to find all products and marks any that do not have
// a Category reference as deleted.
// The ToList call is required because otherwise
// the collection will be modified
// by the Remove call while it is being enumerated.
// In most other situations you can do LINQ to Objects directly
// against the Local property without using ToList first.
foreach (var product in _context.Products.Local.ToList())
{
if (product.Category == null)
{
_context.Products.Remove(product);
}
}
// Save the changes to the database.

this._context.SaveChanges();
// Refresh the controls to show the values

// that were generated by the database.
this.categoryDataGridView.Refresh();
this.productsDataGridView.Refresh();
}
protected override void OnClosing(CancelEventArgs e)

{
base.OnClosing(e);
this._context.Dispose();
}
}
}
Prueba de la aplicación Windows Forms

Compile y ejecute la aplicación y puede probar la funcionalidad.
Después de guardar las claves generadas por el almacén, se muestran en la pantalla.

Si ha usado Code First, también verá que se ha creado una base de datos WinFormswithEFSample.
ProductContext .
IMPORTANT
Este documento es válido para WPF en .NET Framework
En este documento se describe el enlace de datos para WPF en .NET Framework. Para los nuevos proyectos de .NET Core, se
recomienda usar EF Core en lugar de Entity Framework 6. Se realiza un seguimiento de la documentación para el enlace de
datos en EF Core en el #778.
Databinding with WPF (Enlace de datos con WPF)

En este tutorial paso a paso se muestra cómo enlazar tipos POCO a controles WPFWPF en un formulario
"maestro-detalle". La aplicación usa las API de Entity Framework para rellenar objetos con datos de la base de
datos, realizar un seguimiento de los cambios y conservar los datos en la base de datos.
El modelo define dos tipos que participan en la\relación uno a\varios: Categoría (principal maestro) y Producto
(detalle dependiente). A continuación, las herramientas de Visual Studio se usan para enlazar los tipos definidos en
el modelo a los controles WPFWPF. El marco de enlace de datos WPFWPF permite la navegación entre objetos
relacionados: la selección de filas en la vista maestra hace que la vista de detalle se actualice con los datos
secundarios correspondientes.
Las capturas de pantalla y las listas de código de este tutorial se toman de Visual Studio 2013, pero puede
completar este tutorial con Visual Studio 2012 o Visual Studio 2010.
Use la opción 'Objeto' para crear orígenes de datos WPF

Con la versión anterior de Entity Framework se usa el uso de la base de datos opción al crear un nuevo origen de
datos basado en un modelo creado con el Diseñador de EF. Esto se debió a que el diseñador generaría un contexto
derivado de ObjectContext y clases de entidad derivadas de EntityObject. El uso de la opción Base de datos le
ayudaría a escribir el mejor código para interactuar con esta superficie de API.
Los diseñadores de EF para Visual Studio 2012 y Visual Studio 2013 generan un contexto que deriva de DbContext
junto con clases de entidad POCO simples. Con Visual Studio 2010 se recomienda intercambiar a una plantilla de
generación de código que usa DbContext como se describe más adelante en este tutorial.
Al usar la superficie de la API de DbContext, debe usar la opción Object al crear un nuevo origen de datos, como
se muestra en este tutorial.
Si es necesario, puede volver a la generación de código basada en ObjectContext para los modelos creados con EF
Designer.
Requisitos previos
Debe tener Visual Studio 2013, Visual Studio 2012 o Visual Studio 2010 instalado para completar este tutorial.
Si usa Visual Studio 2010, también tiene que instalar NuGet. Para obtener más información, vea Instalar NuGet.
Abra Visual Studio.
Archivo> -> Nuevo - Proyecto....
Seleccione Windows en el panel izquierdo y WPFApplication en el panel derecho
Escriba WPFwithEFSample como nombre
Seleccione Aceptar
Instale el paquete NuGet de Entity Framework

En el Explorador de soluciones, haga clic con el botón derecho en el proyecto WinFormswithEFSample
Seleccione Administrar paquetes NuGet...
En el cuadro de diálogo Administrar paquetes NuGet, seleccione la pestaña Online y elija el paquete
EntityFramework
Haga clic en Instalar
NOTE
Además del ensamblado EntityFramework, también se agrega una referencia a
System.ComponentModel.DataAnnotations. Si el proyecto tiene una referencia a System.Data.Entity, se quitará
cuando se instale el paquete EntityFramework. El ensamblado System.Data.Entity ya no se utiliza para aplicaciones de
Entity Framework 6.
Definir un modelo
En este tutorial puede optar por implementar un modelo mediante Code First o EF Designer. Complete una de las
dos secciones siguientes.
Opción 1: Definir un modelo utilizando Code First
En esta sección se muestra cómo crear un modelo y su base de datos asociada mediante Code First. Vaya a la
siguiente sección (Opción 2: definir un modelo con Database First) si prefiere usar Database First para
realizar ingeniería inversa del modelo desde una base de datos mediante el diseñador de EF
Cuando se usa el desarrollo de Code First, normalmente se empieza escribiendo clases de .NET Framework que
definen el modelo conceptual (dominio).
Agregue una nueva clase a la WPFwithEFSample:
Haga clic con el botón derecho en el nombre del proyecto
Seleccione Agregar y, a continuación, Nuevo elemento
Seleccione Clase e introduzca Producto para el nombre de clase
Reemplace la definición de clase Product por el código siguiente:
namespace WPFwithEFSample
{
{
public int ProductId { get; set; }

public virtual Category Category { get; set; }
}
}
- Add a **Category** class with the following definition:
{
public class Category
{
public Category()
{
this.Products = new ObservableCollection<Product>();
}

public virtual ObservableCollection<Product> Products { get; private set; }

}
}
El Products propiedad en el Categor y clase y Categor y propiedad en el Product clase son propiedades de
Además de definir entidades, debe definir una clase que derive de<DbContext y expone las propiedades de DbSet
TEntity.> Las propiedades<DbSet TEntity> permiten al contexto saber qué tipos desea incluir en el modelo.
Una instancia del tipo derivado DbContext administra los objetos de entidad durante el tiempo de ejecución, lo
que incluye rellenar objetos con datos de una base de datos, realizar el seguimiento de cambios y conservar los
Agregue una nueva clase ProductContext al proyecto con la siguiente definición:
{
{
}
}
Opción 2: Definir un modelo utilizando Database First
En esta sección se muestra cómo usar Database First para realizar ingeniería inversa del modelo desde una base
de datos mediante el diseñador de EF. Si ha completado la sección anterior (Opción 1: Definir un modelo
mediante Code First), omita esta sección y vaya directamente a la sección Carga diferida.
Crear una base de datos existente
Normalmente, cuando se dirige a una base de datos existente, ya se creará, pero para este tutorial necesitamos
crear una base de datos para tener acceso.
que haya instalado:
Si usa Visual Studio 2012, va a crear una base de datos LocalDB.
Vamos a seguir adelante y generar la base de datos.
Ver> - Explorador de ser vidores
Haga clic con el botón derecho en Conexiones de datos -> Agregar conexión...
Si no se ha conectado a una base de datos desde el Explorador de servidores antes de que deba seleccionar
Microsoft SQL Server como origen de datos
Conéctese a LocalDB o SQL Express, dependiendo del que haya instalado, e introduzca Products como
nombre de la base de datos
Seleccione Aceptar y se le preguntará si desea crear una nueva base de datos, seleccione Sí
La nueva base de datos aparecerá ahora en el Explorador de servidores, haga clic con el botón derecho en
ella y seleccione Nueva consulta
Copie el siguiente SQL en la nueva consulta, haga clic con el botón derecho en la consulta y seleccione
Ejecutar
CREATE TABLE [dbo].[Categories] (
[CategoryId] [int] NOT NULL IDENTITY,
CONSTRAINT [PK_dbo.Categories] PRIMARY KEY ([CategoryId])
)
CREATE TABLE [dbo].[Products] (

[ProductId] [int] NOT NULL IDENTITY,
[CategoryId] [int] NOT NULL,
CONSTRAINT [PK_dbo.Products] PRIMARY KEY ([ProductId])
)
CREATE INDEX [IX_CategoryId] ON [dbo].[Products]([CategoryId])
ALTER TABLE [dbo].[Products] ADD CONSTRAINT [FK_dbo.Products_dbo.Categories_CategoryId] FOREIGN KEY

([CategoryId]) REFERENCES [dbo].[Categories] ([CategoryId]) ON DELETE CASCADE
Modelo de ingeniería inversa

modelo.
Proyecto> - Añadir nuevo elemento...
Seleccione Datos en el menú de la izquierda y, a continuación, ADO.NET Entity Data Model
Escriba ProductModel como nombre y haga clic en Aceptar
Esto inicia el Asistente para Entity Data Model
Seleccione Generar a par tir de la base de datos y haga clic en Siguiente
Seleccione la conexión a la base de datos que creó en la primera sección, escriba ProductContext como
nombre de la cadena de conexión y haga clic en Siguiente
Haga clic en la casilla de verificación situada junto a 'Tablas' para importar todas las tablas y haga clic en
'Finalizar'
Una vez completado el proceso de ingeniería inversa, el nuevo modelo se agrega al proyecto y se abre para que lo
vea en Entity Framework Designer. También se ha agregado un archivo App.config al proyecto con los detalles de
conexión de la base de datos.
Si está trabajando en Visual Studio 2010, deberá actualizar el diseñador de EF para usar la generación de código
EF6.
Haga clic con el botón derecho en un punto vacío del modelo en EF Designer y seleccione Agregar elemento de
generación de código...
Seleccione Plantillas en línea en el menú de la izquierda y busque DbContext
Seleccione EF 6.x DbContext#Generator para C , escriba ProductsModel como nombre y haga clic en
Agregar
Actualización de la generación de código para el enlace de datos
EF genera código a partir del modelo mediante plantillas T4. Las plantillas incluidas con Visual Studio o
descargadas de la galería de Visual Studio están diseñadas para uso general. Esto significa que las entidades
generadas a<> partir de estas plantillas tienen propiedades ICollection T simples. Sin embargo, al realizar el
enlace de datos mediante WPFWPF es deseable usar Obser vableCollection para las propiedades de colección
para que WPFWPF pueda realizar un seguimiento de los cambios realizados en las colecciones. Para ello vamos a
modificar las plantillas para utilizar ObservableCollection.
Abra el Explorador de soluciones y busque el archivo ProductModel.edmx
Busque el archivo ProductModel.tt que se anidará en el archivo ProductModel.edmx
Haga doble clic en el archivo ProductModel.tt para abrirlo en el editor de Visual Studio
Busque y reemplace las dos apariciones de "ICollection" por "Obser vableCollection ". Estos se
encuentran aproximadamente en las líneas 296 y 484.
Busque y reemplace la primera aparición de "HashSet " por "Obser vableCollection ". Esta ocurrencia se
encuentra aproximadamente en la línea 50. No reemplace la segunda aparición de HashSet que se
encuentra más adelante en el código.
Busque y reemplace la única aparición de "System.Collections.Generic " por
"System.Collections.ObjectModel ". Se encuentra aproximadamente en la línea 424.
Guarde el archivo ProductModel.tt. Esto debería hacer que se regenere el código de las entidades. Si el
código no se regenera automáticamente, haga clic con el botón derecho en ProductModel.tt y elija "Ejecutar
herramienta personalizada".
Si ahora abre el archivo de Category.cs (que está anidado en ProductModel.tt), debería ver que la colección
Products tiene el tipo Obser vableCollection<Product> .
Carga diferida
El Products propiedad en el Categor y clase y Categor y propiedad en el Product clase son propiedades de
EF le ofrece la opción de cargar entidades relacionadas desde la base de datos automáticamente la primera vez
que tenga acceso a la propiedad de navegación. Con este tipo de carga (denominada carga diferida), tenga en
cuenta que la primera vez que acceda a cada propiedad de navegación se ejecutará una consulta independiente en
la base de datos si el contenido no está ya en el contexto.
Cuando se usan tipos de entidad POCO, EF logra la carga diferida mediante la creación de instancias de tipos de
proxy derivados durante el tiempo de ejecución y, a continuación, invalidar las propiedades virtuales en las clases
para agregar el enlace de carga. Para obtener la carga diferida de objetos relacionados, debe declarar los
captadores de propiedades de navegación como públicos y vir tuales (Overridable en Visual Basic) y la clase no
debe estar sellada (NotOverridable en Visual Basic). Cuando se utilizan las propiedades de navegación de
Database First se hacen virtuales automáticamente para habilitar la carga diferida. En la sección Code First
elegimos hacer que las propiedades de navegación sean virtuales por la misma razón
Enlazar objeto a controles

Agregue las clases que se definen en el modelo como orígenes de datos para esta aplicación WPFWPF.
Haga doble clic en MainWindow.xaml en el Explorador de soluciones para abrir el formulario principal
En el menú principal, seleccione Proyecto -> Agregar nuevo origen de datos ... (en Visual Studio
2010, debe seleccionar Datos -> Agregar nuevo origen de datos... )
En la ventana Elegir un tipo de origen de datos, seleccione Objeto y haga clic en Siguiente
En el cuadro de diálogo Seleccionar los objetos de datos, desdoble el ARCHIVO WPFwithEFSample dos
veces y seleccione Categoría
No es necesario seleccionar el origen de datos Del producto, porque llegaremos a él a través de la
propiedad Producto en el origen de datos Categoría
Haga clic en Finalizar .
La ventana Orígenes de datos se abre junto a la ventana MainWindow.xaml Si la ventana Orígenes de
*datos no se muestra, seleccione Ver -> Otros orígenes de> datos * de Windows
Pulse el icono de pasador para que la ventana Orígenes de datos no se oculte automáticamente. Es posible
que deba pulsar el botón de actualización si la ventana ya estaba visible.
Seleccione el origen de datos Categoría y arrástrelo al formulario.

Lo siguiente ocurrió cuando arrastramos esta fuente:
El recurso categor yViewSource y el control categor yDataGrid se agregaron a XAML
El DataContext propiedad en el elemento Grid primario se estableció en "'StaticResource
categor yViewSource '".El recurso categor yViewSource sirve como origen\de enlace para el elemento
Grid primario externo. A continuación, los elementos Grid internos heredan el valor DataContext de la
cuadrícula primaria (la propiedad ItemsSource de categoryDataGrid se establece en "-Binding-")
<Window.Resources>
<CollectionViewSource x:Key="categoryViewSource"
d:DesignSource="{d:DesignInstance {x:Type local:Category}, CreateList=True}"/>
</Window.Resources>
<Grid DataContext="{StaticResource categoryViewSource}">
<DataGrid x:Name="categoryDataGrid" AutoGenerateColumns="False" EnableRowVirtualization="True"
ItemsSource="{Binding}" Margin="13,13,43,191"
RowDetailsVisibilityMode="VisibleWhenSelected">
<DataGrid.Columns>
<DataGridTextColumn x:Name="categoryIdColumn" Binding="{Binding CategoryId}"
Header="Category Id" Width="SizeToHeader"/>
<DataGridTextColumn x:Name="nameColumn" Binding="{Binding Name}"
Header="Name" Width="SizeToHeader"/>
</DataGrid.Columns>
</DataGrid>
</Grid>
Adición de una cuadrícula de detalles

Ahora que tenemos una cuadrícula para mostrar Categorías vamos a agregar una cuadrícula de detalles para
mostrar los Productos asociados.
Seleccione la propiedad Products en el origen de datos Categor y y arrástrela al formulario.
El recurso categor yProductsViewSource y la cuadrícula productDataGrid se agregan a XAML
La ruta de enlace para este recurso se establece en Products
WPFWPF marco de enlace de datos garantiza que sólo los productos relacionados con la categoría
seleccionada se muestran en productDataGrid
Desde el cuadro de herramientas, arrastre Button al formulario. Establezca la propiedad Name en
buttonSave y la propiedad Content en Save .
El formulario debe ser similar a esto:
Agregar código que controla la interacción de datos

Es hora de agregar algunos controladores de eventos a la ventana principal.
En la ventana XAML, ** <** haga clic en el elemento Window, esto selecciona la ventana principal
En la ventana Propiedades elija Eventos en la parte superior derecha y, a continuación, haga doble clic en
el cuadro de texto situado a la derecha de la etiqueta Cargado
Agregue también el evento Click para el botón Guardar haciendo doble clic en el botón Guardar del
diseñador.
Esto le lleva al código subyacente para el formulario, ahora vamos a editar el código para usar el ProductContext
para realizar el acceso a datos. Actualice el código de MainWindow como se muestra a continuación.
El código declara una instancia de ejecución prolongada de ProductContext . El objeto ProductContext se utiliza
para consultar y guardar datos en la base de datos. A continuación, se llama a Dispose() en la instancia de
ProductContext desde el método OnClosing invalidado.Los comentarios de código proporcionan detalles sobre
lo que hace el código.
using System.Linq;
using System.Windows;
{
public partial class MainWindow : Window
{
private ProductContext _context = new ProductContext();
public MainWindow()
{
}
private void Window_Loaded(object sender, RoutedEventArgs e)

{
System.Windows.Data.CollectionViewSource categoryViewSource =
((System.Windows.Data.CollectionViewSource)(this.FindResource("categoryViewSource")));
// Load is an extension method on IQueryable,

// defined in the System.Data.Entity namespace.
// This method enumerates the results of the query,
// similar to ToList but without creating a list.
// When used with Linq to Entities this method
// creates entity objects and adds them to the context.
// After the data is loaded call the DbSet<T>.Local property

// to use the DbSet<T> as a binding source.
categoryViewSource.Source = _context.Categories.Local;
}
private void buttonSave_Click(object sender, RoutedEventArgs e)

{
// When you delete an object from the related entities collection
// (in this case Products), the Entity Framework doesn’t mark
// these child entities as deleted.
// Instead, it removes the relationship between the parent and the child
// by setting the parent reference to null.
// So we manually have to delete the products
// that have a Category reference set to null.
// The following code uses LINQ to Objects
// against the Local collection of Products.
// The ToList call is required because otherwise the collection will be modified
// by the Remove call while it is being enumerated.
// In most other situations you can use LINQ to Objects directly
// against the Local property without using ToList first.
foreach (var product in _context.Products.Local.ToList())
{
if (product.Category == null)
{
_context.Products.Remove(product);
}
}
// Refresh the grids so the database generated values show up.
this.categoryDataGrid.Items.Refresh();
this.productsDataGrid.Items.Refresh();
}
protected override void OnClosing(System.ComponentModel.CancelEventArgs e)

{
base.OnClosing(e);
this._context.Dispose();
}
}
Pruebe la aplicación WPF

Compile y ejecute la aplicación. Si usó Code First, verá que se crea una base de datos
WPFwithEFSample.ProductContext automáticamente.
Escriba un nombre de categoría en la cuadrícula superior y los nombres de productos en la cuadrícula
inferior No escriba nada en las columnas de ID, porque la clave principal la genera la base de datos
Pulse el botón Guardar para guardar los datos en la base de datos

Después de la llamada a SaveChanges() de DbContext, los identificadores se rellenan con los valores generados
por la base de datos. Porque llamamos a Refresh() después de SaveChanges() los controles DataGrid también
se actualizan con los nuevos valores.
Para obtener más información sobre el enlace de datos a colecciones mediante WPFWPF, vea este tema en la
documentación de WPFWPF.
Trabajo con entidades desconectadas
En una aplicación basada en Entity Framework, una clase de contexto es responsable de detectar los cambios
aplicados a las entidades sometidas a seguimiento. Una llamada al método SaveChanges almacena los cambios
que controla el contexto en la base de datos. Cuando se trabaja con aplicaciones de n niveles, los objetos de
entidad generalmente se modifican mientras están desconectados del contexto y es necesario decidir cómo
realizar el seguimiento de los cambios y notificar esos cambios al contexto. En este tema se habla de las distintas
opciones disponibles cuando se usa Entity Framework con entidades desconectadas.
Marcos de trabajo de servicio web

Las tecnologías de servicios web suelen admitir modelos que pueden usarse para almacenar los cambios en
objetos individuales desconectados. Por ejemplo, ASP.NET Web API permite codificar acciones de controlador que
pueden incluir llamadas a EF para almacenar los cambios realizados en un objeto en una base de datos. De hecho,
las herramientas de Web API de Visual Studio facilitan la aplicación de scaffolding a un controlador de Web API
desde el modelo de Entity Framework 6. Para obtener más información, vea Usar Web API con Entity Framework 6.
Históricamente, ha habido otras tecnologías de servicios web que ofrecían integración con Entity Framework,
como WCF Data Services y RIA Services.
API de EF de bajo nivel

Si no quiere usar una solución de n niveles existente, o si quiere personalizar lo que ocurre dentro de una acción
de controlador en los servicios de Web API, Entity Framework proporciona API que permiten aplicar los cambios
realizados en un nivel desconectado. Para obtener más información, vea Add, Attach, and entity state (Agregar,
adjuntar y estado de entidad).
Entidades de seguimiento propio

El seguimiento de los cambios en gráficos arbitrarios de entidades mientras se está desconectado del contexto de
EF es un problema difícil. Uno de los intentos de solucionar el problema fue la plantilla de generación de código
Entidades de autoseguimiento. Esta plantilla genera clases de entidad que contienen lógica para seguir los cambios
realizados en un nivel desconectado como estado en las propias entidades. También se genera un conjunto de
métodos de extensión para aplicar esos cambios a un contexto.
Esta plantilla se puede usar con los modelos creados mediante EF Designer, pero no con modelos de Code First.
Para obtener más información, vea Entidades de autoseguimiento.
IMPORTANT
Ya no se recomienda usar la plantilla Entidades de autoseguimiento. Solo sigue estando disponible para la compatibilidad con
las aplicaciones existentes. Si la aplicación necesita trabajar con gráficos desconectados de entidades, considere otras
alternativas, como Trackable Entities, que es una tecnología similar a Entidades de autoseguimiento pero que la comunidad
desarrolla de forma más activa, o escriba código personalizado mediante la API de seguimiento de cambios de bajo nivel.
Entidades de autoseguimiento
IMPORTANT
Ya no se recomienda usar la plantilla Entidades de autoseguimiento. Solo sigue estando disponible para la compatibilidad
con las aplicaciones existentes. Si la aplicación necesita trabajar con gráficos desconectados de entidades, considere otras
En una aplicación basada en Entity Framework, el responsable de realizar el seguimiento de los cambios en los
objetos es un contexto. Luego se usa el método SaveChanges para almacenar los cambios en la base de datos.
Cuando se trabaja con aplicaciones de n niveles, los objetos de entidad generalmente están desconectados del
contexto y es necesario decidir cómo realizar el seguimiento de los cambios y notificar esos cambios al contexto.
Las entidades de autoseguimiento (STE) pueden ayudar a realizar el seguimiento de los cambios en cualquier nivel
y luego reproducir estos cambios en un contexto que se vaya a guardar.
Use STE solo si el contexto no está disponible en un nivel en el que se realizan cambios en el gráfico del objeto. Si
el contexto está disponible, no hay necesidad de usar STE, ya que él mismo se encarga del seguimiento de los
cambios.
Este elemento de plantilla genera dos archivos .tt (plantilla de texto):
El archivo <nombreDelModelo>.tt genera los tipos de entidad y una clase del asistente que contiene la
lógica de seguimiento de cambios que usan las entidades de autoseguimiento y los métodos de extensión que
permiten establecer el estado en las entidades de autoseguimiento.
El archivo <nombreDelModelo>.Context.tt genera un contexto derivado y una clase de extensión que
contiene métodos ApplyChanges para las clases ObjectContext y ObjectSet . Estos métodos examinan la
información del seguimiento de cambios contenida en el grafo de entidades con seguimiento propio para
deducir el conjunto de operaciones que se deben realizar con el fin de guardar los cambios en la base de datos.
Introducción
Para comenzar, visite la página Self-Tracking Entities Walkthrough (Tutorial sobre entidades de autoseguimiento).
Consideraciones funcionales al trabajar con entidades de seguimiento

propio
IMPORTANT
Tenga en cuenta lo siguiente al trabajar con entidades de seguimiento propio:

Asegúrese de que el proyecto cliente tenga una referencia al ensamblado con los tipos de entidad. Si
agrega solo la referencia de servicio al proyecto cliente, este proyecto usará los tipos de proxy WCF y no los
tipos reales de entidad de seguimiento propio. Es decir, no obtendrá las características de notificación
automatizadas que administran el seguimiento de las entidades en el cliente. Si, a propósito, no desea
incluir los tipos de entidad, deberá establecer manualmente la información de seguimiento de cambios en
el cliente de los cambios que se van a devolver al servicio.
Las llamadas a la operación de servicio no deben tener estado y deben crear una nueva instancia del
contexto del objeto. Asimismo, se recomienda crear el contexto del objeto en un bloque using .
Si envía el gráfico modificado en el cliente al servicio y luego planea seguir trabajando con el mismo
gráfico en el cliente, debe iterar manualmente el gráfico y llamar al método AcceptChanges en cada
objeto para restablecer la herramienta de seguimiento de cambios.
Si los objetos del gráfico contienen propiedades con valores generados por la base de datos (por
ejemplo, valores de identidad o simultaneidad), Entity Framework reemplaza los valores de estas
propiedades por los valores generados por la base de datos después de llamar al método
SaveChanges . Puede implementar la operación del servicio para que devuelva objetos guardados o
una lista de los valores de propiedad generados de los objetos devueltos al cliente. El cliente debe
reemplazar las instancias del objeto o los valores de propiedad del objeto con los objetos o los valores
de propiedad devueltos desde la operación de servicio.
Si se combinan gráficos de varias solicitudes de servicio, se pueden presentar objetos con valores de clave
duplicada en el gráfico resultante. Entity Framework no quita los objetos con claves duplicadas cuando
llama al método ApplyChanges , sino que produce una excepción. Para evitar tener gráficos con valores de
clave duplicados, siga uno de los modelos descritos en el siguiente blog: Self-Tracking Entities:
ApplyChanges and duplicate entities (Entidades de autoseguimiento: ApplyChanges y entidades
duplicadas).
Cuando se cambia la relación entre objetos mediante el establecimiento de la propiedad de clave externa, la
propiedad de navegación de referencia se establece en NULL y no se sincroniza con la entidad de seguridad
adecuada en el cliente. Después de adjuntar el gráfico al contexto del objeto (por ejemplo, después de
llamar al método ApplyChanges ), se sincronizan las propiedades de clave externa y de navegación.
No disponer de ninguna propiedad de navegación de referencia sincronizada con el objeto principal

adecuado podría representar un problema si ha especificado la eliminación en cascada en la relación de
clave externa. Si elimina la entidad de seguridad, la eliminación no se propagará a los objetos
dependientes. Si ha especificado eliminaciones en cascada, use las propiedades de navegación para
cambiar las relaciones en vez de establecer la propiedad de clave externa.
Las entidades con seguimiento propio no están habilitadas para realizar una carga diferida.
La serialización binaria y la serialización a los objetos de administración de estado de ASP.NET no se
admiten en las entidades de autoseguimiento. Sin embargo, puede personalizar la plantilla para agregar la
compatibilidad de serialización binaria. Para obtener más información, vea Using Binary Serialization and
ViewState with Self-Tracking Entities (Uso de la serialización binaria y ViewState con entidades de
autoseguimiento).
Consideraciones sobre la seguridad

Al trabajar con entidades de autoseguimiento, deben contemplarse las siguientes consideraciones de seguridad:
Un servicio no debería confiar en solicitudes de recuperación o actualización de datos que proceden de un
cliente que no es de plena confianza o transmitidas a través de un canal que no es de plena confianza. Se debe
autenticar un cliente: es necesario utilizar un canal seguro o la envoltura de mensajes. Se deben validar las
solicitudes de los clientes de actualización o recuperación de datos para asegurarse de que se ajustan a los
cambios legítimos y previstos del escenario dado.
Evite utilizar información confidencial como claves de entidad (por ejemplo, números de seguridad social). Esto
reduce la posibilidad de que pueda serializarse de forma inadvertida información confidencial en los grafos de
entidades con seguimiento propio de un cliente que no es de plena confianza. Con asociaciones
independientes, se podría enviar también al cliente la clave original de una entidad que esté relacionada con la
que se está serializando.
Para evitar propagar mensajes de excepción con datos confidenciales en el nivel de cliente, las llamadas a
ApplyChanges y SaveChanges en el nivel del servidor se deben encapsular en un código de control de
excepciones.
Tutorial de entidades de seguimiento propio
IMPORTANT
En este tutorial se muestra el escenario en el que un servicio de Windows Communication Foundation (WCF)
expone una operación que devuelve un gráfico de entidades. A continuación, una aplicación cliente manipula
dicho gráfico y envía las modificaciones a una operación de servicio que valida y guarda las actualizaciones en una
base de datos mediante Entity Framework.
Antes de completar este tutorial, asegúrese de leer la página entidades de seguimiento propio .
Este tutorial realiza las siguientes acciones:
Crea una base de datos a la que se tiene acceso.
Crea una biblioteca de clases que contiene el modelo.
Intercambia la plantilla generador de entidades de seguimiento propio.
Mueve las clases de entidad a un proyecto independiente.
Crea un servicio WCF que expone las operaciones para consultar y guardar entidades.
Crea aplicaciones cliente (consola y WPF) que consumen el servicio.
Usaremos Database First en este tutorial, pero las mismas técnicas se aplican igualmente a Model First.
Requisitos previos
Para completar este tutorial, necesitará una versión reciente de Visual Studio.
Crear una base de datos

que haya instalado:
Si usa Visual Studio 2012, va a crear una base de datos de LocalDB.
Abra Visual Studio.
Si no se ha conectado a una base de datos desde Explorador de servidores antes de que tenga que seleccionar
Microsoft SQL Ser ver como origen de datos
Conéctese a LocalDB o a SQL Express, en función de la que haya instalado.
Escriba STESample como nombre de la base de datos
La nueva base de datos aparecerá ahora en Explorador de servidores
Si usa Visual Studio 2012
Haga clic con el botón derecho en la base de datos en Explorador de servidores y seleccione nueva
consulta .
Seleccionar datos-> el editor de TRANSACT SQL-> nueva consulta.. .
Escriba .\SQLEXPRESS como nombre del servidor y haga clic en Aceptar .
Seleccione la base de datos STESample en la lista desplegable de la parte superior del editor de
consultas.
seleccione ejecutar SQL .
CREATE TABLE [dbo].[Blogs] (

[BlogId] INT IDENTITY (1, 1) NOT NULL,
[Name] NVARCHAR (200) NULL,
[Url] NVARCHAR (200) NULL,
CONSTRAINT [PK_dbo.Blogs] PRIMARY KEY CLUSTERED ([BlogId] ASC)
);
CREATE TABLE [dbo].[Posts] (

[PostId] INT IDENTITY (1, 1) NOT NULL,
[Title] NVARCHAR (200) NULL,
[Content] NTEXT NULL,
[BlogId] INT NOT NULL,
CONSTRAINT [PK_dbo.Posts] PRIMARY KEY CLUSTERED ([PostId] ASC),
CONSTRAINT [FK_dbo.Posts_dbo.Blogs_BlogId] FOREIGN KEY ([BlogId]) REFERENCES [dbo].[Blogs] ([BlogId])
ON DELETE CASCADE
);
SET IDENTITY_INSERT [dbo].[Blogs] ON

INSERT INTO [dbo].[Blogs] ([BlogId], [Name], [Url]) VALUES (1, N'ADO.NET Blog', N'blogs.msdn.com/adonet')
SET IDENTITY_INSERT [dbo].[Blogs] OFF
INSERT INTO [dbo].[Posts] ([Title], [Content], [BlogId]) VALUES (N'Intro to EF', N'Interesting stuff...',
1)
INSERT INTO [dbo].[Posts] ([Title], [Content], [BlogId]) VALUES (N'What is New', N'More interesting
stuff...', 1)
Crear el modelo
En primer lugar, necesitamos un proyecto en el que colocar el modelo.
Archivo-> nuevo proyecto de>...
Seleccione Visual C# en el panel izquierdo y, a continuación, biblioteca de clases
Escriba STESample como nombre y haga clic en Aceptar .
Ahora vamos a crear un modelo simple en EF Designer para tener acceso a la base de datos:
Seleccione datos en el panel izquierdo y, a continuación, ADO.NET Entity Data Model
Escriba BloggingModel como nombre y haga clic en Aceptar .
Escriba la información de conexión de la base de datos que creó en la sección anterior
Escriba BloggingContext como nombre de la cadena de conexión y haga clic en siguiente .
Active la casilla situada junto a tablas y haga clic en Finalizar .
Intercambio a la generación de código de STE
Ahora es necesario deshabilitar la generación de código y el intercambio predeterminados para las entidades de
seguimiento propio.
Expanda BloggingModel. edmx en Explorador de soluciones y elimine BloggingModel.TT y
BloggingModel.Context.TT esto deshabilitará la generación de código predeterminada
Haga clic con el botón secundario en un área vacía de la superficie de EF Designer y seleccione Agregar
elemento de generación de código.. .
Seleccione en línea en el panel izquierdo y busque el generador Ste .
Seleccione el generador Ste para C# plantilla, escriba STETemplate como nombre y haga clic en Agregar .
Los archivos STETemplate.TT y STETemplate.Context.TT se agregan anidados en el archivo BloggingModel.
edmx.
Haga clic con el botón secundario en un área vacía de la superficie de EF Designer y seleccione Agregar
Seleccione código en el panel izquierdo y, a continuación, ADO.net generador de entidades de
seguimiento propio .
Escriba STETemplate como nombre y haga clic en Agregar .
Los archivos STETemplate.TT y STETemplate.Context.TT se agregan directamente al proyecto
Traslado de tipos de entidad a un proyecto independiente

Para usar entidades de seguimiento propio, nuestra aplicación cliente necesita acceso a las clases de entidad
generadas a partir de nuestro modelo. Dado que no queremos exponer todo el modelo a la aplicación cliente,
vamos a trasladar las clases de entidad a un proyecto independiente.
El primer paso es dejar de generar las clases de entidad en el proyecto existente:
Haga clic con el botón derecho en STETemplate.TT en Explorador de soluciones y seleccione propiedades
.
En la ventana propiedades , desactive TextTemplatingFileGenerator de la propiedad CustomTool .
Expandir STETemplate.TT en Explorador de soluciones y eliminar todos los archivos anidados en él
A continuación, vamos a agregar un nuevo proyecto y a generar las clases de entidad en él.
Archivo-> proyecto de complemento de>...
Seleccione Visual C# en el panel izquierdo y, a continuación, biblioteca de clases
Escriba STESample. Entities como nombre y haga clic en Aceptar .
Proyecto-> Agregar elemento existente...
Navegue hasta la carpeta del proyecto STESample
Seleccione esta información para ver todos los archivos (*.*)
Seleccione el archivo STETemplate.TT
Haga clic en la flecha desplegable situada junto al botón Agregar y seleccione Agregar como vínculo .
También vamos a asegurarnos de que las clases de entidad se generan en el mismo espacio de nombres que el
contexto. Esto solo reduce el número de instrucciones Using que necesitamos agregar en toda la aplicación.
Haga clic con el botón derecho en el STETemplate.TT vinculado en Explorador de soluciones y seleccione
propiedades .
En la ventana propiedades , establezca el espacio de nombres de la herramienta personalizada en
STESample
El código generado por la plantilla STE necesitará una referencia a System. Runtime. Serialization para
compilar. Esta biblioteca es necesaria para los atributos DataContract y DataMember de WCF que se utilizan en
los tipos de entidad serializables.
Haga clic con el botón derecho en el proyecto STESample. Entities en Explorador de soluciones y
seleccione Agregar referencia.. .
En Visual Studio 2012: Active la casilla situada junto a System. Runtime. Serialization y haga clic en
Aceptar .
En Visual Studio 2010: seleccione System. Runtime. Serialization y haga clic en Aceptar .
Por último, el proyecto con nuestro contexto en él necesitará una referencia a los tipos de entidad.
Haga clic con el botón derecho en el proyecto STESample en Explorador de soluciones y seleccione
Agregar referencia.. .
En Visual Studio 2012: seleccione solución en el panel izquierdo, active la casilla situada junto a
STESample. entidades y haga clic en Aceptar .
En Visual Studio 2010: seleccione la pestaña proyectos , seleccione STESample. Entities y haga clic en
Aceptar .
NOTE
Otra opción para mover los tipos de entidad a un proyecto independiente consiste en mover el archivo de plantilla, en lugar
de vincularlo desde su ubicación predeterminada. Si lo hace, tendrá que actualizar la variable ArchivoDeEntrada en la
plantilla para proporcionar la ruta de acceso relativa al archivo edmx (en este ejemplo sería ..\BloggingModel. edmx).
Crear un servicio WCF
Ahora es el momento de agregar un servicio WCF para exponer nuestros datos, comenzaremos por crear el
proyecto.
Archivo-> proyecto de complemento de>...
Seleccione Visual C# en el panel izquierdo y, a continuación, aplicación de ser vicio WCF
Escriba STESample. Ser vice como nombre y haga clic en Aceptar .
Agregar una referencia al ensamblado System. Data. Entity
Agregar una referencia a los proyectos STESample y STESample. Entities
Necesitamos copiar la cadena de conexión de EF en este proyecto para que se encuentre en tiempo de ejecución.
Abra el archivo app. config para el proyecto **STESample **y copie el elemento connectionStrings .
Pegue el elemento connectionStrings como un elemento secundario del elemento de configuración del
archivo Web. config en el proyecto STESample. Ser vice.
Ahora es el momento de implementar el servicio real.
Abra ISer vice1.CS y reemplace el contenido por el código siguiente.
using System.ServiceModel;
namespace STESample.Service
{
[ServiceContract]
public interface IService1
{
[OperationContract]
List<Blog> GetBlogs();
[OperationContract]
void UpdateBlog(Blog blog);
}
}
Abra Ser vice1. SVC y reemplace el contenido por el código siguiente.

using System;
using System.Data;
using System.Linq;
namespace STESample.Service
{
public class Service1 : IService1
{
/// <summary>
/// Gets all the Blogs and related Posts.
/// </summary>
public List<Blog> GetBlogs()
{
using (BloggingContext context = new BloggingContext())
{
return context.Blogs.Include("Posts").ToList();
}
}
/// <summary>
/// Updates Blog and its related Posts.
/// </summary>
public void UpdateBlog(Blog blog)
{
using (BloggingContext context = new BloggingContext())
{
try
{
// TODO: Perform validation on the updated order before applying the changes.
// The ApplyChanges method examines the change tracking information

// contained in the graph of self-tracking entities to infer the set of operations
// that need to be performed to reflect the changes in the database.
context.Blogs.ApplyChanges(blog);
}
catch (UpdateException)
{
// To avoid propagating exception messages that contain sensitive data to the client
tier
// calls to ApplyChanges and SaveChanges should be wrapped in exception handling code.
throw new InvalidOperationException("Failed to update. Try your request again.");
}
}
}
}
}
Consumo del servicio desde una aplicación de consola

Vamos a crear una aplicación de consola que use nuestro servicio.
Seleccione Visual C# en el panel izquierdo y, a continuación, aplicación de consola
Escriba STESample. ConsoleTest como nombre y haga clic en Aceptar .
Agregar una referencia al proyecto STESample. Entities
Necesitamos una referencia de servicio a nuestro servicio WCF
Haga clic con el botón derecho en el proyecto STESample. ConsoleTest en Explorador de soluciones y
seleccione Agregar referencia de ser vicio...
Haga clic en detectar
Escriba BloggingSer vice como espacio de nombres y haga clic en Aceptar .
Ahora podemos escribir código para consumir el servicio.
Abra el archivo Program.cs y sustituya el contenido por el código siguiente:
using STESample.ConsoleTest.BloggingService;
using System;
using System.Linq;
namespace STESample.ConsoleTest
{
class Program
{
{
// Print out the data before we change anything
Console.WriteLine("Initial Data:");
DisplayBlogsAndPosts();
// Add a new Blog and some Posts

AddBlogAndPost();
Console.WriteLine("After Adding:");
// Modify the Blog and one of its Posts

UpdateBlogAndPost();
Console.WriteLine("After Update:");
// Delete the Blog and its Posts

DeleteBlogAndPost();
Console.WriteLine("After Delete:");

Console.ReadKey();
}
static void DisplayBlogsAndPosts()

{
using (var service = new Service1Client())
{
// Get all Blogs (and Posts) from the service
// and print them to the console
var blogs = service.GetBlogs();
{
Console.WriteLine(blog.Name);
{
Console.WriteLine(" - {0}", post.Title);
}
}
}
}
static void AddBlogAndPost()

{
{
// Create a new Blog with a couple of Posts
var newBlog = new Blog
{
Name = "The New Blog",
Posts =
{
new Post { Title = "Welcome to the new blog"},
new Post { Title = "What's new on the new blog"}
}
};
// Save the changes using the service

service.UpdateBlog(newBlog);
}
}
static void UpdateBlogAndPost()

{
{
// Get all the Blogs
// Use LINQ to Objects to find The New Blog

var blog = blogs.First(b => b.Name == "The New Blog");
// Update the Blogs name

blog.Name = "The Not-So-New Blog";
// Update one of the related posts

blog.Posts.First().Content = "Some interesting content...";

service.UpdateBlog(blog);
}
}
static void DeleteBlogAndPost()

{
{
// Get all the Blogs
// Use LINQ to Objects to find The Not-So-New Blog

var blog = blogs.First(b => b.Name == "The Not-So-New Blog");
// Mark all related Posts for deletion

// We need to call ToList because each Post will be removed from the
// Posts collection when we call MarkAsDeleted
foreach (var post in blog.Posts.ToList())
{
post.MarkAsDeleted();
}
// Mark the Blog for deletion

blog.MarkAsDeleted();

}
}
}
}
Ahora puede ejecutar la aplicación para verla en acción.

Haga clic con el botón derecho en el proyecto STESample. ConsoleTest en Explorador de soluciones y
seleccione depurar-> iniciar nueva instancia .
Verá el siguiente resultado cuando se ejecute la aplicación.
Initial Data:
ADO.NET Blog
- Intro to EF
- What is New
After Adding:
ADO.NET Blog
- Intro to EF
- What is New
The New Blog
- Welcome to the new blog
- What's new on the new blog
After Update:
ADO.NET Blog
- Intro to EF
- What is New
The Not-So-New Blog
- Welcome to the new blog
- What's new on the new blog
After Delete:
ADO.NET Blog
- Intro to EF
- What is New
Press any key to exit...
Consumo del servicio desde una aplicación de WPF

Vamos a crear una aplicación WPF que use nuestro servicio.
Seleccione el #de Visual C en el panel izquierdo y, a continuación, en aplicación WPF .
Escriba STESample. WPFTest como nombre y haga clic en Aceptar .
Agregar una referencia al proyecto STESample. Entities
Necesitamos una referencia de servicio a nuestro servicio WCF
Haga clic con el botón derecho en el proyecto STESample. WPFTest en Explorador de soluciones y
seleccione Agregar referencia de ser vicio...
Haga clic en detectar
Escriba BloggingSer vice como espacio de nombres y haga clic en Aceptar .
Ahora podemos escribir código para consumir el servicio.
Abra MainWindow. Xaml y reemplace el contenido por el código siguiente.
<Window
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:STESample="clr-namespace:STESample;assembly=STESample.Entities"
mc:Ignorable="d" x:Class="STESample.WPFTest.MainWindow"
Title="MainWindow" Height="350" Width="525" Loaded="Window_Loaded">
<Window.Resources>
<CollectionViewSource
x:Key="blogViewSource"
d:DesignSource="{d:DesignInstance {x:Type STESample:Blog}, CreateList=True}"/>
<CollectionViewSource
x:Key="blogPostsViewSource"
Source="{Binding Posts, Source={StaticResource blogViewSource}}"/>
</Window.Resources>
<Grid DataContext="{StaticResource blogViewSource}">

<DataGrid AutoGenerateColumns="False" EnableRowVirtualization="True"
ItemsSource="{Binding}" Margin="10,10,10,179">
<DataGrid.Columns>
<DataGridTextColumn Binding="{Binding BlogId}" Header="Id" Width="Auto" IsReadOnly="True"
/>
<DataGridTextColumn Binding="{Binding Name}" Header="Name" Width="Auto"/>
<DataGridTextColumn Binding="{Binding Url}" Header="Url" Width="Auto"/>
</DataGrid.Columns>
</DataGrid>
<DataGrid AutoGenerateColumns="False" EnableRowVirtualization="True"
ItemsSource="{Binding Source={StaticResource blogPostsViewSource}}"
Margin="10,145,10,38">
<DataGrid.Columns>
<DataGridTextColumn Binding="{Binding PostId}" Header="Id" Width="Auto"
IsReadOnly="True"/>
<DataGridTextColumn Binding="{Binding Title}" Header="Title" Width="Auto"/>
<DataGridTextColumn Binding="{Binding Content}" Header="Content" Width="Auto"/>
</DataGrid.Columns>
</DataGrid>
<Button Width="68" Height="23" HorizontalAlignment="Right" VerticalAlignment="Bottom"
Margin="0,0,10,10" Click="buttonSave_Click">Save</Button>
</Grid>
</Window>
Abra el código subyacente de MainWindow (MainWindow.Xaml.CS ) y reemplace el contenido por el código

siguiente.
using STESample.WPFTest.BloggingService;
using System.Linq;
using System.Windows;
using System.Windows.Data;
namespace STESample.WPFTest
{
public partial class MainWindow : Window
{
public MainWindow()
{
}
private void Window_Loaded(object sender, RoutedEventArgs e)

{
{
// Find the view source for Blogs and populate it with all Blogs (and related Posts)
// from the Service. The default editing functionality of WPF will allow the objects
// to be manipulated on the screen.
var blogsViewSource = (CollectionViewSource)this.FindResource("blogViewSource");
blogsViewSource.Source = service.GetBlogs().ToList();
}
}
private void buttonSave_Click(object sender, RoutedEventArgs e)

{
{
// Get the blogs that are bound to the screen
var blogsViewSource = (CollectionViewSource)this.FindResource("blogViewSource");
var blogs = (List<Blog>)blogsViewSource.Source;
// Save all Blogs and related Posts

{
}
// Re-query for data to get database-generated keys etc.

blogsViewSource.Source = service.GetBlogs().ToList();
}
}
}
}
Ahora puede ejecutar la aplicación para verla en acción.

Haga clic con el botón derecho en el proyecto STESample. WPFTest en Explorador de soluciones y
seleccione depurar-> iniciar nueva instancia .
Puede manipular los datos mediante la pantalla y guardarlos a través del servicio mediante el botón Guardar
Registrar e interceptar operaciones de base de datos
NOTE
A partir de Entity Framework 6, en cualquier momento Entity Framework envía un comando a la base de datos.
este comando puede ser interceptado por el código de la aplicación. Esto se usa normalmente para registrar SQL,
pero también se puede usar para modificar o anular el comando.
En concreto, EF incluye:
Una propiedad de registro para el contexto similar a DataContext. log en LINQ to SQL
Mecanismo para personalizar el contenido y el formato de la salida enviada al registro.
Bloques de creación de bajo nivel para la interceptación, lo que ofrece un mayor control y flexibilidad
Propiedad de registro de contexto

La propiedad DbContext. Database. log se puede establecer en un delegado para cualquier método que toma una
cadena. Normalmente, se usa con cualquier TextWriter estableciéndolo en el método "write" de ese TextWriter.
Todos los SQL generados por el contexto actual se registrarán en ese escritor. Por ejemplo, el código siguiente
registrará SQL en la consola:
using (var context = new BlogContext())

{
context.Database.Log = Console.Write;
// Your code here...

}
Tenga en cuenta ese contexto. Database. log se establece en Console. Write. Esto es todo lo que se necesita para
registrar SQL en la consola.
Vamos a agregar algunos códigos simples de consulta/inserción/actualización para que podamos ver algunos
resultados:
using (var context = new BlogContext())

{
context.Database.Log = Console.Write;
var blog = context.Blogs.First(b => b.Title == "One Unicorn");
blog.Posts.First().Title = "Green Eggs and Ham";
blog.Posts.Add(new Post { Title = "I do not like them!" });
context.SaveChangesAsync().Wait();
}
Se generará el siguiente resultado:

SELECT TOP (1)
[Extent1].[Id] AS [Id],
[Extent1].[Title] AS [Title]
FROM [dbo].[Blogs] AS [Extent1]
WHERE (N'One Unicorn' = [Extent1].[Title]) AND ([Extent1].[Title] IS NOT NULL)
-- Executing at 10/8/2013 10:55:41 AM -07:00
-- Completed in 4 ms with result: SqlDataReader
SELECT
[Extent1].[Title] AS [Title],
[Extent1].[BlogId] AS [BlogId]
FROM [dbo].[Posts] AS [Extent1]
WHERE [Extent1].[BlogId] = @EntityKeyValue1
-- EntityKeyValue1: '1' (Type = Int32)
-- Executing at 10/8/2013 10:55:41 AM -07:00
UPDATE [dbo].[Posts]
SET [Title] = @0
WHERE ([Id] = @1)
-- @0: 'Green Eggs and Ham' (Type = String, Size = -1)
-- @1: '1' (Type = Int32)
-- Executing asynchronously at 10/8/2013 10:55:41 AM -07:00
-- Completed in 12 ms with result: 1
INSERT [dbo].[Posts]([Title], [BlogId])

VALUES (@0, @1)
SELECT [Id]
FROM [dbo].[Posts]
WHERE @@ROWCOUNT > 0 AND [Id] = scope_identity()
-- @0: 'I do not like them!' (Type = String, Size = -1)
-- @1: '1' (Type = Int32)
-- Executing asynchronously at 10/8/2013 10:55:41 AM -07:00
(Tenga en cuenta que esta es la salida, suponiendo que ya se ha producido cualquier inicialización de base de
datos. Si aún no se ha producido la inicialización de la base de datos, habría mucha más salida mostrando todas
las migraciones de trabajo en segundo plano para comprobar o crear una nueva base de datos.
¿Qué se registra?
Cuando se establece la propiedad log, se registran todos los elementos siguientes:
SQL para todos los tipos de comandos diferentes. Por ejemplo:
Consultas, incluidas las consultas LINQ normales, las consultas eSQL y las consultas sin formato de
métodos como SqlQuery
Inserciones, actualizaciones y eliminaciones generadas como parte de SaveChanges
Consultas de carga de relaciones como las generadas por la carga diferida
Parámetros
Si el comando se ejecuta de forma asincrónica o no
Marca de tiempo que indica cuándo empezó A ejecutarse el comando.
Si el comando se completó correctamente, se produjo un error al iniciar una excepción o, para Async, se
canceló.
Alguna indicación del valor del resultado
Cantidad aproximada de tiempo que se tardó en ejecutar el comando. Tenga en cuenta que es el momento en el
que se envía el comando para volver a obtener el objeto de resultado. No incluye el tiempo para leer los
resultados.
Al examinar la salida de ejemplo anterior, cada uno de los cuatro comandos registrados son:
La consulta que resulta de la llamada a context. Blogs. First
Tenga en cuenta que el método ToString para obtener el SQL no habría funcionado para esta consulta
porque "First" no proporciona un IQueryable en el que se podría llamar a ToString
La consulta que resulta de la carga diferida del blog. Publique
Observe los detalles del parámetro para el valor de clave para el que se está produciendo la carga
diferida.
Solo se registran las propiedades del parámetro que se establecen en valores no predeterminados. Por
ejemplo, la propiedad Size solo se muestra si es distinto de cero.
Dos comandos resultantes de SaveChangesAsync; uno para la actualización para cambiar el título de una
publicación, el otro para una inserción para agregar una nueva publicación
Tenga en cuenta los detalles de los parámetros de las propiedades de FK y title
Tenga en cuenta que estos comandos se ejecutan de forma asincrónica
Registro en distintos lugares

Como se indicó anteriormente, el registro en la consola es muy sencillo. También es fácil de registrar en la
memoria, el archivo, etc. mediante el uso de diferentes tipos de TextWriter.
Si está familiarizado con LINQ to SQL podría observar que en LINQ to SQL la propiedad log está establecida en el
objeto TextWriter real (por ejemplo, Console. out) mientras que en EF la propiedad log está establecida en un
método que acepta una cadena (por ejemplo, , Console. Write o Console. out. Write). El motivo es desacoplar EF de
TextWriter mediante la aceptación de cualquier delegado que pueda actuar como receptor de cadenas. Por
ejemplo, Imagine que ya tiene alguna plataforma de registro y que define un método de registro como el
siguiente:
public class MyLogger

{
public void Log(string component, string message)
{
Console.WriteLine("Component: {0} Message: {1} ", component, message);
}
}
Se puede enlazar a la propiedad de registro EF de la siguiente manera:
var logger = new MyLogger();

context.Database.Log = s => logger.Log("EFApp", s);
Registro de resultados
El registrador predeterminado registra el texto del comando (SQL), los parámetros y la línea "en ejecución" con
una marca de tiempo antes de que el comando se envíe a la base de datos. Una línea "completada" que contiene el
tiempo transcurrido se registra después de la ejecución del comando.
Tenga en cuenta que para los comandos asincrónicos, la línea "completada" no se registra hasta que la tarea
asincrónica se complete realmente, se produzca un error o se cancele.
La línea "completado" contiene información diferente en función del tipo de comando y de si la ejecución se
realizó correctamente o no.
Ejecución correcta
En el caso de los comandos que se completan correctamente, la salida es "Completed in x MS with result:" seguida
de alguna indicación de cuál fue el resultado. Para los comandos que devuelven un lector de datos, la indicación de
resultado es el tipo de DbDataReader devuelto. En el caso de los comandos que devuelven un valor entero como el
comando UPDATE mostrado sobre el resultado que se muestra es ese entero.
Error de ejecución
En el caso de los comandos que producen un error iniciando una excepción, la salida contiene el mensaje de la
excepción. Por ejemplo, el uso de SqlQuery para realizar consultas en una tabla que existe producirá una salida de
registro similar a la siguiente:
SELECT * from ThisTableIsMissing

-- Executing at 5/13/2013 10:19:05 AM
-- Failed in 1 ms with error: Invalid object name 'ThisTableIsMissing'.
Ejecución cancelada
En el caso de los comandos Async en los que se cancela la tarea, el resultado podría ser un error con una
excepción, ya que esto es lo que suele hacer el proveedor ADO.NET subyacente cuando se intenta cancelar. Si esto
no ocurre y la tarea se cancela correctamente, la salida tendrá un aspecto similar al siguiente:
update Blogs set Title = 'No' where Id = -1

-- Executing asynchronously at 5/13/2013 10:21:10 AM
-- Canceled in 1 ms
Cambiar el contenido y el formato del registro

En, la propiedad Database. log hace uso de un objeto DatabaseLogFormatter. Este objeto enlaza eficazmente una
implementación de IDbCommandInterceptor (consulte a continuación) a un delegado que acepta cadenas y
DbContext. Esto significa que se llama a los métodos de DatabaseLogFormatter antes y después de la ejecución de
comandos por EF. Estos métodos de DatabaseLogFormatter recopilan y dan formato al resultado del registro y lo
envían al delegado.
Personalización de DatabaseLogFormatter
El cambio de lo que se registra y su formato se puede lograr creando una nueva clase que se deriva de
DatabaseLogFormatter e invalida los métodos según corresponda. Los métodos más comunes para invalidar son:
LogCommand: invalide esto para cambiar el modo en que se registran los comandos antes de que se ejecuten.
De forma predeterminada, LogCommand llama a LogParameter para cada parámetro; en su lugar, puede elegir
hacer lo mismo en los parámetros de invalidación o de control de forma diferente.
LogResult: invalide esto para cambiar el modo en que se registra el resultado de la ejecución de un comando.
LogParameter: invalide esto para cambiar el formato y el contenido del registro de parámetros.
Por ejemplo, supongamos que deseamos registrar solo una línea antes de que cada comando se envíe a la base de
datos. Esto puede hacerse con dos invalidaciones:
Invalide LogCommand para dar formato y escribir la única línea de SQL
Invalide LogResult para no hacer nada.
El código tendría un aspecto similar al siguiente:
public class OneLineFormatter : DatabaseLogFormatter
{
public OneLineFormatter(DbContext context, Action<string> writeAction)
: base(context, writeAction)
{
}
public override void LogCommand<TResult>(

DbCommand command, DbCommandInterceptionContext<TResult> interceptionContext)
{
Write(string.Format(
"Context '{0}' is executing command '{1}'{2}",
Context.GetType().Name,
command.CommandText.Replace(Environment.NewLine, ""),
Environment.NewLine));
}
public override void LogResult<TResult>(

{
}
}
Para registrar la salida, simplemente llame al método Write, que enviará la salida al delegado de escritura
configurado.
(Tenga en cuenta que este código hace la eliminación simplista de los saltos de línea como ejemplo. Lo más
probable es que no funcione bien para ver SQL complejo).
Establecer DatabaseLogFormatter
Una vez que se ha creado una nueva clase DatabaseLogFormatter, debe registrarse con EF. Esto se hace mediante
la configuración basada en código. En pocas palabras, esto significa que se crea una nueva clase que se deriva de
DbConfiguration en el mismo ensamblado que la clase DbContext y, después, se llama a SetDatabaseLogFormatter
en el constructor de esta nueva clase. Por ejemplo:
public class MyDbConfiguration : DbConfiguration

{
public MyDbConfiguration()
{
SetDatabaseLogFormatter(
(context, writeAction) => new OneLineFormatter(context, writeAction));
}
}
Usar el nuevo DatabaseLogFormatter

Este nuevo DatabaseLogFormatter se usará siempre que se establezca Database. log. Por lo tanto, la ejecución del
código de la parte 1 generará ahora el siguiente resultado:
Context 'BlogContext' is executing command 'SELECT TOP (1) [Extent1].[Id] AS [Id], [Extent1].[Title] AS
[Title]FROM [dbo].[Blogs] AS [Extent1]WHERE (N'One Unicorn' = [Extent1].[Title]) AND ([Extent1].[Title] IS NOT
NULL)'
Context 'BlogContext' is executing command 'SELECT [Extent1].[Id] AS [Id], [Extent1].[Title] AS [Title],
[Extent1].[BlogId] AS [BlogId]FROM [dbo].[Posts] AS [Extent1]WHERE [Extent1].[BlogId] = @EntityKeyValue1'
Context 'BlogContext' is executing command 'update [dbo].[Posts]set [Title] = @0where ([Id] = @1)'
Context 'BlogContext' is executing command 'insert [dbo].[Posts]([Title], [BlogId])values (@0, @1)select
[Id]from [dbo].[Posts]where @@rowcount > 0 and [Id] = scope_identity()'
Bloques de creación de interceptación

Hasta ahora hemos visto cómo usar DbContext. Database. log para registrar el SQL generado por EF. Pero este
código es realmente una fachada relativamente fina sobre algunos bloques de creación de bajo nivel para la
interceptación más general.
Interfaces de interceptación
El código de intercepción se crea en torno al concepto de interfaces de interceptación. Estas interfaces heredan de
IDbInterceptor y definen métodos a los que se llama cuando EF realiza alguna acción. La intención es tener una
interfaz por cada tipo de objeto que se va a interceptar. Por ejemplo, la interfaz IDbCommandInterceptor define
métodos a los que se llama antes de que EF realice una llamada a ExecuteNonQuery, ExecuteScalar, ExecuteReader
y a los métodos relacionados. Del mismo modo, la interfaz define métodos a los que se llama cuando se completa
cada una de estas operaciones. La clase DatabaseLogFormatter que hemos examinado anteriormente implementa
esta interfaz para registrar los comandos.
El contexto de interceptación
Si se examinan los métodos definidos en cualquiera de las interfaces del interceptor, es evidente que cada llamada
recibe un objeto de tipo DbInterceptionContext o algún tipo derivado de este, como
DbCommandInterceptionContext<>. Este objeto contiene información contextual sobre la acción que está
llevando a cabo EF. Por ejemplo, si la acción se realiza en nombre de un DbContext, el DbContext se incluye en el
DbInterceptionContext. De forma similar, para los comandos que se ejecutan de forma asincrónica, la marca
IsAsync se establece en DbCommandInterceptionContext.
Control de resultados
La clase DbCommandInterceptionContext<> contiene una propiedad denominada result, OriginalResult, Exception
y OriginalException. Estas propiedades se establecen en NULL/Zero para las llamadas a los métodos de
interceptación a los que se llama antes de que se ejecute la operación, es decir, para... Ejecutar métodos. Si la
operación se ejecuta y se realiza correctamente, result y OriginalResult se establecen en el resultado de la
operación. Estos valores se pueden observar en los métodos de interceptación a los que se llama después de que
se haya ejecutado la operación, es decir, en... Métodos ejecutados. Del mismo modo, si se produce la operación, se
establecerán las propiedades Exception y OriginalException.
Suprimir la ejecución
Si un interceptor establece la propiedad de resultado antes de que se ejecute el comando (en una de las
propiedades... Ejecutar métodos) entonces EF no intentará realmente ejecutar el comando, sino que solo usará el
conjunto de resultados. En otras palabras, el interceptor puede suprimir la ejecución del comando, pero el EF
continúa como si se hubiera ejecutado el comando.
Un ejemplo de cómo se podría usar esto es el procesamiento por lotes de comandos que se ha realizado
tradicionalmente con un proveedor de ajuste. El interceptor almacenaría el comando para su ejecución posterior
como un lote, pero "fingiría" a EF que el comando se ejecutaba como normal. Tenga en cuenta que esto requiere
más que esto para implementar el procesamiento por lotes, pero este es un ejemplo de cómo se puede usar el
resultado de la interceptación.
La ejecución también se puede suprimir si se establece la propiedad Exception en una de las propiedades... Ejecutar
métodos. Esto hace que EF continúe como si se produjera un error en la ejecución de la operación produciendo la
excepción dada. Por supuesto, esto puede hacer que la aplicación se bloquee, pero también puede ser una
excepción transitoria o cualquier otra excepción controlada por EF. Por ejemplo, se puede usar en entornos de
prueba para probar el comportamiento de una aplicación cuando se produce un error en la ejecución del
comando.
Cambiar el resultado después de la ejecución
Si un interceptor establece la propiedad de resultado después de que se haya ejecutado el comando (en una de las
propiedades... Métodos ejecutados) entonces EF usará el resultado cambiado en lugar del resultado que se
devolvió realmente desde la operación. Del mismo modo, si un interceptor establece la propiedad Exception
después de que se haya ejecutado el comando, EF producirá la excepción set como si la operación hubiera
producido la excepción.
Un interceptor también puede establecer la propiedad Exception en null para indicar que no se debe producir
ninguna excepción. Esto puede ser útil si se produce un error en la ejecución de la operación, pero el interceptor
quiere que EF continúe como si la operación se hubiera realizado correctamente. Normalmente, esto también
implica establecer el resultado para que EF tenga algún valor de resultado con el que trabajar mientras continúa.
OriginalResult y OriginalException
Después de que EF haya ejecutado una operación, establecerá las propiedades result y OriginalResult si la
ejecución no produjo un error, o bien las propiedades Exception y OriginalException si se produce un error de
ejecución con una excepción.
Las propiedades OriginalResult y OriginalException son de solo lectura y solo las establece EF después de ejecutar
realmente una operación. Los interceptores no pueden establecer estas propiedades. Esto significa que cualquier
interceptor puede distinguir entre una excepción o un resultado establecido por otro interceptor, en lugar de la
excepción real o el resultado que se produjo cuando se ejecutó la operación.
Registro de interceptores
Una vez que se ha creado una clase que implementa una o varias interfaces de interceptación, se puede registrar
con EF mediante la clase DbInterception. Por ejemplo:
DbInterception.Add(new NLogCommandInterceptor());
Los interceptores también se pueden registrar en el nivel de dominio de aplicación mediante el mecanismo de
configuración basado en código DbConfiguration.
Ejemplo: registro en NLog
Vamos a reunir todo esto en un ejemplo que usa IDbCommandInterceptor y NLog para:
Registrar una advertencia para cualquier comando que se ejecute de forma no asincrónica
Registrar un error para cualquier comando que se produzca cuando se ejecute
Esta es la clase que realiza el registro, que se debe registrar como se muestra arriba:
public class NLogCommandInterceptor : IDbCommandInterceptor
{
private static readonly Logger Logger = LogManager.GetCurrentClassLogger();
public void NonQueryExecuting(

DbCommand command, DbCommandInterceptionContext<int> interceptionContext)
{
LogIfNonAsync(command, interceptionContext);
}
public void NonQueryExecuted(

DbCommand command, DbCommandInterceptionContext<int> interceptionContext)
{
LogIfError(command, interceptionContext);
}
public void ReaderExecuting(

DbCommand command, DbCommandInterceptionContext<DbDataReader> interceptionContext)
{
}
public void ReaderExecuted(

DbCommand command, DbCommandInterceptionContext<DbDataReader> interceptionContext)
{
}
public void ScalarExecuting(

DbCommand command, DbCommandInterceptionContext<object> interceptionContext)
{
}
public void ScalarExecuted(

DbCommand command, DbCommandInterceptionContext<object> interceptionContext)
{
}
private void LogIfNonAsync<TResult>(

{
if (!interceptionContext.IsAsync)
{
Logger.Warn("Non-async command used: {0}", command.CommandText);
}
}
private void LogIfError<TResult>(

{
if (interceptionContext.Exception != null)
{
Logger.Error("Command {0} failed with exception {1}",
command.CommandText, interceptionContext.Exception);
}
}
}
Observe cómo este código utiliza el contexto de interceptación para detectar cuándo un comando se ejecuta de
forma no asincrónica y para detectar cuándo se produjo un error al ejecutar un comando.
Consideraciones de rendimiento para EF 4, 5 y 6
Por David Obando, Eric Dettinger y otros

Publicado: abril 2012
Última actualización: 2014 de mayo
1. Introducción
Los marcos de trabajo de asignación relacional de objetos son una manera cómoda de proporcionar una
abstracción para el acceso a datos en una aplicación orientada a objetos. En el caso de las aplicaciones .NET, se
recomienda que el O el RM de Microsoft se Entity Framework. Sin embargo, con cualquier abstracción, el
rendimiento puede ser un problema.
Estas notas del producto se han escrito para mostrar las consideraciones de rendimiento al desarrollar aplicaciones
mediante Entity Framework, para ofrecer a los desarrolladores una idea de los algoritmos internos de Entity
Framework que pueden afectar al rendimiento, y para proporcionar sugerencias de investigación y mejorar el
rendimiento en sus aplicaciones que usan Entity Framework. Hay una serie de buenos temas sobre el rendimiento
que ya están disponibles en la web y también hemos intentado apuntar a estos recursos siempre que sea posible.
El rendimiento es un tema complicado. Estas notas del producto están pensadas como recursos para ayudarle a
tomar decisiones relacionadas con el rendimiento de las aplicaciones que usan Entity Framework. Hemos incluido
algunas métricas de prueba para demostrar el rendimiento, pero estas métricas no están pensadas como
indicadores absolutos del rendimiento que verá en la aplicación.
A efectos prácticos, en este documento se supone Entity Framework 4 se ejecuta en .NET 4,0 y Entity Framework 5
y 6 se ejecutan en .NET 4,5. Muchas de las mejoras de rendimiento realizadas para Entity Framework 5 residen en
los componentes principales que se incluyen con .NET 4,5.
Entity Framework 6 es una versión fuera de banda y no depende de los componentes Entity Framework que se
incluyen con .NET. Entity Framework 6 funcionan tanto en .NET 4,0 como en .NET 4,5 y pueden ofrecer una gran
ventaja de rendimiento a aquellos que no se han actualizado desde .NET 4,0, pero que quieren los bits de Entity
Framework más recientes en su aplicación. Cuando este documento menciona Entity Framework 6, hace referencia
a la última versión disponible en el momento de redactar este documento: versión 6.1.0.
2. actividad en frío frente a ejecución de consultas en caliente

La primera vez que se realiza una consulta en un modelo determinado, el Entity Framework realiza una gran
cantidad de trabajo en segundo plano para cargar y validar el modelo. A menudo, hacemos referencia a esta
primera consulta como una consulta "fría". Las consultas adicionales en un modelo ya cargado se conocen como
consultas "calientes" y son mucho más rápidas.
Vamos a tomar una vista de alto nivel del tiempo que se dedica a la ejecución de una consulta mediante Entity
Framework y ver dónde están mejorando las cosas en Entity Framework 6.
Primera ejecución de la consulta: consulta en frío
ESC RIT URA DE IM PA C TO EN EL IM PA C TO EN EL IM PA C TO EN EL
C Ó DIGO DE USUA RIO A C C IÓ N REN DIM IEN TO DE EF 4 REN DIM IEN TO DE EF 5 REN DIM IEN TO DE EF 6
using(var db = Creación de contexto Media Media Bajo

new MyContext())
{
var q1 = Creación de Bajo Bajo Bajo

from c in expresiones de
db.Customers consulta
where c.Id == id1
select c;
var c1 = Ejecución de -Carga de metadatos: -Carga de metadatos: -Carga de metadatos:

q1.First(); consultas LINQ alta pero almacenada alta pero almacenada alta pero almacenada
en caché en caché en caché
-Vista de la -Vista de la -Ver generación:
generación: generación: medio pero
posiblemente muy posiblemente muy almacenado en caché
alta pero almacenada alta pero almacenada -Evaluación de
en caché en caché parámetros: baja
-Evaluación de -Evaluación de -Traducción de
parámetros: media parámetros: baja consultas: mediana
-Traducción de -Traducción de pero almacenada en
consultas: mediana consultas: mediana caché
-Generación de pero almacenada en -Generación de
materializador: medio caché materializador: medio
pero almacenado en -Generación de pero almacenado en
caché materializador: medio caché
-Ejecución de la pero almacenado en -Ejecución de la
consulta de base de caché consulta de base de
datos: potencialmente -Ejecución de la datos: potencialmente
alta consulta de base de alta (mejores
+ Conexión. abrir datos: potencialmente consultas en algunas
+ Command. alta (mejores situaciones)
ExecuteReader consultas en algunas + Conexión. abrir
+ DataReader. Read situaciones) + Command.
Materialización de + Conexión. abrir ExecuteReader
objetos: medio + Command. + DataReader. Read
-Búsqueda de ExecuteReader Materialización de
identidad: mediana + DataReader. Read objetos: medio (más
Materialización de rápido que EF5)
objetos: medio -Búsqueda de
-Búsqueda de identidad: mediana
identidad: mediana
} Conexión. Close Bajo Bajo Bajo
Segunda ejecución de consultas: consulta en caliente

using(var db = Creación de contexto Media Media Bajo

new MyContext())
{
var q1 = Creación de Bajo Bajo Bajo

from c in expresiones de
db.Customers consulta
where c.Id == id1
select c;
var c1 = Ejecución de -Búsqueda de carga -Búsqueda de carga -Búsqueda de carga

q1.First(); consultas LINQ de metadatos: alta de metadatos: alta de metadatos: alta
pero caché baja pero caché baja pero caché baja
-Vista de la -Vista de la -Ver generación de la
generación de vistas: generación de vistas: búsqueda: medio
potencialmente muy potencialmente muy pero en caché bajo
alta pero con alta pero con -Evaluación de
almacenamiento en almacenamiento en parámetros: baja
caché bajo caché bajo -Consulta de
-Evaluación de -Evaluación de traducción de
parámetros: media parámetros: baja consultas: mediana
-Búsqueda de -Consulta de pero en caché baja
traducción de traducción de -Búsqueda de la
consultas: mediana consultas: mediana generación del
-Búsqueda de la pero en caché baja materializador: medio
generación del -Búsqueda de la pero en caché bajo
materializador: medio generación del -Ejecución de la
pero en caché bajo materializador: medio consulta de base de
-Ejecución de la pero en caché bajo datos: potencialmente
consulta de base de -Ejecución de la alta (mejores
datos: potencialmente consulta de base de consultas en algunas
alta datos: potencialmente situaciones)
+ Conexión. abrir alta (mejores + Conexión. abrir
+ Command. consultas en algunas + Command.
ExecuteReader situaciones) ExecuteReader
+ DataReader. Read + Conexión. abrir + DataReader. Read
Materialización de + Command. Materialización de
objetos: medio ExecuteReader objetos: medio (más
-Búsqueda de + DataReader. Read rápido que EF5)
identidad: mediana Materialización de -Búsqueda de
objetos: medio identidad: mediana
-Búsqueda de
identidad: mediana
} Conexión. Close Bajo Bajo Bajo
Hay varias maneras de reducir el costo de rendimiento de las consultas en frío y en caliente, y echaremos un
vistazo a ellas en la sección siguiente. En concreto, veremos cómo reducir el costo de la carga de modelos en
consultas frías mediante el uso de vistas generadas previamente, que ayudan a mitigar los problemas de
rendimiento experimentados durante la generación de la vista. En el caso de las consultas cálidas, trataremos el
almacenamiento en caché del plan de consulta, ninguna consulta de seguimiento y opciones de ejecución de
consulta diferentes.
2,1 ¿Qué es la generación de vistas?
Para comprender qué es la generación de vistas, primero debemos comprender qué son las "vistas de asignación".
Las vistas de asignación son representaciones ejecutables de las transformaciones especificadas en la asignación
para cada conjunto de entidades y asociación. Internamente, estas vistas de asignación adoptan la forma de CQTs
(árboles de consulta canónicos). Hay dos tipos de vistas de asignación:
Vistas de consulta: representan la transformación necesaria para pasar del esquema de la base de datos al
modelo conceptual.
Vistas de actualización: representan la transformación necesaria para pasar del modelo conceptual al esquema
de la base de datos.
Tenga en cuenta que el modelo conceptual podría diferir del esquema de la base de datos de varias maneras. Por
ejemplo, se puede usar una sola tabla para almacenar los datos de dos tipos de entidad diferentes. La herencia y
las asignaciones no triviales desempeñan un papel en la complejidad de las vistas de asignación.
El proceso de cálculo de estas vistas en función de la especificación de la asignación es lo que llamamos
generación de vistas. La generación de vistas puede tener lugar dinámicamente cuando se carga un modelo, o en
el momento de la compilación, mediante "vistas generadas previamente". estos últimos se serializan en forma de
Entity SQL instrucciones en un archivo de C# o VB.
Cuando se generan vistas, también se validan. Desde el punto de vista del rendimiento, la gran mayoría del costo
de la generación de vistas es realmente la validación de las vistas, lo que garantiza que las conexiones entre las
entidades tienen sentido y tienen la cardinalidad correcta para todas las operaciones admitidas.
Cuando se ejecuta una consulta en un conjunto de entidades, la consulta se combina con la vista de consulta
correspondiente y el resultado de esta composición se ejecuta a través del compilador del plan para crear la
representación de la consulta que la memoria auxiliar puede entender. Por SQL Server, el resultado final de esta
compilación será una instrucción SELECT de T-SQL. La primera vez que se realiza una actualización en un conjunto
de entidades, la vista de actualización se ejecuta a través de un proceso similar para transformarla en instrucciones
DML para la base de datos de destino.
2,2 factores que afectan al rendimiento de la generación de vistas
El paso rendimiento de la generación de vistas no solo depende del tamaño del modelo, sino también de cómo se
conecta el modelo. Si dos entidades están conectadas a través de una cadena de herencia o una asociación, se dice
que están conectadas. Del mismo modo, si dos tablas están conectadas a través de una clave externa, están
conectadas. A medida que aumenta el número de entidades conectadas y tablas en los esquemas, aumenta el
costo de la generación de la vista.
El algoritmo que usamos para generar y validar vistas es exponencial en el peor de los casos, aunque usamos
algunas optimizaciones para mejorar esto. Los factores más importantes que parecen afectar negativamente al
rendimiento son:
Tamaño del modelo, que hace referencia al número de entidades y la cantidad de asociaciones entre estas
entidades.
Complejidad del modelo, específicamente la herencia que implica un gran número de tipos.
Usar asociaciones independientes, en lugar de asociaciones de clave externa.
En el caso de los modelos pequeños y sencillos, el costo puede ser lo suficientemente pequeño como para no
molestarse en usar vistas generadas previamente. A medida que aumentan el tamaño y la complejidad del modelo,
hay varias opciones disponibles para reducir el costo de la generación y validación de las vistas.
2,3 usar vistas generadas previamente para reducir el tiempo de carga del modelo
Para obtener información detallada sobre cómo usar las vistas generadas previamente en Entity Framework 6,
visite vistas de asignación previamente generadas
2.3.1 vistas previamente generadas mediante el Entity Framework Power Tools Community Edition
Puede usar la edición Community Tools de Entity Framework 6 para generar vistas de los modelos EDMX y Code
First haciendo clic con el botón secundario en el archivo de clase de modelo y usando el menú Entity Framework
para seleccionar "generar vistas". Entity Framework Power Tools Community Edition solo funciona en contextos
derivados de DbContext.
2.3.2 Cómo usar las vistas generadas previamente con un modelo creado por EDMGen
EDMGen es una utilidad que se incluye con .NET y funciona con Entity Framework 4 y 5, pero no con Entity
Framework 6. EDMGen permite generar un archivo de modelo, la capa de objetos y las vistas desde la línea de
comandos. Una de las salidas será un archivo de vistas en el lenguaje que prefiera, VB o C#. Se trata de un archivo
de código que contiene fragmentos de Entity SQL para cada conjunto de entidades. Para habilitar las vistas
generadas previamente, solo tiene que incluir el archivo en el proyecto.
Si realiza modificaciones manualmente en los archivos de esquema para el modelo, tendrá que volver a generar el
archivo de vistas. Para ello, ejecute EDMGen con la marca /Mode: ViewGeneration .
2.3.3 Cómo usar vistas generadas previamente con un archivo EDMX
También puede usar EDMGen para generar vistas para un archivo EDMX: el tema de MSDN al que se hace
referencia anteriormente describe cómo agregar un evento anterior a la compilación para hacer esto, pero esto es
complicado y hay algunos casos en los que no es posible. Generalmente, es más fácil usar una plantilla T4 para
generar las vistas cuando el modelo se encuentra en un archivo edmx.
El blog del equipo de ADO.NET tiene una publicación que describe cómo usar una plantilla T4 para la generación
de vistas (<http://blogs.msdn.com/b/adonet/archive/2008/06/20/how-to-use-a-t4-template-for-view-
generation.aspx>). Esta publicación incluye una plantilla que se puede descargar y agregar al proyecto. La plantilla
se escribió para la primera versión de Entity Framework, por lo que no se garantiza que funcionen con las
versiones más recientes de Entity Framework. Sin embargo, puede descargar un conjunto más actualizado de
plantillas de generación de vistas para Entity Framework 4 y 5from la galería de Visual Studio:
VB.NET: <http://visualstudiogallery.msdn.microsoft.com/118b44f2-1b91-4de2-a584-7a680418941d>
C#: <http://visualstudiogallery.msdn.microsoft.com/ae7730ce-ddab-470f-8456-1b313cd2c44d>
Si usa Entity Framework 6, puede obtener las plantillas T4 de la generación de vistas de la galería de Visual Studio
en <http://visualstudiogallery.msdn.microsoft.com/18a7db90-6705-4d19-9dd1-0a6c23d0751f>.
2,4 reducir el costo de la generación de vistas
El uso de vistas generadas previamente mueve el costo de la generación de vistas de la carga del modelo (tiempo
de ejecución) al tiempo de diseño. Aunque esto mejora el rendimiento de inicio en tiempo de ejecución, todavía
experimentará el problema de la generación de vistas mientras está desarrollando. Hay varios trucos adicionales
que pueden ayudar a reducir el costo de la generación de vistas, tanto en tiempo de compilación como en tiempo
de ejecución.
2.4.1 usar asociaciones de clave externa para reducir el costo de la generación de vistas
Hemos detectado varios casos en los que el cambio de las asociaciones en el modelo de asociaciones
independientes a asociaciones de claves externas mejoró considerablemente el tiempo empleado en la generación
de la vista.
Para demostrar esta mejora, se generaron dos versiones del modelo de Navision mediante EDMGen. Nota: vea el
Apéndice C para obtener una descripción del modelo de Navision. El modelo de Navision es interesante para este
ejercicio debido a su gran cantidad de entidades y relaciones entre ellos.
Se generó una versión de este modelo muy grande con las asociaciones de claves externas y la otra se generó con
asociaciones independientes. A continuación, se agotó el tiempo que se tardó en generar las vistas para cada
modelo. La prueba de Entity Framework 5 usó el método GenerateViews () de la clase EntityViewGenerator para
generar las vistas, mientras que la prueba de Entity Framework 6 usaba el método GenerateViews () de la clase
StorageMappingItemCollection. Esto se debe a la reestructuración del código que se produjo en el código base de
Entity Framework 6.
Con Entity Framework 5, la generación de vistas del modelo con claves externas tardó 65 minutos en un equipo de
laboratorio. Se desconoce cuánto tiempo habría tardado en generar las vistas para el modelo que usaba
asociaciones independientes. Hemos dejado la prueba en ejecución durante un mes antes de que el equipo se
reinicie en nuestro laboratorio para instalar las actualizaciones mensuales.
Con Entity Framework 6, la generación de vistas del modelo con claves externas tardó 28 segundos en el mismo
equipo de laboratorio. La generación de la vista para el modelo que usa asociaciones independientes tardó 58
segundos. Las mejoras realizadas en Entity Framework 6 en el código de generación de vistas significan que
muchos proyectos no necesitarán vistas generadas previamente para obtener tiempos de inicio más rápidos.
Es importante volver a marcar que las vistas que se generan previamente en Entity Framework 4 y 5 se pueden
realizar con EDMGen o con las herramientas avanzadas de Entity Framework. Para Entity Framework la generación
de una vista de 6 puede realizarse mediante el Entity Framework herramientas avanzadas o mediante
programación, tal y como se describe en vistas de asignación previamente generadas.
2 .4 .1 .1 C ó m o u sa r c l a v e s e x t e r n a s e n l u g a r d e a so c i a c i o n e s i n d e p e n d i e n t e s
Cuando se usa EDMGen o el diseñador de entidades en Visual Studio, se obtiene claves externas de forma
predeterminada y solo se usa una marca de la línea de comandos o una casilla para cambiar entre claves externas
e IAs.
Si tiene un modelo de Code First grande, el uso de asociaciones independientes tendrá el mismo efecto en la
generación de la vista. Puede evitar este impacto si incluye propiedades de clave externa en las clases para los
objetos dependientes, aunque algunos desarrolladores considerarán que esto va a contaminar su modelo de
objetos. Puede encontrar más información sobre este tema en <http://blog.oneunicorn.com/2011/12/11/whats-
the-deal-with-mapping-foreign-keys-using-the-entity-framework/>.
A L USA R H A GA ESTO
Entity Designer Después de agregar una asociación entre dos entidades,

asegúrese de que tiene una restricción referencial. Las
restricciones referenciales indican a Entity Framework que
utilicen claves externas en lugar de asociaciones
independientes. Para obtener más detalles, visite
<http://blogs.msdn.com/b/efdesign/archive/2009/03/16/forei
gn-keys-in-the-entity-framework.aspx>.
EDMGen Al usar EDMGen para generar los archivos de la base de

datos, las claves externas se respetan y se agregan al modelo
como tal. Para obtener más información sobre las distintas
opciones expuestas por EDMGen, visite
http://msdn.microsoft.com/library/bb387165.aspx.
Code First Vea la sección "Convención de relación" del tema code First
convenciones para obtener información sobre cómo incluir
propiedades de clave externa en objetos dependientes cuando
se usa Code First.
2.4.2 mover el modelo a un ensamblado independiente

Cuando el modelo se incluya directamente en el proyecto de la aplicación y se generen vistas a través de un evento
anterior a la compilación o de una plantilla T4, se realizará la generación y validación de la vista cada vez que se
vuelva a generar el proyecto, incluso si el modelo no se ha cambiado. Si mueve el modelo a un ensamblado
independiente y hace referencia a él desde el proyecto de la aplicación, puede realizar otros cambios en la
aplicación sin necesidad de volver a compilar el proyecto que contiene el modelo.
Nota: al mover el modelo a ensamblados independientes, recuerde copiar las cadenas de conexión para el modelo
en el archivo de configuración de la aplicación del proyecto de cliente.
2.4.3 deshabilitar la validación de un modelo basado en edmx
Los modelos EDMX se validan en tiempo de compilación, incluso si el modelo no se ha modificado. Si el modelo ya
se ha validado, puede suprimir la validación en tiempo de compilación estableciendo la propiedad "validar al
compilar" en false en la ventana Propiedades. Al cambiar la asignación o el modelo, puede volver a habilitar
temporalmente la validación para comprobar los cambios.
Tenga en cuenta que se han realizado mejoras en el rendimiento del Entity Framework Designer para Entity
Framework 6 y el costo de "validar al compilar" es mucho menor que en versiones anteriores del diseñador.
3 almacenamiento en caché en el Entity Framework
Entity Framework tiene los siguientes formatos de almacenamiento en caché integrados:
1. Almacenamiento en caché de objetos: el ObjectStateManager integrado en una instancia de ObjectContext
realiza un seguimiento de la memoria de los objetos que se han recuperado mediante esa instancia. Esto
también se conoce como caché de primer nivel.
2. Almacenamiento en caché del plan de consulta: reutilizar el comando de almacenamiento generado cuando una
consulta se ejecuta más de una vez.
3. Almacenamiento en caché de metadatos: compartir los metadatos de un modelo entre diferentes conexiones
con el mismo modelo.
Además de las memorias caché que EF proporciona de forma integrada, también se puede usar un tipo especial de
proveedor de datos ADO.NET conocido como proveedor de ajuste para extender Entity Framework con una
memoria caché para los resultados recuperados de la base de datos, también denominado almacenamiento en
caché de segundo nivel.
ca3,1 almacenamiento en caché de objetos
De forma predeterminada, cuando una entidad se devuelve en los resultados de una consulta, justo antes de que
EF lo materializa, el ObjectContext comprobará si ya se ha cargado una entidad con la misma clave en el
ObjectStateManager. Si ya existe una entidad con las mismas claves, EF la incluirá en los resultados de la consulta.
Aunque EF seguirá emitiendo la consulta en la base de datos, este comportamiento puede omitir la mayor parte
del costo de materializar la entidad varias veces.
3.1.1 obtener entidades de la memoria caché de objetos mediante la búsqueda de DbContext
A diferencia de una consulta normal, el método Find de DbSet (las API que se incluyen por primera vez en EF 4,1)
realizará una búsqueda en la memoria antes de emitir la consulta en la base de datos. Es importante tener en
cuenta que dos instancias de ObjectContext diferentes tendrán dos instancias de ObjectStateManager diferentes, lo
que significa que tienen cachés de objetos independientes.
Find usa el valor de la clave principal para intentar buscar una entidad de la que el contexto realiza un seguimiento.
Si la entidad no está en el contexto, se ejecutará y evaluará una consulta en la base de datos y se devolverá null si
no se encuentra la entidad en el contexto o en la base de datos. Tenga en cuenta que la búsqueda también
devuelve las entidades que se han agregado al contexto pero que todavía no se han guardado en la base de datos.
Se debe tener en cuenta el rendimiento al usar la búsqueda. De forma predeterminada, las invocaciones a este
método desencadenarán una validación de la memoria caché de objetos para detectar los cambios que aún están
pendientes de confirmación en la base de datos. Este proceso puede resultar muy caro si hay un gran número de
objetos en la memoria caché de objetos o en un gráfico de objetos grande que se va a agregar a la memoria caché
de objetos, pero también se puede deshabilitar. En algunos casos, es posible que perciba un orden de magnitud de
diferencia en la llamada al método Find cuando se deshabilitan los cambios de detección automática. Todavía se
percibe un segundo orden de magnitud cuando el objeto realmente está en la memoria caché en lugar de cuando
el objeto tiene que recuperarse de la base de datos. A continuación se muestra un gráfico de ejemplo con medidas
tomadas con algunos de nuestros microbenchmarks, expresados en milisegundos, con una carga de 5000
entidades:
Ejemplo de búsqueda con cambios de detección automática deshabilitados:
context.Configuration.AutoDetectChangesEnabled = false;
var product = context.Products.Find(productId);
context.Configuration.AutoDetectChangesEnabled = true;
...
Lo que tiene que tener en cuenta al usar el método Find es:

1. Si el objeto no está en la memoria caché, se niegan las ventajas de la búsqueda, pero la sintaxis es todavía más
sencilla que una consulta por clave.
2. Si la detección automática de cambios está habilitada, el costo del método buscar puede aumentar en un orden
de magnitud, o incluso más en función de la complejidad del modelo y de la cantidad de entidades en la
memoria caché de objetos.
Además, tenga en cuenta que la búsqueda solo devuelve la entidad que está buscando y no carga
automáticamente sus entidades asociadas si aún no están en la memoria caché de objetos. Si necesita recuperar
entidades asociadas, puede usar una consulta por clave con carga diligente. Para obtener más información, vea
carga diferida de 8,1 frente a carga diligente .
3.1.2 problemas de rendimiento cuando la memoria caché de objetos tiene muchas entidades
La memoria caché de objetos ayuda a aumentar la capacidad de respuesta general de Entity Framework. Sin
embargo, cuando la memoria caché de objetos tiene una cantidad muy grande de entidades cargadas, puede
afectar a ciertas operaciones, como agregar, quitar, buscar, entrada, SaveChanges, etc. En concreto, las operaciones
que desencadenan una llamada a DetectChanges se verán afectadas negativamente por las memorias caché de
objetos de gran tamaño. DetectChanges sincroniza el gráfico de objetos con el administrador de estado de objetos
y su rendimiento viene determinado directamente por el tamaño del gráfico de objetos. Para obtener más
información sobre DetectChanges, consulte seguimiento de cambios en entidades poco.
Al usar Entity Framework 6, los desarrolladores pueden llamar a AddRange y RemoveRange directamente en un
DbSet, en lugar de recorrer en iteración una colección y llamar a agregar una vez por instancia. La ventaja de usar
los métodos de intervalo es que el costo de DetectChanges solo se paga una vez para todo el conjunto de
entidades en lugar de una vez por cada entidad agregada.
ca3,2 almacenamiento en caché del plan de consulta
La primera vez que se ejecuta una consulta, pasa por el compilador del plan interno para traducir la consulta
conceptual en el comando de almacenamiento (por ejemplo, el T-SQL que se ejecuta cuando se ejecuta con SQL
Server). Si está habilitado el almacenamiento en caché del plan de consulta, la próxima vez que se ejecute la
consulta, el comando de almacenamiento se recupera directamente de la memoria caché del plan de consulta para
su ejecución, omitiendo el compilador del plan.
La memoria caché del plan de consulta se comparte entre instancias de ObjectContext dentro del mismo
AppDomain. No es necesario mantener en una instancia de ObjectContext para beneficiarse del almacenamiento
en caché del plan de consulta.
3.2.1 algunas notas sobre el almacenamiento en caché del plan de consulta
La memoria caché del plan de consulta se comparte para todos los tipos de consulta: Entity SQL, LINQ to
Entities y objetos CompiledQuery.
De forma predeterminada, el almacenamiento en caché del plan de consulta está habilitado para las consultas
Entity SQL, tanto si se ejecutan a través de EntityCommand como a través de ObjectQuery. También está
habilitada de forma predeterminada para las consultas LINQ to Entities en Entity Framework en .NET 4,5 y en
Entity Framework 6
El almacenamiento en caché del plan de consulta se puede deshabilitar estableciendo la propiedad
EnablePlanCaching (en EntityCommand o ObjectQuery) en false. Por ejemplo:
var query = from customer in context.Customer
where customer.CustomerId == id
select new
{
customer.CustomerId,
customer.Name
};
ObjectQuery oQuery = query as ObjectQuery;
oQuery.EnablePlanCaching = false;
En el caso de las consultas con parámetros, el cambio del valor del parámetro seguirá alcanzando la consulta
almacenada en caché. Pero cambiar las caras de un parámetro (por ejemplo, tamaño, precisión o escala)
alcanzará una entrada diferente en la memoria caché.
Cuando se usa Entity SQL, la cadena de consulta forma parte de la clave. Si se cambia la consulta en todos, se
producirán diferentes entradas de caché, incluso si las consultas son equivalentes funcionalmente. Esto incluye
los cambios en el uso de mayúsculas o minúsculas.
Al utilizar LINQ, la consulta se procesa para generar una parte de la clave. Al cambiar la expresión LINQ, se
generará una clave diferente.
Pueden aplicarse otras limitaciones técnicas; vea consultas compiladas para obtener más información.
3.2.2 algoritmo de expulsión de caché
Comprender cómo funciona el algoritmo interno le ayudará a averiguar cuándo habilitar o deshabilitar el
almacenamiento en caché del plan de consulta. El algoritmo de limpieza es el siguiente:
1. Una vez que la memoria caché contiene un número establecido de entradas (800), se inicia un temporizador
que, periódicamente (una vez por minuto), barre la memoria caché.
2. Durante los barridos de caché, las entradas se quitan de la memoria caché en una base de LFRU (con menos
frecuencia, usada recientemente). Este algoritmo toma en cuenta tanto el número de llamadas como la
antigüedad al decidir qué entradas se expulsan.
3. Al final de cada barrido de caché, la memoria caché contiene 800 entradas.
Todas las entradas de la memoria caché se tratan igualmente al determinar qué entradas se expulsan. Esto significa
que el comando de almacenamiento de una CompiledQuery tiene la misma oportunidad de expulsión que el
comando de almacenamiento de una consulta de Entity SQL.
Tenga en cuenta que el temporizador de expulsión de caché se inicia cuando hay 800 entidades en la caché, pero la
memoria caché solo se explora 60 segundos después de que se inicie este temporizador. Esto significa que hasta
60 segundos la memoria caché puede crecer de forma bastante grande.
3.2.3 métricas de pruebas que muestran el rendimiento del almacenamiento en caché del plan de consulta
Para demostrar el efecto del almacenamiento en caché del plan de consulta en el rendimiento de la aplicación,
hemos realizado una prueba en la que se ha ejecutado un número de consultas Entity SQL en el modelo de
Navision. Vea el apéndice para obtener una descripción del modelo de Navision y los tipos de consultas que se
ejecutaron. En esta prueba, primero se recorre en iteración la lista de consultas y se ejecuta cada una de ellas para
agregarlas a la caché (si está habilitado el almacenamiento en caché). Este paso es inesperado. A continuación, se
suspende el subproceso principal durante más de 60 segundos para permitir que se lleve a cabo el rastreo de la
memoria caché. por último, se recorre en iteración la lista una segunda vez para ejecutar las consultas en caché.
Además, la memoria caché del plan de SQL Server se vacía antes de que se ejecute cada conjunto de consultas, de
modo que las horas que se obtengan con precisión reflejen el beneficio dado por la memoria caché del plan de
consulta.
R e su l t a d o s d e p r u e b a s 3 .2 .3 .1
P RUEB A EF 5 SIN C A C H É EF 5 EN C A C H É EF 6 SIN C A C H É EF 6 EN C A C H É
Enumerar todas las 124 125.4 124.3 125.3

consultas de 18723
Evitar el rastreo (solo 41.7 5.5 40,5 5.4

las primeras 800,
independientemente
de la complejidad)
Solo las consultas de 39,5 4.5. 38.1 4.6

AggregatingSubtotals
(178 en total, lo que
evita el barrido)
Todo el tiempo en segundos.

Moral: cuando se ejecutan muchas consultas distintas (por ejemplo, consultas creadas dinámicamente), el
almacenamiento en caché no ayuda y el vaciado resultante de la memoria caché puede mantener las consultas que
más se beneficiarían del almacenamiento en caché del plan.
Las consultas de AggregatingSubtotals son las consultas más complejas que hemos probado con. Como cabría
esperar, cuanto más compleja sea la consulta, más ventajas verá del almacenamiento en caché del plan de consulta.
Dado que CompiledQuery es realmente una consulta LINQ con su plan almacenado en memoria caché, la
comparación de un CompiledQuery con respecto a la consulta de Entity SQL equivalente debe tener resultados
similares. De hecho, si una aplicación tiene una gran cantidad de consultas de Entity SQL dinámicas, llenar la
memoria caché con consultas también hará que CompiledQueries se "descompile" cuando se vacíen de la
memoria caché. En este escenario, el rendimiento puede mejorar si se deshabilita el almacenamiento en caché en
las consultas dinámicas para priorizar el CompiledQueries. Aún mejor, por supuesto, sería volver a escribir la
aplicación para usar consultas con parámetros en lugar de consultas dinámicas.
3,3 uso de CompiledQuery para mejorar el rendimiento con consultas LINQ
Nuestras pruebas indican que el uso de CompiledQuery puede aportar una ventaja del 7% sobre las consultas
LINQ compiladas. Esto significa que va a pasar el 7% menos tiempo ejecutando el código de la pila de Entity
Framework; no significa que la aplicación vaya a ser del 7% más rápida. Por lo general, el costo de escribir y
mantener los objetos CompiledQuery en EF 5,0 podría no merecer el problema en comparación con las ventajas. El
kilometraje puede variar, por lo que debe ejecutar esta opción si el proyecto requiere la extracción adicional. Tenga
en cuenta que CompiledQueries solo son compatibles con los modelos derivados de ObjectContext y no son
compatibles con los modelos derivados de DbContext.
Para obtener más información sobre cómo crear e invocar un CompiledQuery, vea consultas compiladas (LINQ to
Entities).
Hay dos consideraciones que debe tomar al usar un CompiledQuery, es decir, el requisito de usar instancias
estáticas y los problemas que tienen con composición. A continuación se muestra una explicación detallada de
estas dos consideraciones.
3.3.1 usar instancias de CompiledQuery estáticas
Dado que la compilación de una consulta LINQ es un proceso que requiere mucho tiempo, no queremos hacerlo
cada vez que necesitamos capturar datos de la base de datos. Las instancias de CompiledQuery permiten compilar
una vez y ejecutarse varias veces, pero tiene que tener cuidado y adquirir para volver a usar la misma instancia de
CompiledQuery cada vez en lugar de compilarla una y otra vez. Se necesita el uso de miembros estáticos para
almacenar las instancias de CompiledQuery. en caso contrario, no verá ninguna ventaja.
Por ejemplo, supongamos que la página tiene el cuerpo del método siguiente para controlar la visualización de los
productos de la categoría seleccionada:
// Warning: this is the wrong way of using CompiledQuery
using (NorthwindEntities context = new NorthwindEntities())
{
string selectedCategory = this.categoriesList.SelectedValue;
var productsForCategory = CompiledQuery.Compile<NorthwindEntities, string, IQueryable<Product>>(

(NorthwindEntities nwnd, string category) =>
nwnd.Products.Where(p => p.Category.CategoryName == category)
);
this.productsGrid.DataSource = productsForCategory.Invoke(context, selectedCategory).ToList();

this.productsGrid.DataBind();
}
this.productsGrid.Visible = true;
En este caso, creará una nueva instancia de CompiledQuery sobre la marcha cada vez que se llame al método. En
lugar de ver las ventajas de rendimiento mediante la recuperación del comando de almacenamiento desde la
memoria caché del plan de consulta, el CompiledQuery pasará por el compilador del plan cada vez que se cree una
nueva instancia. De hecho, estará contaminando la memoria caché del plan de consulta con una nueva entrada
CompiledQuery cada vez que se llame al método.
En su lugar, se desea crear una instancia estática de la consulta compilada, por lo que se invoca la misma consulta
compilada cada vez que se llama al método. Una manera de hacerlo es agregar la instancia de CompiledQuery
como un miembro del contexto del objeto. A continuación, puede hacer cosas un poco limpiador accediendo a
CompiledQuery a través de un método auxiliar:
public partial class NorthwindEntities : ObjectContext

{
private static readonly Func<NorthwindEntities, string, IEnumerable<Product>> productsForCategoryCQ =
CompiledQuery.Compile(
(NorthwindEntities context, string categoryName) =>
context.Products.Where(p => p.Category.CategoryName == categoryName)
);
public IEnumerable<Product> GetProductsForCategory(string categoryName)

{
return productsForCategoryCQ.Invoke(this, categoryName).ToList();
}
Este método auxiliar se invocaría de la siguiente manera:
this.productsGrid.DataSource = context.GetProductsForCategory(selectedCategory);
3.3.2 redacción sobre un CompiledQuery

La capacidad de componer sobre cualquier consulta LINQ es muy útil; para ello, basta con invocar un método
después de IQueryable, como SKIP () o Count () . Sin embargo, si lo hace, se devuelve un nuevo objeto IQueryable.
Aunque no hay nada que se detenga técnicamente de la composición en un CompiledQuery, si lo hace, se
producirá la generación de un nuevo objeto IQueryable que requiera pasar de nuevo el compilador del plan.
Algunos componentes harán uso de objetos IQueryable compuestos para habilitar la funcionalidad avanzada. Por
ejemplo, ASP. GridView de la red se puede enlazar a datos a un objeto IQueryable a través de la propiedad
SelectMethod. A continuación, GridView se compondrá sobre este objeto IQueryable para permitir la ordenación y
la paginación en el modelo de datos. Como puede ver, el uso de un CompiledQuery para GridView no alcanzaría la
consulta compilada pero generaría una nueva consulta compilada.
Un lugar en el que pueda encontrarse es al agregar filtros progresivos a una consulta. Por ejemplo, supongamos
que tiene una página clientes con varias listas desplegables para filtros opcionales (por ejemplo, Country y
OrdersCount). Puede crear estos filtros a través de los resultados de IQueryable de un CompiledQuery, pero si lo
hace, la nueva consulta pasará a través del compilador del plan cada vez que la ejecute.

{
IQueryable<Customer> myCustomers = context.InvokeCustomersForEmployee();
if (this.orderCountFilterList.SelectedItem.Value != defaultFilterText)
{
int orderCount = int.Parse(orderCountFilterList.SelectedValue);
myCustomers = myCustomers.Where(c => c.Orders.Count > orderCount);
}
if (this.countryFilterList.SelectedItem.Value != defaultFilterText)
{
myCustomers = myCustomers.Where(c => c.Address.Country == countryFilterList.SelectedValue);
}
this.customersGrid.DataSource = myCustomers;
this.customersGrid.DataBind();
}
Para evitar esta recompilación, puede volver a escribir CompiledQuery para tener en cuenta los posibles filtros:
private static readonly Func<NorthwindEntities, int, int?, string, IQueryable<Customer>>

customersForEmployeeWithFiltersCQ = CompiledQuery.Compile(
(NorthwindEntities context, int empId, int? countFilter, string countryFilter) =>
context.Customers.Where(c => c.Orders.Any(o => o.EmployeeID == empId))
.Where(c => countFilter.HasValue == false || c.Orders.Count > countFilter)
.Where(c => countryFilter == null || c.Address.Country == countryFilter)
);
Que se invocaría en la interfaz de usuario como:

{
int? countFilter = (this.orderCountFilterList.SelectedIndex == 0) ?
(int?)null :
int.Parse(this.orderCountFilterList.SelectedValue);
string countryFilter = (this.countryFilterList.SelectedIndex == 0) ?

null :
this.countryFilterList.SelectedValue;
IQueryable<Customer> myCustomers = context.InvokeCustomersForEmployeeWithFilters(

countFilter, countryFilter);
this.customersGrid.DataSource = myCustomers;
this.customersGrid.DataBind();
}
Un inconveniente aquí es que el comando de almacenamiento generado siempre tendrá los filtros con las
comprobaciones de valores NULL, pero deben ser bastante simples para que el servidor de base de datos pueda
optimizar:
...
WHERE ((0 = (CASE WHEN (@p__linq__1 IS NOT NULL) THEN cast(1 as bit) WHEN (@p__linq__1 IS NULL) THEN cast(0 as
bit) END)) OR ([Project3].[C2] > @p__linq__2)) AND (@p__linq__3 IS NULL OR [Project3].[Country] = @p__linq__4)
3,4 almacenamiento en caché de metadatos

La Entity Framework también admite el almacenamiento en caché de metadatos. Esencialmente, se almacena en
caché la información de tipo y la información de asignación de tipo a base de datos en distintas conexiones al
mismo modelo. La caché de metadatos es única por AppDomain.
algoritmo de almacenamiento en caché de metadatos de 3.4.1
1. La información de metadatos de un modelo se almacena en ItemCollection para cada EntityConnection.
Como nota lateral, hay diferentes objetos ItemCollection para diferentes partes del modelo. Por ejemplo,
StoreItemCollections contiene la información acerca del modelo de base de datos; ObjectItemCollection
contiene información sobre el modelo de datos. EdmItemCollection contiene información sobre el
modelo conceptual.
2. Si dos conexiones utilizan la misma cadena de conexión, compartirán la misma instancia de ItemCollection.
3. Funcionalmente equivalente, pero las cadenas de conexión textualmente diferentes pueden dar lugar a
diferentes cachés de metadatos. Vamos a acortar las cadenas de conexión, por lo que cambiar el orden de
los tokens debe generar metadatos compartidos. Pero dos cadenas de conexión que parecen
funcionalmente iguales no se pueden evaluar como idénticas después de la tokenización.
4. La ItemCollection se comprueba periódicamente para su uso. Si se determina que no se ha tenido acceso
recientemente a un área de trabajo, se marcará para su limpieza en el siguiente barrido de caché.
5. Simplemente la creación de EntityConnection hará que se cree una memoria caché de metadatos (aunque
las colecciones de elementos que contengan no se inicializarán hasta que se abra la conexión). Esta área de
trabajo permanecerá en memoria hasta que el algoritmo de almacenamiento en caché determine que no
está en uso.
El equipo de asesoramiento al cliente ha escrito una entrada de blog que describe la conservación de una
referencia a un ItemCollection para evitar la "degradación" al utilizar modelos grandes:
<http://blogs.msdn.com/b/appfabriccat/archive/2010/10/22/metadataworkspace-reference-in-wcf-services.aspx>.
3.4.2 la relación entre almacenamiento en caché de metadatos y almacenamiento en caché del plan de consulta
La instancia de la memoria caché del plan de consulta reside en el ItemCollection de los tipos de almacén de
MetadataWorkspace. Esto significa que los comandos de almacenamiento almacenados en caché se usarán para
las consultas en cualquier contexto del que se haya creado una instancia con un MetadataWorkspace determinado.
También significa que si tiene dos cadenas de conexión que son ligeramente diferentes y no coinciden después de
la tokenización, tendrá instancias de la memoria caché del plan de consulta diferente.
Caching de resultados de 3,5
Con el almacenamiento en caché de resultados (también conocido como "almacenamiento en caché de segundo
nivel"), se conservan los resultados de las consultas en una caché local. Al emitir una consulta, primero verá si los
resultados están disponibles localmente antes de realizar la consulta en el almacén. Aunque el almacenamiento en
caché de resultados no es compatible directamente con Entity Framework, es posible agregar una memoria caché
de segundo nivel mediante un proveedor de ajuste. Un proveedor de ajuste de ejemplo con una memoria caché de
segundo nivel es la Entity Framework de la memoria caché de segundo nivel basada en NCache.
Esta implementación del almacenamiento en caché de segundo nivel es una funcionalidad insertada que tiene
lugar después de evaluar la expresión LINQ (y funcletized) y de que el plan de ejecución de consulta se calcula o
recupera de la caché de primer nivel. La memoria caché de segundo nivel solo almacenará los resultados de la
base de datos sin formato, por lo que la canalización de materialización se seguirá ejecutando después.
3.5.1 referencias adicionales para el almacenamiento en caché de resultados con el proveedor de ajuste
Julia Lerman ha escrito un artículo de MSDN "almacenamiento en caché de segundo nivel en Entity Framework
y Windows Azure" que incluye cómo actualizar el proveedor de empaquetado de ejemplo para usar el
almacenamiento en caché de Windows Server AppFabric:
https://msdn.microsoft.com/magazine/hh394143.aspx
Si está trabajando con Entity Framework 5, el blog del equipo tiene una publicación en la que se describe cómo
hacer todo lo que se ejecuta con el proveedor de almacenamiento en caché para Entity Framework 5:
<http://blogs.msdn.com/b/adonet/archive/2010/09/13/ef-caching-with-jarek-kowalski-s-provider.aspx>.
También incluye una plantilla T4 para ayudar a automatizar la adición del almacenamiento en caché de segundo
nivel al proyecto.
4 consultas compiladas
Cuando se emite una consulta en una base de datos mediante Entity Framework, debe pasar por una serie de
pasos antes de materializar los resultados. uno de estos pasos es la compilación de consultas. Entity SQL se sabe
que las consultas tienen un buen rendimiento, ya que se almacenan en caché automáticamente, por lo que la
segunda o tercera vez que se ejecuta la misma consulta puede omitir el compilador del plan y usar el plan
almacenado en caché en su lugar.
Entity Framework 5 presentó también el almacenamiento en caché automático para las consultas de LINQ to
Entities. En las ediciones anteriores de Entity Framework crear un CompiledQuery para acelerar el rendimiento era
una práctica común, ya que esto haría que su LINQ to Entities consulta se pudiera almacenar en caché. Dado que el
almacenamiento en caché se realiza ahora automáticamente sin el uso de un CompiledQuery, se llama a esta
característica "autocompiled queries". Para obtener más información acerca de la memoria caché del plan de
consulta y su mecánica, vea almacenamiento en caché del plan de consulta.
Entity Framework detecta cuándo es necesario volver a compilar una consulta y lo hace cuando se invoca la
consulta incluso si se había compilado antes. Las condiciones comunes que hacen que la consulta se vuelva a
compilar son:
Cambio de MergeOption asociado a la consulta. No se usará la consulta almacenada en caché, sino que el
compilador del plan se ejecutará de nuevo y el plan recién creado se almacenará en caché.
Cambiar el valor de ContextOptions. UseCSharpNullComparisonBehavior. Tiene el mismo efecto que cambiar
MergeOption.
Otras condiciones pueden impedir que la consulta use la memoria caché. Los ejemplos comunes son:
Usar IEnumerable<T>. Contiene<>(valor T).
Usar funciones que generan consultas con constantes.
Usar las propiedades de un objeto no asignado.
Vincular la consulta a otra consulta que requiere que se vuelva a compilar.
4,1 usar IEnumerable<T>. Contiene<T>(valor T )
Entity Framework no almacena en caché las consultas que invocan a IEnumerable<T>. Contiene<T>(valor T) en
una colección en memoria, ya que los valores de la colección se consideran volátiles. La consulta de ejemplo
siguiente no se almacenará en caché, por lo que el compilador del plan siempre la procesará:
int[] ids = new int[10000];

...
using (var context = new MyContext())
{
var query = context.MyEntities
.Where(entity => ids.Contains(entity.Id));
var results = query.ToList();

...
}
Tenga en cuenta que el tamaño de IEnumerable en el que se ejecuta se determina la rapidez o la velocidad de
compilación de la consulta. El rendimiento puede verse afectado de forma significativa al usar colecciones grandes
como la que se muestra en el ejemplo anterior.
Entity Framework 6 contiene optimizaciones para la manera en que se>IEnumerable<T. Contiene<T>(valor T)
funciona cuando se ejecutan las consultas. El código SQL que se genera es mucho más rápido para generar y más
legible y, en la mayoría de los casos, también se ejecuta más rápido en el servidor.
4,2 usar funciones que generan consultas con constantes
Los operadores LINQ SKIP (), Take (), Contains () y DefautIfEmpty () no generan consultas SQL con parámetros sino
que, en su lugar, colocan los valores que se les pasan como constantes. Por este motivo, las consultas que, de otro
modo, podrían ser idénticas en la memoria caché del plan de consulta, tanto en la pila de EF como en el servidor
de base de datos, y no se reutilizarán a menos que se usen las mismas constantes en una ejecución de consulta
posterior. Por ejemplo:
var id = 10;
...
{
var query = context.MyEntities.Select(entity => entity.Id).Contains(id);

...
}
En este ejemplo, cada vez que se ejecuta esta consulta con un valor diferente para el identificador, la consulta se
compilará en un nuevo plan.
En concreto, preste atención al uso de SKIP y Take al realizar la paginación. En EF6, estos métodos tienen una
sobrecarga lambda que hace que el plan de consulta almacenado en caché se vuelva a usar porque EF puede
capturar las variables que se pasan a estos métodos y traducirlas a SQLparameters. Esto también ayuda a
mantener el limpiador de la memoria caché, ya que, de lo contrario, cada consulta con una constante diferente
para Skip y Take obtendría su propia entrada de caché del plan de consulta.
Considere el siguiente código, que es poco óptimo, pero solo está pensado para ejemplificar esta clase de
consultas:
var customers = context.Customers.OrderBy(c => c.LastName);

for (var i = 0; i < count; ++i)
{
var currentCustomer = customers.Skip(i).FirstOrDefault();
ProcessCustomer(currentCustomer);
}
Una versión más rápida de este mismo código implicaría llamar a SKIP con una expresión lambda:
var customers = context.Customers.OrderBy(c => c.LastName);

for (var i = 0; i < count; ++i)
{
var currentCustomer = customers.Skip(() => i).FirstOrDefault();
}
El segundo fragmento de código puede ejecutarse hasta un 11% más rápido, ya que se usa el mismo plan de
consulta cada vez que se ejecuta la consulta, lo que ahorra tiempo de CPU y evita contaminar la caché de consultas.
Además, dado que el parámetro que se va a omitir está en un cierre, el código también tendrá el siguiente aspecto:
var i = 0;
var skippyCustomers = context.Customers.OrderBy(c => c.LastName).Skip(() => i);
for (; i < count; ++i)
{
var currentCustomer = skippyCustomers.FirstOrDefault();
}
4,3 uso de las propiedades de un objeto no asignado

Cuando una consulta usa las propiedades de un tipo de objeto no asignado como parámetro, la consulta no se
almacenará en caché. Por ejemplo:

{
var myObject = new NonMappedType();
var query = from entity in context.MyEntities

where entity.Name.StartsWith(myObject.MyProperty)
select entity;

...
}
En este ejemplo, supongamos que la clase NonMappedType no forma parte del modelo de entidad. Esta consulta
se puede cambiar fácilmente para que no use un tipo no asignado y, en su lugar, use una variable local como
parámetro para la consulta:

{
var myObject = new NonMappedType();
var myValue = myObject.MyProperty;
var query = from entity in context.MyEntities
where entity.Name.StartsWith(myValue)
select entity;

...
}
En este caso, la consulta se podrá almacenar en caché y se beneficiará de la caché del plan de consulta.
4,4 vincular a consultas que requieren volver a compilar
Siguiendo el mismo ejemplo anterior, si tiene una segunda consulta que se basa en una consulta que se debe
volver a compilar, también se volverá a compilar toda la segunda consulta. Este es un ejemplo para ilustrar este
escenario:
int[] ids = new int[10000];
...
{
var firstQuery = from entity in context.MyEntities
where ids.Contains(entity.Id)
select entity;
var secondQuery = from entity in context.MyEntities

where firstQuery.Any(otherEntity => otherEntity.Id == entity.Id)
select entity;
var results = secondQuery.ToList();

...
}
El ejemplo es genérico, pero muestra cómo la vinculación a firstQuery hace que secondQuery no pueda
almacenarse en caché. Si firstQuery no hubiera sido una consulta que requiera volver a compilar, entonces
secondQuery se habría almacenado en caché.
5 realizar un seguimiento de las consultas

5,1 deshabilitar el seguimiento de cambios para reducir la sobrecarga de administración de estado
Si está en un escenario de solo lectura y desea evitar la sobrecarga que supone cargar los objetos en el
ObjectStateManager, puede emitir consultas "sin seguimiento". El seguimiento de cambios se puede deshabilitar
en el nivel de consulta.
Tenga en cuenta que, si deshabilita el seguimiento de cambios, se desactivará la caché de objetos. Al consultar una
entidad, no se puede omitir la materialización mediante la extracción de los resultados de la consulta
materializados previamente del ObjectStateManager. Si consulta repetidamente las mismas entidades en el mismo
contexto, es posible que realmente vea una ventaja de rendimiento al habilitar el seguimiento de cambios.
Cuando se realiza una consulta con ObjectContext, las instancias de ObjectQuery y ObjectSet recordarán una
MergeOption una vez que se haya establecido y las consultas que se componen en ellas heredarán la MergeOption
en vigor de la consulta primaria. Al usar DbContext, el seguimiento se puede deshabilitar llamando al modificador
AsNoTracking () en DbSet.
5.1.1 deshabilitar el seguimiento de cambios para una consulta al usar DbContext
Puede cambiar el modo de una consulta a NoTracking mediante el encadenamiento de una llamada al método
AsNoTracking () en la consulta. A diferencia de ObjectQuery, las clases DbSet y DbQuery de la API DbContext no
tienen una propiedad mutable para MergeOption.
var productsForCategory = from p in context.Products.AsNoTracking()

where p.Category.CategoryName == selectedCategory
select p;
5.1.2 deshabilitar el seguimiento de cambios en el nivel de consulta mediante ObjectContext
var productsForCategory = from p in context.Products

select p;
((ObjectQuery)productsForCategory).MergeOption = MergeOption.NoTracking;
5.1.3 deshabilitar el seguimiento de cambios para un conjunto de entidades completo mediante ObjectContext
context.Products.MergeOption = MergeOption.NoTracking;
var productsForCategory = from p in context.Products

select p;
5,2 métricas de prueba que muestran las ventajas de rendimiento de las consultas NoTracking
En esta prueba, veremos el costo de rellenar el ObjectStateManager comparando el seguimiento con NoTracking
queries for the Navision Model. Vea el apéndice para obtener una descripción del modelo de Navision y los tipos
de consultas que se ejecutaron. En esta prueba, se recorre en iteración la lista de consultas y se ejecuta cada una de
ellas. Se han ejecutado dos variaciones de la prueba, una vez con NoTracking Queries y una con la opción de fusión
mediante combinación predeterminada de "AppendOnly". Se ejecutó cada variación 3 veces y se toma el valor
medio de las ejecuciones. Entre las pruebas se borra la memoria caché de consultas en el SQL Server y se reduce la
tempdb mediante la ejecución de los siguientes comandos:
1. DBCC DROPCLEANBUFFERS
2. DBCC FREEPROCCACHE
3. DBCC SHRINKDATABASE (tempdb, 0)
Resultados de pruebas, la mediana en 3 ejecuciones:
SIN SEGUIM IEN TO : SIN SEGUIM IEN TO : SO LO A N EXA R:

ESPA C IO DE T RA B A JO T IEM P O ESPA C IO DE T RA B A JO SO LO A N EXA R: H O RA
Entity Framework 460361728 1163536 MS 596545536 1273042 MS

5
Entity Framework 647127040 190228 ms 832798720 195521 MS

6
Entity Framework 5 tendrá una superficie de memoria menor al final de la ejecución que Entity Framework 6. La
memoria adicional consumida por Entity Framework 6 es el resultado de estructuras de memoria y código
adicionales que permiten nuevas características y un mejor rendimiento.
También hay una diferencia clara en la superficie de memoria cuando se usa ObjectStateManager. Entity
Framework 5 aumentó su superficie en un 30% al realizar un seguimiento de todas las entidades que
materializamos en la base de datos. Entity Framework 6 aumentó su superficie en un 28% al hacerlo.
En términos de tiempo, Entity Framework 6 supera Entity Framework 5 en esta prueba por un margen grande.
Entity Framework 6 completó la prueba en aproximadamente el 16% del tiempo consumido por Entity Framework
5. Además, Entity Framework 5 tarda un 9% más en completarse cuando se usa ObjectStateManager. En
comparación, Entity Framework 6 utiliza el 3% más de tiempo al usar el ObjectStateManager.
6 opciones de ejecución de consultas

Entity Framework ofrece varias maneras de consultar. Echaremos un vistazo a las siguientes opciones,
compararemos las ventajas y desventajas de cada una de ellas y examinaremos sus características de rendimiento:
LINQ to Entities.
Ningún LINQ to Entities de seguimiento.
Entity SQL en una ObjectQuery.
Entity SQL sobre un EntityCommand.
ExecuteStoreQuery.
SqlQuery.
CompiledQuery.
6,1 consultas LINQ to Entities
var q = context.Products.Where(p => p.Category.CategoryName == "Beverages");
Ventajas
Adecuado para las operaciones CUD.
Objetos completamente materializados.
Más sencillo de escribir con la sintaxis integrada en el lenguaje de programación.
Buen rendimiento.
Desventajas
Ciertas restricciones técnicas, como:
Los patrones que usan DefaultIfEmpty para consultas de combinación externas dan como resultado
consultas más complejas que las instrucciones de combinación externa simples en Entity SQL.
Todavía no se puede usar como con la coincidencia de patrones general.
6,2 ninguna consulta de LINQ to Entities de seguimiento
Cuando el contexto deriva a ObjectContext:
Cuando el contexto derive DbContext:
var q = context.Products.AsNoTracking()
.Where(p => p.Category.CategoryName == "Beverages");
Ventajas
Rendimiento mejorado con respecto a las consultas LINQ normales.
Más sencillo de escribir con la sintaxis integrada en el lenguaje de programación.
Desventajas
No es adecuado para las operaciones de CUD.
Ciertas restricciones técnicas, como:
Los patrones que usan DefaultIfEmpty para consultas de combinación externas dan como resultado
consultas más complejas que las instrucciones de combinación externa simples en Entity SQL.
Todavía no se puede usar como con la coincidencia de patrones general.
Tenga en cuenta que no se realiza el seguimiento de las consultas de las propiedades escalares del proyecto,
aunque no se especifique el NoTracking. Por ejemplo:
var q = context.Products.Where(p => p.Category.CategoryName == "Beverages").Select(p => new { p.ProductName

});
Esta consulta en particular no especifica explícitamente que sea NoTracking, pero como no materializa un tipo
conocido por el administrador de estado de objeto, no se realiza el seguimiento del resultado materializado.
6,3 Entity SQL en una ObjectQuery
ObjectQuery<Product> products = context.Products.Where("it.Category.CategoryName = 'Beverages'");
Ventajas
Admite el almacenamiento en caché del plan de consulta.
Desventajas
Incluye cadenas de consulta textual que son más propensas a errores del usuario que las construcciones de
consulta integradas en el lenguaje.
6,4 Entity SQL sobre un comando de entidad
EntityCommand cmd = eConn.CreateCommand();

cmd.CommandText = "Select p From NorthwindEntities.Products As p Where p.Category.CategoryName = 'Beverages'";
using (EntityDataReader reader = cmd.ExecuteReader(CommandBehavior.SequentialAccess))

{
while (reader.Read())
{
// manually 'materialize' the product
}
}
Ventajas
Admite el almacenamiento en caché del plan de consulta en .NET 4,0 (el almacenamiento en caché del plan es
compatible con todos los demás tipos de consulta en .NET 4,5).
Desventajas
Incluye cadenas de consulta textual que son más propensas a errores del usuario que las construcciones de
consulta integradas en el lenguaje.
No es adecuado para las operaciones de CUD.
Los resultados no se materializan automáticamente y deben leerse desde el lector de datos.
6,5 SqlQuery y ExecuteStoreQuery
SqlQuery en la base de datos:
// use this to obtain entities and not track them

var q1 = context.Database.SqlQuery<Product>("select * from products");
SqlQuery en DbSet:
// use this to obtain entities and have them tracked

var q2 = context.Products.SqlQuery("select * from products");
ExecyteStoreQuery:
var beverages = context.ExecuteStoreQuery<Product>(
@" SELECT P.ProductID, P.ProductName, P.SupplierID, P.CategoryID, P.QuantityPerUnit, P.UnitPrice,
P.UnitsInStock, P.UnitsOnOrder, P.ReorderLevel, P.Discontinued, P.DiscontinuedDate
FROM Products AS P INNER JOIN Categories AS C ON P.CategoryID = C.CategoryID
WHERE (C.CategoryName = 'Beverages')"
);
Ventajas
Rendimiento generalmente más rápido, ya que se omite el compilador del plan.
Adecuado para las operaciones de CUD cuando se usa desde DbSet.
Desventajas
La consulta es de texto y propenso a errores.
La consulta está asociada a un back-end específico mediante la semántica del almacén en lugar de la semántica
conceptual.
Cuando la herencia está presente, la consulta handcrafted debe tener en cuenta las condiciones de asignación
para el tipo solicitado.
6,6 CompiledQuery
private static readonly Func<NorthwindEntities, string, IQueryable<Product>> productsForCategoryCQ =

);
…
var q = context.InvokeProductsForCategoryCQ("Beverages");
Ventajas
Proporciona una mejora del rendimiento del 7% sobre las consultas LINQ normales.
Desventajas
Mayor complejidad y sobrecarga de programación.
La mejora del rendimiento se pierde cuando se compone de una consulta compilada.
Algunas consultas LINQ no se pueden escribir como CompiledQuery, por ejemplo, proyecciones de tipos
anónimos.
6,7 comparación de rendimiento de diferentes opciones de consulta
Los microbenchmarks simples en los que no se ha agotado el tiempo de creación del contexto se han puesto en la
prueba. Se ha medido la consulta de 5000 veces para un conjunto de entidades sin almacenamiento en caché en
un entorno controlado. Estos números se deben realizar con una advertencia: no reflejan los números reales
generados por una aplicación, sino que son una medición muy precisa de la cantidad de una diferencia de
rendimiento que se produce cuando se comparan diferentes opciones de consulta. manzanas a manzanas, excepto
el costo de crear un nuevo contexto.
EF P RUEB A T IEM P O ( M S) M EM O RIA
EF5 ObjectContext (ESQL) 2414 38801408

EF5 Consulta de ObjectContext 2692 38277120

para LINQ
EF5 No seguimiento de consulta 2818 41840640

LINQ de DbContext
EF5 Consulta LINQ de 2930 41771008

DbContext
EF5 No seguimiento de 3013 38412288

consultas LINQ de
ObjectContext
EF6 ObjectContext (ESQL) 2059 46039040

para LINQ

LINQ de DbContext

DbContext

consultas LINQ de
ObjectContext
Los microbenchmarks son muy sensibles a los pequeños cambios en el código. En este caso, la diferencia entre los
costos de Entity Framework 5 y Entity Framework 6 se debe a la adición de mejoras de interceptación y
transaccional. Sin embargo, estos números de microbenchmarks son una visión amplificada en un fragmento muy
pequeño de lo que hace Entity Framework. Los escenarios reales de consultas cálidas no deben ver una regresión
del rendimiento al actualizar desde Entity Framework 5 a Entity Framework 6.
Para comparar el rendimiento real de las distintas opciones de consulta, hemos creado 5 variaciones de pruebas
independientes en las que usamos una opción de consulta diferente para seleccionar todos los productos cuyo
nombre de categoría sea "bebidas". Cada iteración incluye el costo de crear el contexto y el costo de materializar
todas las entidades devueltas. 10 iteraciones se ejecutan de vez en cuando, antes de tomar la suma de 1000
iteraciones con tiempo. Los resultados que se muestran son el promedio de ejecución de 5 ejecuciones de cada
prueba. Para obtener más información, vea el Apéndice B, que incluye el código de la prueba.
EF5 ObjectContext (comando de 621 39350272

entidad)
EF5 Consulta SQL DbContext en 825 37519360

la base de datos
EF5 Consulta del almacén de 878 39460864

ObjectContext

consultas LINQ de
ObjectContext
EF5 ObjectContext Entity SQL 1089 38981632

mediante consulta de objeto
EF5 Consulta compilada de 1099 38682624

ObjectContext

para LINQ

LINQ de DbContext

DbSet

DbContext
EF6 ObjectContext (comando de 480 47247360

entidad)
EF6 Consulta del almacén de 493 46739456

ObjectContext

la base de datos

consultas LINQ de
ObjectContext
EF6 ObjectContext Entity SQL 767 48865280

mediante consulta de objeto
EF6 Consulta compilada de 788 48467968

ObjectContext

LINQ de DbContext

para LINQ

DbSet

DbContext
NOTE
Por integridad, se incluye una variación en la que se ejecuta una consulta de Entity SQL en un EntityCommand. Sin embargo,
dado que los resultados no se materializan para estas consultas, la comparación no es necesariamente de manzanas a
manzanas. La prueba incluye una aproximación aproximada a la materialización para intentar hacer la comparación más justa.
En este caso de un extremo a otro, Entity Framework 6 supera Entity Framework 5 debido a las mejoras de
rendimiento realizadas en varias partes de la pila, lo que incluye una inicialización de DbContext mucho más clara
y más rápido MetadataCollection<T> búsquedas.
7 consideraciones de rendimiento en tiempo de diseño

7,1 estrategias de herencia
Otra consideración de rendimiento al usar Entity Framework es la estrategia de herencia que se usa. Entity
Framework admite 3 tipos básicos de herencia y sus combinaciones:
Tabla por jerarquía (TPH): donde cada conjunto de herencia se asigna a una tabla con una columna
discriminadora para indicar qué tipo determinado de la jerarquía se representa en la fila.
Tabla por tipo (TPT): cada tipo tiene su propia tabla en la base de datos; las tablas secundarias solo definen las
columnas que no contiene la tabla primaria.
Tabla por clase (TPC): cada tipo tiene su propia tabla completa en la base de datos; las tablas secundarias
definen todos sus campos, incluidos los definidos en tipos primarios.
Si el modelo utiliza la herencia de TPT, las consultas que se generan serán más complejas que las que se generan
con las otras estrategias de herencia, lo que puede dar lugar a tiempos de ejecución más largos en el almacén. Por
lo general, se tarda más tiempo en generar consultas en un modelo TPT y materializar los objetos resultantes.
Vea la herencia "consideraciones de rendimiento al usar TPT (tabla por tipo)" en la Entity Framework "entrada del
blog de MSDN: <http://blogs.msdn.com/b/adonet/archive/2010/08/17/performance-considerations-when-using-
tpt-table-per-type-inheritance-in-the-entity-framework.aspx>.
7.1.1 evitar la aplicación de la Model First o Code First aplicaciones
Al crear un modelo sobre una base de datos existente que tiene un esquema TPT, no tiene muchas opciones. Pero
al crear una aplicación mediante Model First o Code First, debe evitar la herencia de TPT por cuestiones de
rendimiento.
Al usar Model First en el Asistente de Entity Designer, obtendrá el TPT para cualquier herencia del modelo. Si desea
cambiar a una estrategia de herencia de TPH con Model First, puede usar "Entity Designer Database Generation
Power Pack" disponible en la galería de Visual Studio (<http://visualstudiogallery.msdn.microsoft.com/df3541c3-
d833-4b65-b942-989e7ec74c87/>).
Cuando se usa Code First para configurar la asignación de un modelo con herencia, EF usará TPH de forma
predeterminada, por lo que todas las entidades de la jerarquía de herencia se asignarán a la misma tabla. Consulte
la sección "asignación con la API fluida" del artículo "Code First en Entity Framework 4.1" en MSDN Magazine (
http://msdn.microsoft.com/magazine/hh126815.aspx) para obtener más detalles.
7,2 actualización de EF4 para mejorar el tiempo de generación de modelos
En Entity Framework 5 y 6 se encuentra disponible una mejora específica del SQL Server para el algoritmo que
genera el nivel de almacenamiento (SSDL), y como una actualización de Entity Framework 4 cuando está instalado
Visual Studio 2010 SP1. Los resultados de pruebas siguientes muestran la mejora al generar un modelo muy
grande, en este caso el modelo de Navision. Consulte el Apéndice C para obtener más detalles sobre él.
El modelo contiene 1005 conjuntos de entidades y conjuntos de asociaciones de 4227.
C O N F IGURA C IÓ N DESGLO SE DEL T IEM P O C O N SUM IDO
Visual Studio 2010, Entity Framework 4 Generación de SSDL: 2 h 27 min

Generación de asignaciones: 1 segundo
Generación de CSDL: 1 segundo
Generación de ObjectLayer: 1 segundo
Generación de vista: 2 h 14 min
Visual Studio 2010 SP1, Entity Framework 4 Generación de SSDL: 1 segundo

Generación de vista: 1 h 53 min
Visual Studio 2013, Entity Framework 5 Generación de SSDL: 1 segundo

Generación de vistas: 65 minutos
Visual Studio 2013, Entity Framework 6 Generación de SSDL: 1 segundo

Generación de vista: 28 segundos.
Merece la pena tener en cuenta que cuando se genera el SSDL, la carga se emplea casi por completo en el SQL
Server, mientras que el equipo de desarrollo de cliente está esperando la inactividad de los resultados para volver
del servidor. Los DBA deben apreciar especialmente esta mejora. También merece la pena tener en cuenta que
básicamente el costo completo de la generación del modelo tiene lugar en la generación de la vista ahora.
7,3 dividir modelos grandes con Database First y Model First
A medida que aumenta el tamaño del modelo, la superficie del diseñador se vuelve abarrotada y difícil de usar.
Normalmente consideramos que un modelo con más de 300 entidades es demasiado grande para usar
eficazmente el diseñador. En la siguiente entrada de blog se describen varias opciones para dividir modelos
grandes: <http://blogs.msdn.com/b/adonet/archive/2008/11/25/working-with-large-models-in-entity-framework-
part-2.aspx>.
La publicación se escribió para la primera versión de Entity Framework, pero los pasos se siguen aplicando.
7,4 consideraciones de rendimiento con el control de origen de datos de entidad
Hemos visto casos en pruebas de rendimiento y esfuerzo multiproceso en las que el rendimiento de una aplicación
web que usa el control EntityDataSource se deteriora significativamente. La causa subyacente es que
EntityDataSource llama repetidamente a MetadataWorkspace. LoadFromAssembly en los ensamblados a los que
hace referencia la aplicación web para detectar los tipos que se van a usar como entidades.
La solución consiste en establecer el valor de ContextTypeName de EntityDataSource en el nombre de tipo de la
clase derivada de ObjectContext. Esto desactiva el mecanismo que examina todos los ensamblados a los que se
hace referencia para los tipos de entidad.
Al establecer el campo ContextTypeName también se evita un problema funcional en el que EntityDataSource en
.NET 4,0 produce una excepción ReflectionTypeLoadException cuando no puede cargar un tipo de un ensamblado a
través de la reflexión. Este problema se ha corregido en .NET 4,5.
7,5 entidades POCO y servidores proxy de seguimiento de cambios
Entity Framework le permite utilizar clases de datos personalizadas junto con su modelo de datos sin realizar
ninguna modificación en las clases de datos. Esto significa que podrá utilizar objetos CLR "antiguos" (POCO), tales
como objetos de dominio existentes, con el modelo de datos. Estas clases de datos POCO (también conocidas
como objetos que ignoran la persistencia), que se asignan a las entidades que se definen en un modelo de datos,
admiten la mayoría de los mismos comportamientos de consulta, inserción, actualización y eliminación que los
tipos de entidad generados por las herramientas de Entity Data Model.
Entity Framework también puede crear clases de proxy derivadas de los tipos POCO, que se usan cuando se desea
habilitar características como la carga diferida y el seguimiento de cambios automático en entidades POCO. Las
clases POCO deben cumplir ciertos requisitos para permitir que Entity Framework use servidores proxy, como se
describe aquí: http://msdn.microsoft.com/library/dd468057.aspx.
Los proxies de seguimiento de oportunidades enviarán una notificación al administrador de estado de objetos
cada vez que se cambie el valor de cualquiera de las propiedades de las entidades, por lo que Entity Framework
conoce el estado real de las entidades todo el tiempo. Esto se hace agregando eventos de notificación al cuerpo de
los métodos de establecedor de las propiedades y haciendo que el administrador de estado de objetos procese
dichos eventos. Tenga en cuenta que la creación de una entidad de proxy normalmente será más costosa que crear
una entidad POCO que no sea de proxy debido al conjunto agregado de eventos creados por Entity Framework.
Cuando una entidad POCO no tiene un proxy de seguimiento de cambios, se encuentran los cambios comparando
el contenido de las entidades con una copia de un estado guardado anterior. Esta comparación profunda se
convertirá en un proceso largo cuando tenga muchas entidades en el contexto, o cuando las entidades tengan una
gran cantidad de propiedades, aunque no hayan cambiado desde que se realizó la última comparación.
En Resumen: pagará un impacto en el rendimiento al crear el proxy de seguimiento de cambios, pero el
seguimiento de cambios le ayudará a acelerar el proceso de detección de cambios cuando las entidades tengan
muchas propiedades o cuando tenga muchas entidades en el modelo. En el caso de las entidades con un número
pequeño de propiedades en las que la cantidad de entidades no crece demasiado, es posible que los proxies de
seguimiento de cambios no tengan muchas ventajas.
8 carga de entidades relacionadas

8,1 carga diferida frente a carga diligente
Entity Framework ofrece varias maneras de cargar las entidades relacionadas con la entidad de destino. Por
ejemplo, al consultar productos, hay diferentes maneras de cargar los pedidos relacionados en el administrador de
estado de objetos. Desde el punto de vista del rendimiento, la pregunta más importante que hay que tener en
cuenta al cargar entidades relacionadas será si se va a usar la carga diferida o la carga diligente.
Cuando se usa la carga diligente, las entidades relacionadas se cargan junto con el conjunto de entidades de
destino. Use una instrucción include en la consulta para indicar qué entidades relacionadas desea incorporar.
Cuando se usa la carga diferida, la consulta inicial solo se coloca en el conjunto de entidades de destino. Pero
siempre que se tiene acceso a una propiedad de navegación, se emite otra consulta en el almacén para cargar la
entidad relacionada.
Una vez que se ha cargado una entidad, cualquier consulta adicional para la entidad la cargará directamente desde
el administrador de estado de objetos, tanto si usa la carga diferida como la carga diligente.
8,2 Cómo elegir entre la carga diferida y la carga diligente
Lo importante es que comprenda la diferencia entre la carga diferida y la carga diligente para que pueda tomar la
decisión correcta para su aplicación. Esto le ayudará a evaluar el equilibrio entre varias solicitudes en la base de
datos frente a una solicitud única que puede contener una carga grande. Puede ser adecuado usar la carga
diligente en algunas partes de la aplicación y la carga diferida en otras partes.
Como ejemplo de lo que sucede en el capó, supongamos que desea consultar los clientes que viven en el Reino
Unido y su recuento de pedidos.
Uso de la carga diligente

{
var ukCustomers = context.Customers.Include(c => c.Orders).Where(c => c.Address.Country == "UK");
var chosenCustomer = AskUserToPickCustomer(ukCustomers);
Console.WriteLine("Customer Id: {0} has {1} orders", customer.CustomerID, customer.Orders.Count);
}
Usar la carga diferida

{
context.ContextOptions.LazyLoadingEnabled = true;
//Notice that the Include method call is missing in the query

var ukCustomers = context.Customers.Where(c => c.Address.Country == "UK");
var chosenCustomer = AskUserToPickCustomer(ukCustomers);

Console.WriteLine("Customer Id: {0} has {1} orders", customer.CustomerID, customer.Orders.Count);
}
Cuando se usa la carga diligente, se emite una consulta única que devuelve todos los clientes y todos los pedidos.
El comando de almacenamiento tiene el siguiente aspecto:
SELECT
[Project1].[C1] AS [C1],
[Project1].[CustomerID] AS [CustomerID],
[Project1].[CompanyName] AS [CompanyName],
[Project1].[ContactName] AS [ContactName],
[Project1].[ContactTitle] AS [ContactTitle],
[Project1].[Address] AS [Address],
[Project1].[City] AS [City],
[Project1].[Region] AS [Region],
[Project1].[PostalCode] AS [PostalCode],
[Project1].[Country] AS [Country],
[Project1].[Phone] AS [Phone],
[Project1].[Fax] AS [Fax],
[Project1].[OrderID] AS [OrderID],
[Project1].[CustomerID1] AS [CustomerID1],
[Project1].[EmployeeID] AS [EmployeeID],
[Project1].[OrderDate] AS [OrderDate],
[Project1].[RequiredDate] AS [RequiredDate],
[Project1].[ShippedDate] AS [ShippedDate],
[Project1].[ShipVia] AS [ShipVia],
[Project1].[Freight] AS [Freight],
[Project1].[ShipName] AS [ShipName],
[Project1].[ShipAddress] AS [ShipAddress],
[Project1].[ShipCity] AS [ShipCity],
[Project1].[ShipRegion] AS [ShipRegion],
[Project1].[ShipPostalCode] AS [ShipPostalCode],
[Project1].[ShipCountry] AS [ShipCountry]
FROM ( SELECT
[Extent1].[CustomerID] AS [CustomerID],
[Extent1].[CompanyName] AS [CompanyName],
[Extent1].[ContactName] AS [ContactName],
[Extent1].[ContactTitle] AS [ContactTitle],
[Extent1].[Address] AS [Address],
[Extent1].[City] AS [City],
[Extent1].[Region] AS [Region],
[Extent1].[PostalCode] AS [PostalCode],
[Extent1].[Country] AS [Country],
[Extent1].[Phone] AS [Phone],
[Extent1].[Fax] AS [Fax],
1 AS [C1],
[Extent2].[OrderID] AS [OrderID],
[Extent2].[CustomerID] AS [CustomerID1],
[Extent2].[EmployeeID] AS [EmployeeID],
[Extent2].[OrderDate] AS [OrderDate],
[Extent2].[RequiredDate] AS [RequiredDate],
[Extent2].[ShippedDate] AS [ShippedDate],
[Extent2].[ShipVia] AS [ShipVia],
[Extent2].[Freight] AS [Freight],
[Extent2].[ShipName] AS [ShipName],
[Extent2].[ShipAddress] AS [ShipAddress],
[Extent2].[ShipCity] AS [ShipCity],
[Extent2].[ShipRegion] AS [ShipRegion],
[Extent2].[ShipPostalCode] AS [ShipPostalCode],
[Extent2].[ShipCountry] AS [ShipCountry],
CASE WHEN ([Extent2].[OrderID] IS NULL) THEN CAST(NULL AS int) ELSE 1 END AS [C2]
FROM [dbo].[Customers] AS [Extent1]
LEFT OUTER JOIN [dbo].[Orders] AS [Extent2] ON [Extent1].[CustomerID] = [Extent2].[CustomerID]
WHERE N'UK' = [Extent1].[Country]
) AS [Project1]
ORDER BY [Project1].[CustomerID] ASC, [Project1].[C2] ASC
Al usar la carga diferida, emitirá la siguiente consulta inicialmente:

SELECT
[Extent1].[CompanyName] AS [CompanyName],
[Extent1].[ContactName] AS [ContactName],
[Extent1].[ContactTitle] AS [ContactTitle],
[Extent1].[Address] AS [Address],
[Extent1].[City] AS [City],
[Extent1].[Region] AS [Region],
[Extent1].[PostalCode] AS [PostalCode],
[Extent1].[Country] AS [Country],
[Extent1].[Phone] AS [Phone],
[Extent1].[Fax] AS [Fax]
FROM [dbo].[Customers] AS [Extent1]
WHERE N'UK' = [Extent1].[Country]
Y cada vez que se accede a la propiedad de navegación Orders de un cliente, se emite otra consulta similar a la
siguiente en la tienda:
exec sp_executesql N'SELECT

[Extent1].[OrderID] AS [OrderID],
[Extent1].[EmployeeID] AS [EmployeeID],
[Extent1].[OrderDate] AS [OrderDate],
[Extent1].[RequiredDate] AS [RequiredDate],
[Extent1].[ShippedDate] AS [ShippedDate],
[Extent1].[ShipVia] AS [ShipVia],
[Extent1].[Freight] AS [Freight],
[Extent1].[ShipName] AS [ShipName],
[Extent1].[ShipAddress] AS [ShipAddress],
[Extent1].[ShipCity] AS [ShipCity],
[Extent1].[ShipRegion] AS [ShipRegion],
[Extent1].[ShipPostalCode] AS [ShipPostalCode],
[Extent1].[ShipCountry] AS [ShipCountry]
FROM [dbo].[Orders] AS [Extent1]
WHERE [Extent1].[CustomerID] = @EntityKeyValue1',N'@EntityKeyValue1 nchar(5)',@EntityKeyValue1=N'AROUT'
Para obtener más información, vea cargar objetos relacionados.

hoja de referencia diferida de carga 8.2.1 frente a carga diligente
No hay nada que se ajuste a todo para elegir la carga diligente frente a la carga diferida. Pruebe primero para
comprender las diferencias entre ambas estrategias, de modo que pueda tomar una decisión bien fundamentada;
Además, considere la posibilidad de que el código se ajuste a cualquiera de los siguientes escenarios:
ESC EN A RIO N UEST RA SUGEREN C IA
¿Necesita acceder a muchas propiedades de navegación desde No : las dos opciones probablemente sí lo hagan. Sin
las entidades capturadas? embargo, si la carga de la consulta no es demasiado grande,
puede experimentar ventajas de rendimiento mediante la
carga diligente, ya que requerirá menos viajes de ida y vuelta
de red para materializar los objetos.
Sí : Si necesita tener acceso a muchas propiedades de

navegación desde las entidades, lo haría mediante el uso de
varias instrucciones include en la consulta con la carga
diligente. Cuanto más entidades incluya, mayor será la carga
que devolverá la consulta. Una vez que incluya tres o más
entidades en la consulta, considere la posibilidad de cambiar a
la carga diferida.
ESC EN A RIO N UEST RA SUGEREN C IA
¿Sabe exactamente qué datos se necesitarán en tiempo de La carga no diferida será mejor para usted. De lo contrario,
ejecución? puede acabar consultando los datos que no necesitará.
Sí : la carga diligente es probablemente su mejor apuesta;

ayuda a cargar conjuntos completos más rápido. Si la consulta
requiere la captura de una cantidad muy grande de datos y se
vuelve demasiado lenta, intente la carga diferida en su lugar.
¿El código se ejecuta lejos de la base de datos? (mayor latencia No : cuando la latencia de red no es un problema, el uso de la
de red) carga diferida puede simplificar el código. Recuerde que la
topología de la aplicación puede cambiar, de modo que no
asuma la proximidad de la base de datos para concedido.
Sí : cuando la red es un problema, solo puede decidir cuál se

adapta mejor a su escenario. Normalmente, la carga diligente
será mejor porque requiere menos viajes de ida y vuelta.
8.2.2 problemas de rendimiento con varios includes

Cuando se escuchan preguntas de rendimiento que implican problemas en el tiempo de respuesta del servidor, el
origen del problema es con frecuencia consultas con varias instrucciones include. Aunque incluir las entidades
relacionadas en una consulta es eficaz, es importante comprender lo que sucede en segundo plano.
Tarda bastante tiempo en una consulta con varias instrucciones include en ella para pasar a través de nuestro
compilador del plan interno y generar el comando de la tienda. La mayor parte de este tiempo se dedica a intentar
optimizar la consulta resultante. El comando de almacenamiento generado contendrá una combinación externa o
una Unión para cada inclusión, en función de la asignación. Las consultas de este tipo incluirán gráficos de gran
tamaño de la base de datos en una sola carga, lo que acerbate cualquier problema de ancho de banda,
especialmente cuando hay mucha redundancia en la carga (por ejemplo, cuando se usan varios niveles de include
para atravesar) asociaciones en la dirección uno a varios).
Puede comprobar los casos en los que las consultas devuelven cargas excesivamente grandes mediante el acceso
al TSQL subyacente para la consulta mediante ToTraceString y la ejecución del comando Store en SQL Server
Management Studio para ver el tamaño de la carga. En tales casos, puede intentar reducir el número de
instrucciones include en la consulta para incorporar los datos que necesita. O bien, puede dividir la consulta en una
secuencia más pequeña de subconsultas, por ejemplo:
Antes de interrumpir la consulta:

{
var customers = from c in context.Customers.Include(c => c.Orders)
where c.LastName.StartsWith(lastNameParameter)
select c;
foreach (Customer customer in customers)

{
...
}
}
Después de interrumpir la consulta:

{
var orders = from o in context.Orders
where o.Customer.LastName.StartsWith(lastNameParameter)
select o;
orders.Load();
var customers = from c in context.Customers

where c.LastName.StartsWith(lastNameParameter)
select c;
foreach (Customer customer in customers)

{
...
}
}
Esto solo funcionará en las consultas con seguimiento, ya que estamos haciendo uso de la capacidad que el
contexto tiene para realizar la resolución de identidades y la corrección de asociación automáticamente.
Al igual que con la carga diferida, el compromiso será más consultas para cargas más pequeñas. También puede
usar las proyecciones de propiedades individuales para seleccionar explícitamente los datos que necesita de cada
entidad, pero no se cargarán las entidades en este caso y las actualizaciones no se admitirán.
8.2.3 solución alternativa para obtener la carga diferida de propiedades
Actualmente, Entity Framework no admite la carga diferida de propiedades escalares o complejas. Sin embargo, en
los casos en los que tiene una tabla que incluye un objeto grande, como un BLOB, puede usar la división de tablas
para separar las propiedades grandes en una entidad independiente. Por ejemplo, supongamos que tiene una tabla
de productos que incluye una columna de foto varbinary. Si no necesita tener acceso a esta propiedad con
frecuencia en las consultas, puede usar la división de tablas para traer solo las partes de la entidad que necesite
normalmente. La entidad que representa la foto del producto solo se cargará cuando lo necesite explícitamente.
Un buen recurso que muestra cómo habilitar la división de tablas es la entrada de blog "división de tablas en Entity
Framework" de Gil Fink: <http://blogs.microsoft.co.il/blogs/gilf/archive/2009/10/13/table-splitting-in-entity-
framework.aspx>.
9 otras consideraciones
Recolección de elementos no utilizados de 9,1 Server
Algunos usuarios podrían experimentar contención de recursos que limite el paralelismo que esperan cuando el
recolector de elementos no utilizados no está configurado correctamente. Siempre que se use EF en un escenario
multiproceso o en cualquier aplicación similar a un sistema de servidor, asegúrese de habilitar la recolección de
elementos no utilizados de servidor. Esto se hace a través de una configuración simple en el archivo de
configuración de la aplicación:
<?xmlversion="1.0" encoding="utf-8" ?>

<configuration>
<runtime>
<gcServer enabled="true" />
</runtime>
</configuration>
Esto debería reducir la contención del subproceso y aumentar el rendimiento hasta un 30% en escenarios
saturados de CPU. En términos generales, siempre debe probar el comportamiento de la aplicación mediante la
recolección de elementos no utilizados clásica (que está mejor optimizada para los escenarios de la interfaz de
usuario y del cliente), así como la recolección de elementos no utilizados del servidor.
9,2 AutoDetectChanges
Como se mencionó anteriormente, Entity Framework podrían mostrar problemas de rendimiento cuando la
memoria caché de objetos tiene muchas entidades. Ciertas operaciones, como agregar, quitar, buscar, entrada y
SaveChanges, desencadenan llamadas a DetectChanges que pueden consumir una gran cantidad de CPU en
función del tamaño de la memoria caché de objetos. La razón de esto es que la memoria caché de objetos y el
administrador de estado de objetos intentan permanecer sincronizados como sea posible en cada operación
realizada en un contexto para que se garantice que los datos generados son correctos en una amplia gama de
escenarios.
Por lo general, se recomienda dejar habilitada la detección automática de cambios de Entity Framework para toda
la vida de la aplicación. Si el escenario se ve afectado negativamente por el uso intensivo de la CPU y los perfiles
indican que la causa es la llamada a DetectChanges, considere la posibilidad de desactivar temporalmente
AutoDetectChanges en la parte confidencial del código:
try
{
var product = context.Products.Find(productId);
...
}
finally
{
}
Antes de desactivar AutoDetectChanges, es conveniente comprender que esto podría hacer que Entity Framework
pierda su capacidad de realizar un seguimiento de determinada información sobre los cambios que se están
llevando a cabo en las entidades. Si se trata de forma incorrecta, puede provocar incoherencias de datos en la
aplicación. Para obtener más información sobre la desactivación de AutoDetectChanges, lea
<http://blog.oneunicorn.com/2012/03/12/secrets-of-detectchanges-part-3-switching-off-automatic-
detectchanges/>.
9,3 contexto por solicitud
Los contextos de Entity Framework están diseñados para usarse como instancias de corta duración con el fin de
proporcionar la experiencia de rendimiento óptima. Se espera que los contextos tengan una duración corta y se
descarten, y como tal se han implementado para ser muy ligeros y reutilizar los metadatos siempre que sea
posible. En escenarios web es importante tener esto en cuenta y no tener un contexto mayor que la duración de
una única solicitud. Del mismo modo, en escenarios que no son Web, el contexto debe descartarse en función de
los distintos niveles de almacenamiento en caché en el Entity Framework. En general, debe evitar tener una
instancia de contexto a lo largo de la vida de la aplicación, así como contextos por subproceso y contextos
estáticos.
9,4 semántica nula de la base de datos
De forma predeterminada, Entity Framework generará código SQL que tiene una semántica de comparación de C#
null. Considere la consulta de ejemplo siguiente:
int? categoryId = 7;
int? supplierId = 8;
decimal? unitPrice = 0;
short? unitsInStock = 100;
short? unitsOnOrder = 20;
short? reorderLevel = null;
var q = from p incontext.Products

wherep.Category.CategoryName == "Beverages"
|| (p.CategoryID == categoryId
|| p.SupplierID == supplierId
|| p.UnitPrice == unitPrice
|| p.UnitsInStock == unitsInStock
|| p.UnitsOnOrder == unitsOnOrder
|| p.ReorderLevel == reorderLevel)
select p;
var r = q.ToList();
En este ejemplo, vamos a comparar un número de variables que aceptan valores NULL con las propiedades que
aceptan valores NULL en la entidad, como SupplierID y UnitPrice. El SQL generado para esta consulta le
preguntará si el valor del parámetro es el mismo que el valor de la columna, o si los valores del parámetro y de la
columna son NULL. Esto ocultará el modo en que el servidor de base de datos controla los valores NULL y
proporcionará una experiencia de C# null coherente entre distintos proveedores de bases de datos. Por otro lado,
el código generado es un poco complicado y es posible que no funcione correctamente cuando la cantidad de
comparaciones en la instrucción WHERE de la consulta aumenta a un número grande.
Una manera de tratar esta situación es usar la semántica de valores NULL de base de datos. Tenga en cuenta que
esto podría comportarse de forma diferente a la semántica de C# null, ya que ahora Entity Framework generará un
SQL más sencillo que exponga el modo en que el motor de base de datos controla los valores NULL. La semántica
de valores NULL de base de datos se puede activar por contexto con una sola línea de configuración en la
configuración de contexto:
context.Configuration.UseDatabaseNullSemantics = true;
Las consultas de tamaño pequeño a medio no mostrarán una mejora perceptible del rendimiento al usar la
semántica de las bases de datos nulas, pero la diferencia se volverá más perceptible en las consultas con un gran
número de comparaciones de NULL potenciales.
En la consulta de ejemplo anterior, la diferencia de rendimiento era inferior al 2% en un microbenchmark que se
ejecuta en un entorno controlado.
9,5 Async
Entity Framework 6 presentó la compatibilidad con operaciones asincrónicas cuando se ejecutan en .NET 4,5 o
versiones posteriores. En su mayor parte, las aplicaciones que tienen contención relacionada con la e/s
beneficiarán al máximo el uso de las operaciones asincrónicas de consulta y guardado. Si la aplicación no se ve
afectada por la contención de e/s, el uso de Async hará que, en los mejores casos, se ejecute sincrónicamente y
devuelva el resultado en la misma cantidad de tiempo que una llamada sincrónica, o en el peor de los casos,
simplemente postergue la ejecución a una tarea asincrónica y agregue Tim adicionales e a la finalización de su
escenario.
Para obtener información sobre cómo funciona la programación asincrónica que le ayudará a decidir si Async
mejorará el rendimiento de la aplicación, visite http://msdn.microsoft.com/library/hh191443.aspx. Para obtener
más información sobre el uso de operaciones asincrónicas en Entity Framework, consulte Async Query and Save.
NGEN 9,6
Entity Framework 6 no se incluye en la instalación predeterminada de .NET Framework. Como tal, los ensamblados
de Entity Framework no son de forma predeterminada NGEN, lo que significa que todo el código de Entity
Framework está sujeto a los mismos costos de JIT'ing que cualquier otro ensamblado de MSIL. Esto podría
degradar la experiencia F5 durante el desarrollo y también el inicio en frío de la aplicación en los entornos de
producción. Con el fin de reducir los costos de CPU y memoria de JIT'ing, es aconsejable que NGEN las imágenes
de Entity Framework según corresponda. Para obtener más información sobre cómo mejorar el rendimiento de
inicio de Entity Framework 6 con NGEN, vea mejorar el rendimiento de inicio con Ngen.
9,7 Code First frente a EDMX
Entity Framework razones sobre el problema de falta de coincidencia de impedancia entre la programación
orientada a objetos y las bases de datos relacionales con una representación en memoria del modelo conceptual
(los objetos), el esquema de almacenamiento (la base de datos) y una asignación entre el túnel. Estos metadatos se
denominan Entity Data Model o EDM para abreviar. Desde este EDM, Entity Framework derivarán las vistas para los
datos de ida y vuelta de los objetos de la memoria a la base de datos y viceversa.
Cuando se utiliza Entity Framework con un archivo EDMX que especifica formalmente el modelo conceptual, el
esquema de almacenamiento y la asignación, la fase de carga del modelo solo tiene que validar que el EDM es
correcto (por ejemplo, asegúrese de que no faltan asignaciones). genere las vistas y, a continuación, valide las
vistas y tenga estos metadatos listos para su uso. Solo entonces se puede ejecutar una consulta o se pueden
guardar datos nuevos en el almacén de datos.
El enfoque Code First es, en esencia, un generador de Entity Data Model sofisticado. El Entity Framework tiene que
generar un EDM a partir del código proporcionado; lo hace mediante el análisis de las clases implicadas en el
modelo, la aplicación de convenciones y la configuración del modelo a través de la API fluida. Una vez creado el
EDM, el Entity Framework se comporta de la misma manera que tenía un archivo EDMX presente en el proyecto.
Por lo tanto, la generación del modelo a partir de Code First agrega complejidad adicional que se traduce en un
tiempo de inicio más lento para el Entity Framework en comparación con el uso de EDMX. El costo depende por
completo del tamaño y la complejidad del modelo que se está compilando.
Al elegir usar EDMX frente a Code First, es importante saber que la flexibilidad introducida por Code First aumenta
el costo de crear el modelo por primera vez. Si la aplicación puede resistir el costo de esta primera carga,
normalmente Code First será la mejor manera de ir.
10 investigación del rendimiento

10,1 uso del generador de perfiles de Visual Studio
Si tiene problemas de rendimiento con el Entity Framework, puede usar un generador de perfiles como el que está
integrado en Visual Studio para ver dónde está gastando su aplicación su tiempo. Esta es la herramienta que se usa
para generar los gráficos circulares en la entrada de blog "Exploring the Performance of the ADO.NET Entity
Framework-Part 1" (<http://blogs.msdn.com/b/adonet/archive/2008/02/04/exploring-the-performance-of-the-
ado-net-entity-framework-part-1.aspx>) que muestran dónde Entity Framework dedica su tiempo durante las
consultas en frío y en caliente.
La entrada de blog "Entity Framework de generación de perfiles con el generador de perfiles de Visual Studio 2010
Profiler" escrita por el equipo de asesoramiento de datos y modelado de clientes muestra un ejemplo real de cómo
usaba el generador de perfiles para investigar un problema de rendimiento.
<http://blogs.msdn.com/b/dmcat/archive/2010/04/30/profiling-entity-framework-using-the-visual-studio-2010-
profiler.aspx>. Esta entrada se escribió para una aplicación Windows. Si tiene que generar perfiles de una
aplicación Web, las herramientas del Windows performance Recorder (WPR) y del analizador de rendimiento de
Windows (WPA) pueden funcionar mejor que si se trabajaran desde Visual Studio. WPR y WPA forman parte del kit
de herramientas de rendimiento de Windows que se incluye con Windows Assessment and Deployment Kit (
http://www.microsoft.com/download/details.aspx?id=39982).
10,2 generación de perfiles de aplicación/base de datos
Herramientas como el generador de perfiles integrado en Visual Studio le indica dónde dedica tiempo la
aplicación. Existe otro tipo de generador de perfiles que realiza el análisis dinámico de la aplicación en ejecución,
ya sea en producción o en preproducción en función de las necesidades, y busca errores comunes y antipatrones
de acceso a la base de datos.
Dos perfiles disponibles comercialmente son Entity Framework Profiler (<http://efprof.com>) y ORMProfiler
(<http://ormprofiler.com>).
Si la aplicación es una aplicación MVC que usa Code First, puede usar MiniProfiler de StackExchange. Scott
Hanselman describe esta herramienta en el blog de:
<http://www.hanselman.com/blog/NuGetPackageOfTheWeek9ASPNETMiniProfilerFromStackExchangeRocksYour
World.aspx>.
Para más información sobre la generación de perfiles de la actividad de base de datos de la aplicación, consulte el
artículo de MSDN Magazine de Julie Lerman titulado actividad de base de datos de generación de perfiles en el
Entity Framework.
registrador de base de datos 10,3
Si usa Entity Framework 6, considere también el uso de la funcionalidad de registro integrada. Se puede indicar a
la propiedad de base de datos del contexto que registre su actividad a través de una sencilla configuración de una
línea:
using (var context = newQueryComparison.DbC.NorthwindEntities())

{
context.Database.Log = Console.WriteLine;
q.ToList();
}
En este ejemplo, la actividad de la base de datos se registrará en la consola, pero la propiedad log puede
configurarse para llamar a cualquier acción<cadena> delegado.
Si desea habilitar el registro de base de datos sin volver a compilar y usa Entity Framework 6,1 o una versión
posterior, puede hacerlo agregando un interceptor en el archivo Web. config o app. config de la aplicación.
<interceptors>
<parameters>
<parameter value="C:\Path\To\My\LogOutput.txt"/>
</parameters>
</interceptor>
</interceptors>
Para obtener más información sobre cómo agregar registro sin volver a compilar, vaya a
<http://blog.oneunicorn.com/2014/02/09/ef-6-1-turning-on-logging-without-recompiling/>.
11 Apéndice
11,1 A. entorno de prueba
Este entorno utiliza una configuración de dos equipos con la base de datos en un equipo independiente de la
aplicación cliente. Las máquinas están en el mismo bastidor, por lo que la latencia de red es relativamente baja,
pero más realista que un entorno de un solo equipo.
Servidor de aplicaciones 11.1.1
En t o r n o d e so ft w a r e d e 1 1 .1 .1 .1
Entity Framework 4 entorno de software

Nombre del sistema operativo: Windows Server 2008 R2 Enterprise SP1.
Visual Studio 2010 – Ultimate.
Visual Studio 2010 SP1 (solo para algunas comparaciones).
Entity Framework 5 y 6 entorno de software
Nombre del sistema operativo: Windows 8.1 Enterprise
Visual Studio 2013: Ultimate.
En t o r n o d e h a r d w a r e d e 1 1 .1 .1 .2
Procesador dual: Intel (R) Xeon (R) CPU L5520 W3530 @ 2,27 GHz, 2261 Mhz8 GHz, 4 núcleos, 84
procesadores lógicos.
2412 GB RamRAM.
136 GB SCSI250GB SATA 7200 RPM GB/s unidad dividida en 4 particiones.
servidor de 11.1.2 DB
En t o r n o d e so ft w a r e d e 1 1 .1 .2 .1
Nombre del sistema operativo: Windows Server 2008 R 28.1 Enterprise SP1.
SQL Server 2008 R22012.
En t o r n o d e h a r d w a r e d e 1 1 .1 .2 .2
Procesador único: Intel (R) Xeon (R) CPU L5520 @ 2,27 GHz, 2261 MhzES-1620 0 @ 3,60 GHz, 4 núcleos, 8
procesadores lógicos.
824 GB RamRAM.
465 GB ATA500GB SATA 7200 RPM 6 GB/s unidad dividida en 4 particiones.
11,2 B. pruebas de comparación de rendimiento de consultas
El modelo Northwind se utilizó para ejecutar estas pruebas. Se generó a partir de la base de datos mediante el
diseñador de Entity Framework. A continuación, se usó el código siguiente para comparar el rendimiento de las
opciones de ejecución de la consulta:
using System;
using System.Data;
using System.Data.Objects;
using System.Linq;
namespace QueryComparison
{
public partial class NorthwindEntities : ObjectContext
{
private static readonly Func<NorthwindEntities, string, IQueryable<Product>> productsForCategoryCQ =
);
public IQueryable<Product> InvokeProductsForCategoryCQ(string categoryName)

{
return productsForCategoryCQ(this, categoryName);
}
}
public class QueryTypePerfComparison

{
private static string entityConnectionStr =
@"metadata=res://*/Northwind.csdl|res://*/Northwind.ssdl|res://*/Northwind.msl;provider=System.Data.SqlClient;
provider connection string='data source=.;initial catalog=Northwind;integrated
security=True;multipleactiveresultsets=True;App=EntityFramework'";
public void LINQIncludingContextCreation()

{
{
{
q.ToList();
}
}
public void LINQNoTracking()

{
{

q.ToList();
}
}
public void CompiledQuery()

{
{
var q = context.InvokeProductsForCategoryCQ("Beverages");
q.ToList();
}
}
public void ObjectQuery()

{
{
ObjectQuery<Product> products = context.Products.Where("it.Category.CategoryName =
'Beverages'");
products.ToList();
}
}
public void EntityCommand()

{
using (EntityConnection eConn = new EntityConnection(entityConnectionStr))
{
eConn.Open();
EntityCommand cmd = eConn.CreateCommand();
cmd.CommandText = "Select p From NorthwindEntities.Products As p Where p.Category.CategoryName
= 'Beverages'";
using (EntityDataReader reader = cmd.ExecuteReader(CommandBehavior.SequentialAccess))

{
List<Product> productsList = new List<Product>();
while (reader.Read())
{
DbDataRecord record = (DbDataRecord)reader.GetValue(0);
// 'materialize' the product by accessing each field and value. Because we are
materializing products, we won't have any nested data readers or records.
int fieldCount = record.FieldCount;
// Treat all products as Product, even if they are the subtype DiscontinuedProduct.
Product product = new Product();
product.ProductID = record.GetInt32(0);
product.ProductName = record.GetString(1);
product.SupplierID = record.GetInt32(2);
product.CategoryID = record.GetInt32(3);
product.QuantityPerUnit = record.GetString(4);
product.UnitPrice = record.GetDecimal(5);
product.UnitsInStock = record.GetInt16(6);
product.UnitsOnOrder = record.GetInt16(7);
product.ReorderLevel = record.GetInt16(8);
product.ReorderLevel = record.GetInt16(8);
product.Discontinued = record.GetBoolean(9);
productsList.Add(product);
}
}
}
}
public void ExecuteStoreQuery()

{
{
ObjectResult<Product> beverages = context.ExecuteStoreQuery<Product>(
P.UnitsInStock, P.UnitsOnOrder, P.ReorderLevel, P.Discontinued
);
beverages.ToList();
}
}
public void ExecuteStoreQueryDbContext()

{
using (var context = new QueryComparison.DbC.NorthwindEntities())
{
var beverages = context.Database.SqlQuery\<QueryComparison.DbC.Product>(
);
beverages.ToList();
}
}
public void ExecuteStoreQueryDbSet()

{
{
var beverages = context.Products.SqlQuery(
);
beverages.ToList();
}
}
public void LINQIncludingContextCreationDbContext()

{
{
q.ToList();
}
}
public void LINQNoTrackingDbContext()

{
{
var q = context.Products.AsNoTracking().Where(p => p.Category.CategoryName == "Beverages");
q.ToList();
}
}
}
}
Modelo 11,3 C. Navision

La base de datos de Navision es una base de datos grande que se usa para la demostración de Microsoft Dynamics
– NAV. El modelo conceptual generado contiene 1005 conjuntos de entidades y conjuntos de asociaciones de 4227.
El modelo usado en la prueba es "plano": no se ha agregado ninguna herencia a él.
11.3.1 consultas usadas para las pruebas de Navision
La lista de consultas utilizada con el modelo de Navision contiene tres categorías de consultas Entity SQL:
b ú sq u e d a 1 1 .3 .1 .1
Una consulta de búsqueda simple sin agregaciones

Recuento: 16232
Ejemplo:
<Query complexity="Lookup">
<CommandText>Select value distinct top(4) e.Idle_Time From NavisionFKContext.Session as e</CommandText>
</Query>
1 1 .3 .1 .2 Si n g l e A g g r e g a t i n g
Una consulta de BI normal con varias agregaciones, pero sin subtotales (consulta única)
Recuento: 2313
Ejemplo:
<Query complexity="SingleAggregating">
<CommandText>NavisionFK.MDF_SessionLogin_Time_Max()</CommandText>
</Query>
Donde MDF_SessionLogin_Time_Max () se define en el modelo como:
<Function Name="MDF_SessionLogin_Time_Max" ReturnType="Collection(DateTime)">

<DefiningExpression>SELECT VALUE Edm.Min(E.Login_Time) FROM NavisionFKContext.Session as
E</DefiningExpression>
</Function>
1 1 .3 .1 .3 A g g r e g a t i n g Su b t o t a l s
Una consulta de BI con agregaciones y subtotales (a través de Union All)

Recuento: 178
Ejemplo:
<Query complexity="AggregatingSubtotals">
<CommandText>
using NavisionFK;
function AmountConsumed(entities Collection([CRONUS_International_Ltd__Zone])) as
(
Edm.Sum(select value N.Block_Movement FROM entities as E, E.CRONUS_International_Ltd__Bin as N)
)
function AmountConsumed(P1 Edm.Int32) as
(
AmountConsumed(select value e from NavisionFKContext.CRONUS_International_Ltd__Zone as e where
e.Zone_Ranking = P1)
)
--------------------------------------------------------------------------------------------------------------
--------
(
select top(10) Zone_Ranking, Cross_Dock_Bin_Zone, AmountConsumed(GroupPartition(E))
from NavisionFKContext.CRONUS_International_Ltd__Zone as E
where AmountConsumed(E.Zone_Ranking) > @MinAmountConsumed
group by E.Zone_Ranking, E.Cross_Dock_Bin_Zone
)
union all
(
select top(10) Zone_Ranking, Cast(null as Edm.Byte) as P2, AmountConsumed(GroupPartition(E))
from NavisionFKContext.CRONUS_International_Ltd__Zone as E
where AmountConsumed(E.Zone_Ranking) > @MinAmountConsumed
group by E.Zone_Ranking
)
union all
{
Row(Cast(null as Edm.Int32) as P1, Cast(null as Edm.Byte) as P2, AmountConsumed(select value E
from
NavisionFKContext.CRONUS_International_Ltd__Zone as E
where AmountConsumed(E.Zone_Ranking)
> @MinAmountConsumed))
}</CommandText>
<Parameters>
<Parameter Name="MinAmountConsumed" DbType="Int32" Value="10000" />
</Parameters>
</Query>
Mejorar el rendimiento de inicio con NGen
NOTE
El .NET Framework admite la generación de imágenes nativas para aplicaciones y bibliotecas administradas como
una manera de ayudar a las aplicaciones a iniciarse más rápido y, en algunos casos, usar menos memoria. Las
imágenes nativas se crean mediante la conversión de ensamblados de código administrado en archivos que
contienen instrucciones máquina nativas antes de que se ejecute la aplicación, lo que evita que el compilador JIT de
.NET (Just-in-Time) tenga que generar las instrucciones nativas en tiempo de ejecución de la aplicación.
Antes de la versión 6, las bibliotecas principales del tiempo de ejecución de EF formaban parte del .NET Framework
y las imágenes nativas se generaban automáticamente para ellas. A partir de la versión 6, todo el tiempo de
ejecución de EF se ha combinado en el paquete NuGet de EntityFramework. Ahora, las imágenes nativas deben
generarse con la herramienta de línea de comandos NGen. exe para obtener resultados similares.
Las observaciones empíricas muestran que las imágenes nativas de los ensamblados en tiempo de ejecución de EF
pueden cortar entre 1 y 3 segundos de tiempo de inicio de la aplicación.
Cómo usar NGen. exe

La función más básica de la herramienta NGen. exe es "instalar" (es decir, crear y conservar en disco) imágenes
nativas para un ensamblado y todas sus dependencias directas. Aquí se muestra cómo lograr esto:
1. Abra una ventana de símbolo del sistema como administrador.
2. Cambie el directorio de trabajo actual a la ubicación de los ensamblados para los que desea generar
imágenes nativas:
cd <*Assemblies location*>
3. En función del sistema operativo y de la configuración de la aplicación, es posible que tenga que generar
imágenes nativas para la arquitectura de 32 bits, la arquitectura de 64 bits o para ambas.
Para la ejecución de 32 bits:
%WINDIR%\Microsoft.NET\Framework\v4.0.30319\ngen install <Assembly name>
Para la ejecución de 64 bits:
%WINDIR%\Microsoft.NET\Framework64\v4.0.30319\ngen install <Assembly name>

TIP
La generación de imágenes nativas para la arquitectura equivocada es un error muy común. En caso de duda, simplemente
puede generar imágenes nativas para todas las arquitecturas que se aplican al sistema operativo instalado en la máquina.
NGen. exe también admite otras funciones, como desinstalar y mostrar las imágenes nativas instaladas, poner en
cola la generación de varias imágenes, etc. Para obtener más detalles sobre el uso, lea la documentación de Ngen.
exe.
Cuándo usar NGen. exe

Cuando se trata de decidir en qué ensamblados se van a generar imágenes nativas en una aplicación basada en EF
versión 6 o versiones posteriores, debe tener en cuenta las siguientes opciones:
El ensamblado de tiempo de ejecución de EF principal, EntityFramework . dll : una aplicación basada
en EF típica ejecuta una cantidad significativa de código de este ensamblado en el inicio o en el primer acceso a
la base de datos. Por lo tanto, la creación de imágenes nativas de este ensamblado producirá las mayores
mejoras en el rendimiento de inicio.
Cualquier ensamblado de proveedor EF usado por la aplicación : el tiempo de inicio también puede
beneficiarse ligeramente de la generación de imágenes nativas. Por ejemplo, si la aplicación utiliza el proveedor
de EF para SQL Server querrá generar una imagen nativa para EntityFramework. SqlServer. dll.
Los ensamblados de la aplicación y otras dependencias : la documentación de Ngen. exe cubre los
criterios generales para elegir en qué ensamblados se van a generar imágenes nativas y el impacto de las
imágenes nativas en la seguridad, opciones avanzadas como "enlace fuerte", escenarios como el uso de
imágenes nativas en escenarios de depuración y generación de perfiles, etc.
TIP
Asegúrese de medir cuidadosamente el impacto del uso de imágenes nativas en el rendimiento de inicio y el rendimiento
general de la aplicación y compararlas con los requisitos reales. Mientras que las imágenes nativas suelen ayudar a mejorar el
rendimiento de inicio y, en algunos casos, reducir el uso de memoria, no todos los escenarios se beneficiarán de forma
equitativa. Por ejemplo, en la ejecución de estado estable (es decir, una vez que todos los métodos que se usan en la
aplicación se han invocado al menos una vez), el código generado por el compilador JIT puede producir de hecho un
rendimiento ligeramente mejor que las imágenes nativas.
Uso de NGen. exe en un equipo de desarrollo

Durante el desarrollo, el compilador JIT de .NET ofrecerá el mejor equilibrio general para el código que cambia con
frecuencia. La generación de imágenes nativas para las dependencias compiladas, como los ensamblados en
tiempo de ejecución de EF, puede ayudar a acelerar el desarrollo y las pruebas reduciendo unos pocos segundos al
principio de cada ejecución.
Un buen lugar para encontrar los ensamblados en tiempo de ejecución de EF es la ubicación del paquete NuGet
para la solución. Por ejemplo, para una aplicación que usa EF 6.0.2 con SQL Server y con .NET 4,5 o superior como
destino, puede escribir lo siguiente en una ventana del símbolo del sistema (Recuerde abrirla como administrador):
cd <Solution directory>\packages\EntityFramework.6.0.2\lib\net45
%WINDIR%\Microsoft.NET\Framework\v4.0.30319\ngen install EntityFramework.SqlServer.dll
%WINDIR%\Microsoft.NET\Framework64\v4.0.30319\ngen install EntityFramework.SqlServer.dll
NOTE
Esto aprovecha el hecho de que la instalación de imágenes nativas para el proveedor de EF para SQL Server también
instalará de forma predeterminada las imágenes nativas para el ensamblado de tiempo de ejecución de EF principal. Esto
funciona porque NGen. exe puede detectar que EntityFramework. dll es una dependencia directa del ensamblado
EntityFramework. SqlServer. dll que se encuentra en el mismo directorio.
Crear imágenes nativas durante la instalación

El kit de herramientas de WiX permite poner en cola la generación de imágenes nativas para los ensamblados
administrados durante la instalación, como se explica en esta Guía de procedimientos. Otra alternativa es crear una
tarea de instalación personalizada que ejecute el comando NGen. exe.
Comprobando que las imágenes nativas se usan para EF

Para comprobar que una aplicación específica está utilizando un ensamblado nativo, busque los ensamblados
cargados que tengan la extensión ". ni. dll" o ". ni. exe". Por ejemplo, una imagen nativa para el ensamblado en
tiempo de ejecución principal de EF se denominará EntityFramework. ni. dll. Una manera sencilla de inspeccionar
los ensamblados .NET cargados de un proceso es usar el Explorador de procesos.
Otras cosas que debe tener en cuenta

No se debe confundir la creación de una imagen nativa de un ensamblado con el registro del
ensamblado en la GAC (caché global de ensamblados) . NGen. exe permite crear imágenes de ensamblados
que no se encuentran en la GAC y, de hecho, varias aplicaciones que usan una versión específica de EF pueden
compartir la misma imagen nativa. Aunque Windows 8 puede crear automáticamente imágenes nativas para los
ensamblados colocados en la GAC, el tiempo de ejecución de EF se optimiza para implementarse junto con la
aplicación y no se recomienda registrarlo en la GAC, ya que esto tiene un impacto negativo en la resolución de
ensamblados. mantenimiento de las aplicaciones entre otros aspectos.
Vistas de asignación generadas previamente
Antes de que el Entity Framework pueda ejecutar una consulta o guardar cambios en el origen de datos, debe
generar un conjunto de vistas de asignación para tener acceso a la base de datos. Estas vistas de asignación son
un conjunto de Entity SQL instrucción que representa la base de datos de forma abstracta y forman parte de los
metadatos que se almacenan en caché por dominio de aplicación. Si crea varias instancias del mismo contexto en
el mismo dominio de aplicación, volverán a usar las vistas de asignación de los metadatos almacenados en caché
en lugar de volver a generarlas. Dado que la generación de la vista de asignación es una parte significativa del
costo total de ejecutar la primera consulta, el Entity Framework permite generar previamente vistas de asignación
e incluirlas en el proyecto compilado. Para obtener más información, vea consideraciones de rendimiento (Entity
Framework).
Generación de vistas de asignación con EF Power Tools Community

Edition
La manera más sencilla de generar vistas previamente es usar la edición de EF Power Tools Community Edition.
Una vez que tenga instaladas las herramientas avanzadas, tendrá una opción de menú para generar vistas, como
se indica a continuación.
En el caso de los modelos de code First , haga clic con el botón derecho en el archivo de código que contiene
la clase DbContext.
En el caso de los modelos EF Designer , haga clic con el botón derecho en el archivo EDMX.
Una vez finalizado el proceso, tendrá una clase similar a la siguiente generada
Ahora, cuando ejecute la aplicación EF, utilizará esta clase para cargar las vistas según sea necesario. Si el modelo
cambia y no vuelve a generar esta clase, EF producirá una excepción.
Generar vistas de asignación desde código-EF6 en adelante

La otra forma de generar vistas es usar las API que proporciona EF. Al usar este método, tiene la libertad de
serializar las vistas de la manera que desee, pero también debe cargar las vistas por su cuenta.
NOTE
EF6 y versiones posteriores: las API que se muestran en esta sección se introdujeron en Entity Framework 6. Si usa una
versión anterior, esta información no se aplica.
Generar vistas
Las API para generar vistas se encuentran en la clase System. Data. Entity. Core. Mapping.
StorageMappingItemCollection. Puede recuperar un StorageMappingCollection para un contexto mediante el
MetadataWorkspace de un ObjectContext. Si usa la API DbContext más reciente, puede acceder a ella con
IObjectContextAdapter como se muestra a continuación, en este código tenemos una instancia de DbContext
derivado denominada dbContext:
var objectContext = ((IObjectContextAdapter) dbContext).ObjectContext;

var mappingCollection = (StorageMappingItemCollection)objectContext.MetadataWorkspace
.GetItemCollection(DataSpace.CSSpace);
Una vez que tenga el StorageMappingItemCollection, puede obtener acceso a los métodos GenerateViews y
ComputeMappingHashValue.
public Dictionary\<EntitySetBase, DbMappingView> GenerateViews(IList<EdmSchemaError> errors)

public string ComputeMappingHashValue()
El primer método crea un diccionario con una entrada para cada vista de la asignación de contenedor. El segundo
método calcula un valor hash para la asignación de un solo contenedor y se utiliza en tiempo de ejecución para
validar que el modelo no ha cambiado desde que se generaron previamente las vistas. Se proporcionan
invalidaciones de los dos métodos para escenarios complejos que implican varias asignaciones de contenedor.
Al generar vistas, llamará al método GenerateViews y, a continuación, escribirá el EntitySetBase resultante y
DbMappingView. También necesitará almacenar el hash generado por el método ComputeMappingHashValue.
Cargando vistas
Para cargar las vistas generadas por el método GenerateViews, puede proporcionar EF con una clase que herede
de la clase abstracta DbMappingViewCache. DbMappingViewCache especifica dos métodos que debe
implementar:
public abstract string MappingHashValue { get; }

public abstract DbMappingView GetView(EntitySetBase extent);
La propiedad MappingHashValue debe devolver el hash generado por el método ComputeMappingHashValue.

Cuando EF vaya a pedir las vistas, primero generará y comparará el valor hash del modelo con el hash devuelto
por esta propiedad. Si no coinciden, EF producirá una excepción EntityCommandCompilationException.
El método GetView (aceptará un EntitySetBase y tendrá que devolver un DbMappingVIew que contenga el
EntitySql generado para que se asoció con el EntitySetBase determinado en el Diccionario generado por el método
GenerateViews. Si EF solicita una vista que no tiene, GetView (debe devolver null.
A continuación se muestra un extracto del DbMappingViewCache que se genera con las herramientas avanzadas,
como se ha descrito anteriormente, en él vemos una forma de almacenar y recuperar el EntitySql necesario.
public override string MappingHashValue

{
get { return "a0b843f03dd29abee99789e190a6fb70ce8e93dc97945d437d9a58fb8e2afd2e"; }
}
public override DbMappingView GetView(EntitySetBase extent)

{
if (extent == null)
{
throw new ArgumentNullException("extent");
}
var extentName = extent.EntityContainer.Name + "." + extent.Name;
if (extentName == "BlogContext.Blogs")
{
return GetView2();
}
if (extentName == "BlogContext.Posts")
{
return GetView3();
}
return null;
}
private static DbMappingView GetView2()

{
return new DbMappingView(@"
SELECT VALUE -- Constructing Blogs
[BlogApp.Models.Blog](T1.Blog_BlogId, T1.Blog_Test, T1.Blog_title, T1.Blog_Active,
T1.Blog_SomeDecimal)
FROM (
SELECT
T.BlogId AS Blog_BlogId,
T.Test AS Blog_Test,
T.title AS Blog_title,
T.Active AS Blog_Active,
T.SomeDecimal AS Blog_SomeDecimal,
True AS _from0
FROM CodeFirstDatabase.Blog AS T
) AS T1");
}
Para que EF use el DbMappingViewCache que agregue, use el DbMappingViewCacheTypeAttribute, especificando

el contexto para el que se creó. En el código siguiente se asocia el BlogContext con la clase MyMappingViewCache.
[assembly: DbMappingViewCacheType(typeof(BlogContext), typeof(MyMappingViewCache))]
En escenarios más complejos, se pueden proporcionar las instancias de la vista de la caché de vistas mediante la
especificación de un generador de caché de vista de asignación. Esto se puede hacer implementando la clase
abstracta System. Data. Entity. Infrastructure. MappingViews. DbMappingViewCacheFactory. La instancia del
generador de caché de la vista de asignación que se usa se puede recuperar o establecer mediante
StorageMappingItemCollection. MappingViewCacheFactoryproperty.
Proveedores de Entity Framework 6
NOTE
Entity Framework ahora se desarrolla bajo una licencia de código abierto, por lo que EF6 y versiones posteriores
no se van a incluir como parte de .NET Framework. Esto ofrece muchas ventajas, pero también exige que los
proveedores de EF se vuelvan a compilar en los ensamblados de EF6. Esto significa que los proveedores de EF para
EF5 y versiones anteriores no funcionarán con EF6 hasta que se vuelvan a compilar.
Proveedores disponibles para EF6

Los proveedores conocidos que se han vuelto a compilar para EF6 incluyen:
Proveedor de Microsoft SQL Ser ver
Compilado a partir del código base fuente abierto de Entity Framework
Incluido como parte del paquete NuGet de Entity Framework
Proveedor de Microsoft SQL Ser ver Compact Edition
Compilado a partir del código base fuente abierto de Entity Framework
Incluido en el paquete NuGet de EntityFramework.SqlServerCompact
Proveedores de datos de Devar t dotConnect
Existen proveedores de terceros de Devart para una serie de bases de datos como Oracle, MySQL,
PostgreSQL, SQLite, Salesforce, DB2 y SQL Server
Proveedores de CData Software
Existen proveedores de terceros de CData Software para una serie de almacenes de datos como
Salesforce, Azure Table Storage, MySql, etc.
Proveedor de Firebird
Disponible como paquete NuGet
Proveedor de Visual Fox Pro
Disponible como paquete NuGet
MySQL
Conector MySQL/NET para Entity Framework
PostgreSQL
Npgsql está disponible como paquete NuGet
Oracle
ODP.NET está disponible como paquete NuGet
Tenga en cuenta que la inclusión en esta lista no indica el nivel de funcionalidad o compatibilidad de un proveedor
determinado, solo que hay una compilación para EF6 disponible.
Registro de proveedores de EF
A partir de Entity Framework 6, los proveedores de EF se pueden registrar mediante configuración basada en
código o en el archivo de configuración de la aplicación.
Registro en el archivo de configuración
El registro del proveedor de EF en app.config o web.config tiene el formato siguiente:
<entityFramework>
<providers>
<provider invariantName="My.Invariant.Name" type="MyProvider.MyProviderServices, MyAssembly" />
</providers>
</entityFramework>
Tenga en cuenta que, a menudo, si el proveedor de EF se instala desde NuGet, el paquete NuGet agrega
automáticamente este registro al archivo de configuración. Si instala el paquete NuGet en un proyecto que no es el
proyecto de inicio de la aplicación, es posible que tenga que copiar el registro en el archivo de configuración del
proyecto de inicio.
El elemento "invariantName" de este registro es el mismo nombre invariable usado para identificar a un
proveedor de ADO.NET. Se puede encontrar como atributo "invariant" en un registro DbProviderFactories y como
atributo "providerName" en un registro de cadena de conexión. El nombre invariable que se va a usar también
debe incluirse en la documentación del proveedor. Ejemplos de nombres invariables son "System.Data.SqlClient"
para SQL Server y "System.Data.SqlServerCe.4.0" para SQL Server Compact.
El elemento "type" de este registro es el nombre calificado con el ensamblado del tipo de proveedor que se deriva
de "System.Data.Entity.Core.Common.DbProviderServices". Por ejemplo, la cadena que se va a usar para SQL
Compact es "System.Data.Entity.SqlServerCompact.SqlCeProviderServices, EntityFramework.SqlServerCompact".
El tipo que se va a usar aquí debe incluirse en la documentación del proveedor.
Registro basado en código
A partir de Entity Framework 6, la configuración de la aplicación de EF puede especificarse en el código. Para
obtener todos los detalles, vea Entity Framework Code-Based Configuration (Configuración basada en código de
Entity Framework). La forma habitual de registrar un proveedor de EF mediante configuración basada en código es
crear una nueva clase que se derive de System.Data.Entity.DbConfiguration y colocarla en el mismo ensamblado
que la clase DbContext. Luego la clase DbConfiguration debe registrar el proveedor en su constructor. Por ejemplo,
para registrar el proveedor de SQL Compact, la clase DbConfiguration tiene este aspecto:

{
{
SetProviderServices(
SqlCeProviderServices.ProviderInvariantName,
SqlCeProviderServices.Instance);
}
}
En este código, "SqlCeProviderServices.ProviderInvariantName" es una comodidad de la cadena de nombre

invariable del proveedor de SQL Server Compact ("System.Data.SqlServerCe.4.0") y
SqlCeProviderServices.Instance devuelve la instancia singleton del proveedor de EF de SQL Compact.
¿Qué ocurre si el proveedor que necesito no está disponible?

Si el proveedor está disponible para versiones anteriores de EF, se le anima a ponerse en contacto con el
propietario del proveedor y pedirle que cree una versión de EF6. Debe incluir una referencia a la documentación
para el modelo de proveedor de EF6.
¿Puedo escribir un proveedor por mí mismo?

Por supuesto que es posible crear un proveedor de EF por sí mismo, aunque no se debe considerar una tarea
trivial. El vínculo anterior sobre el modelo de proveedor de EF6 es un buen punto de partida. También le puede
resultar útil usar el código para el proveedor de SQL Server y SQL CE incluido en el código base fuente abierto de
EF como punto de partida o como referencia.
Tenga en cuenta que a partir de EF6, el proveedor de EF está menos estrechamente ligado al proveedor de
ADO.NET subyacente. Esto facilita la escritura de un proveedor de EF sin necesidad de escribir o ajustar las clases
de ADO.NET.
Modelo de proveedor de Entity Framework 6
El modelo de proveedor de Entity Framework permite utilizar Entity Framework con diferentes tipos de
servidor de base de datos. Por ejemplo, se puede conectar un proveedor para permitir el uso de EF en
Microsoft SQL Server, mientras que otro proveedor puede estar conectado a para permitir que EF se use en
Microsoft SQL Server Compact Edition. Los proveedores de EF6 que somos conscientes de pueden
encontrarse en la página proveedores de Entity Framework .
Algunos cambios fueron necesarios para la manera en que EF interactúa con los proveedores para permitir
que EF se libere bajo una licencia de código abierto. Estos cambios requieren la regeneración de los
proveedores de EF en los ensamblados de EF6 junto con los nuevos mecanismos de registro del proveedor.
Regeneración
Con EF6, el código principal que anteriormente formaba parte de la .NET Framework se envía ahora como
ensamblados fuera de banda (OOB). Puede encontrar información sobre cómo compilar aplicaciones en EF6
en la página actualizar aplicaciones para EF6 . También será necesario volver a generar los proveedores
mediante estas instrucciones.
Información general sobre tipos de proveedor

Un proveedor de EF es realmente una colección de servicios específicos del proveedor definidos por tipos CLR
que estos servicios extienden de (para una clase base) o implementan (para una interfaz). Dos de estos
servicios son fundamentales y necesarios para que EF funcione en absoluto. Otros son opcionales y solo
deben implementarse si se requiere una funcionalidad específica y/o las implementaciones predeterminadas
de estos servicios no funcionan para el servidor de base de datos específico de destino.
Tipos fundamentales de proveedor

DbProviderFactory
EF depende de tener un tipo derivado de System. Data. Common. DbProviderFactory para realizar todo el
acceso a la base de datos de bajo nivel. DbProviderFactory no es realmente parte de EF, sino que es una clase
en el .NET Framework que sirve un punto de entrada para los proveedores de ADO.NET que puede usarse en
EF, otro o, o directamente mediante una aplicación, para obtener instancias de conexiones, comandos,
parámetros y otras abstracciones de ADO.NET de un modo independiente del proveedor. Puede encontrar más
información sobre DbProviderFactory en la documentación de MSDN para ADO.net.
DbProviderServices
EF depende de tener un tipo derivado de DbProviderServices para proporcionar funcionalidad adicional que
EF necesita en la parte superior de la funcionalidad que ya proporciona el proveedor ADO.NET. En versiones
anteriores de EF la clase DbProviderServices formaba parte del .NET Framework y se encontraba en el espacio
de nombres System. Data. Common. A partir de EF6, esta clase ahora forma parte de EntityFramework. dll y se
encuentra en el espacio de nombres System. Data. Entity. Core. Common.
Puede encontrar más información sobre la funcionalidad fundamental de una implementación de
DbProviderServices en MSDN. Sin embargo, tenga en cuenta que, en el momento de escribir esta información,
no se actualiza para EF6, aunque la mayoría de los conceptos siguen siendo válidos. Las implementaciones de
SQL Server y SQL Server Compact de DbProviderServices también se protegen en el código base de código
abierto y pueden servir como referencias útiles para otras implementaciones.
En versiones anteriores de EF, la implementación de DbProviderServices que se va a usar se obtuvo
directamente de un proveedor ADO.NET. Esto se realiza mediante la conversión de DbProviderFactory a
IServiceProvider y la llamada al método GetService. Este es el proveedor de EF estrechamente acoplado al
DbProviderFactory. Este acoplamiento ha bloqueado EF para que no se mueva fuera del .NET Framework y, por
tanto, para EF6 se ha quitado este acoplamiento estricto y ahora se ha registrado una implementación de
DbProviderServices directamente en el archivo de configuración de la aplicación o en la configuración basada
en código, tal y como se describe más detalladamente en la sección registrar DbProviderServices que se
muestra a continuación.
Servicios adicionales
Además de los servicios fundamentales descritos anteriormente, también hay muchos otros servicios que se
usan en EF, que siempre son específicos de cada proveedor. Las implementaciones predeterminadas
específicas del proveedor de estos servicios se pueden proporcionar mediante una implementación de
DbProviderServices. Las aplicaciones también pueden invalidar las implementaciones de estos servicios o
proporcionar implementaciones cuando un tipo DbProviderServices no proporciona un valor predeterminado.
Esto se describe con más detalle en la sección resolución de servicios adicionales más adelante.
A continuación se enumeran los tipos de servicio adicionales que un proveedor puede ser de interés para un
proveedor. Encontrará más detalles sobre cada uno de estos tipos de servicio en la documentación de la API.
IDbExecutionStrategy
Se trata de un servicio opcional que permite a un proveedor implementar reintentos u otro comportamiento
cuando las consultas y los comandos se ejecutan en la base de datos. Si no se proporciona ninguna
implementación, EF simplemente ejecutará los comandos y propagará las excepciones que se produzcan. Por
SQL Server este servicio se utiliza para proporcionar una directiva de reintentos que es especialmente útil
cuando se ejecuta en servidores de bases de datos basados en la nube, como SQL Azure.
IDbConnectionFactory
Se trata de un servicio opcional que permite a un proveedor crear objetos DbConnection por Convención
cuando se especifica solo un nombre de base de datos. Tenga en cuenta que aunque este servicio se puede
resolver mediante una implementación de DbProviderServices, está presente desde EF 4,1 y también se puede
establecer explícitamente en el archivo de configuración o en el código. El proveedor solo tendrá la
oportunidad de resolver este servicio si se registró como el proveedor predeterminado (vea el proveedor
predeterminado a continuación) y si no se ha establecido un generador de conexiones predeterminado en otro
lugar.
DbSpatialServices
Se trata de un servicio opcional que permite a un proveedor agregar compatibilidad para los tipos espaciales
Geography y Geometry. Se debe proporcionar una implementación de este servicio para que una aplicación
use EF con tipos espaciales. DbSptialServices se solicita de dos maneras. En primer lugar, se solicitan servicios
espaciales específicos del proveedor mediante un objeto DbProviderInfo (que contiene el nombre invariable y
el token del manifiesto) como clave. En segundo lugar, se puede solicitar a DbSpatialServices sin clave. Se usa
para resolver el "proveedor espacial global" que se usa al crear tipos independientes de DbGeography o
DbGeometry.
MigrationSqlGenerator
Se trata de un servicio opcional que permite usar migraciones de EF para la generación de SQL que se usa en
la creación y modificación de esquemas de base de datos de Code First. Se requiere una implementación para
admitir las migraciones. Si se proporciona una implementación, también se utilizará cuando se creen las bases
de datos mediante inicializadores de base de datos o el método Database. Create.
FUNC < DbConnection, String, HistoryContextFactory >
Se trata de un servicio opcional que permite a un proveedor configurar la asignación de HistoryContext a la
tabla de __MigrationHistory utilizada por las migraciones de EF. HistoryContext es un DbContext de Code First
y se puede configurar mediante la API fluida normal para cambiar aspectos como el nombre de la tabla y las
especificaciones de asignación de columnas. La implementación predeterminada de este servicio devuelta por
EF para todos los proveedores puede funcionar para un servidor de base de datos determinado si ese
proveedor admite todas las asignaciones predeterminadas de tabla y columna. En tal caso, no es necesario que
el proveedor proporcione una implementación de este servicio.
IDbProviderFactoryResolver
Se trata de un servicio opcional para obtener el DbProviderFactory correcto de un objeto DbConnection
determinado. La implementación predeterminada de este servicio devuelta por EF para todos los proveedores
está pensada para funcionar con todos los proveedores. Sin embargo, cuando se ejecuta en .NET 4, el
DbProviderFactory no es accesible públicamente desde uno si su DbConnections. Por lo tanto, EF usa algunas
heurísticas para buscar coincidencias en los proveedores registrados. Es posible que, en algunos proveedores,
se produzca un error en esta heurística y, en tales situaciones, el proveedor proporcione una nueva
implementación.
Registrando DbProviderServices
La implementación de DbProviderServices que se va a usar se puede registrar en el archivo de configuración
de la aplicación (App. config o Web. config) o mediante la configuración basada en código. En cualquier caso,
el registro utiliza el "nombre invariable" del proveedor como clave. Esto permite registrar y usar varios
proveedores en una sola aplicación. El nombre invariable que se usa para los registros EF es el mismo que el
nombre invariable que se usa para el registro del proveedor ADO.NET y las cadenas de conexión. Por ejemplo,
para SQL Server se usa el nombre invariable "System. Data. SqlClient".
Registro en el archivo de configuración
El tipo DbProviderServices que se va a usar se registra como un elemento de proveedor en la lista de
proveedores de la sección entityFramework del archivo de configuración de la aplicación. Por ejemplo:
<entityFramework>
<providers>
<provider invariantName="My.Invariant.Name" type="MyProvider.MyProviderServices, MyAssembly" />
</providers>
</entityFramework>
La cadena de tipo debe ser el nombre de tipo calificado con el ensamblado de la implementación de
DbProviderServices que se va a usar.
Registro basado en código
A partir de, los proveedores de EF6 también se pueden registrar mediante código. Esto permite usar un
proveedor EF sin ningún cambio en el archivo de configuración de la aplicación. Para usar la configuración
basada en código, una aplicación debe crear una clase DbConfiguration tal como se describe en la
documentación de configuración basada en código. El constructor de la clase DbConfiguration debería llamar
a SetProviderServices para registrar el proveedor de EF. Por ejemplo:

{
{
SetProviderServices("My.New.Provider", new MyProviderServices());
}
}
Resolver servicios adicionales
Como se mencionó anteriormente en la sección información general de los tipos de proveedor, una clase
DbProviderServices también se puede usar para resolver servicios adicionales. Esto es posible porque
DbProviderServices implementa IDbDependencyResolver y cada tipo de DbProviderServices registrado se
agrega como una "resolución predeterminada". El mecanismo IDbDpendencyResolver se describe con más
detalle en resolución de dependencias. Sin embargo, no es necesario comprender todos los conceptos de esta
especificación para resolver servicios adicionales en un proveedor.
La forma más común de que un proveedor resuelva servicios adicionales es llamar a DbProviderServices.
AddDependencyResolver para cada servicio en el constructor de la clase DbProviderServices. Por ejemplo,
SqlProviderServices (el proveedor de EF para SQL Server) tiene un código similar a este para la inicialización:
private SqlProviderServices()
{
AddDependencyResolver(new SingletonDependencyResolver<IDbConnectionFactory>(
new SqlConnectionFactory()));
AddDependencyResolver(new ExecutionStrategyResolver<DefaultSqlExecutionStrategy>(
"System.data.SqlClient", null, () => new DefaultSqlExecutionStrategy()));
AddDependencyResolver(new SingletonDependencyResolver<Func<MigrationSqlGenerator>>(
() => new SqlServerMigrationSqlGenerator(), "System.data.SqlClient"));
AddDependencyResolver(new SingletonDependencyResolver<DbSpatialServices>(
SqlSpatialServices.Instance,
k =>
{
var asSpatialKey = k as DbProviderInfo;
return asSpatialKey == null
|| asSpatialKey.ProviderInvariantName == ProviderInvariantName;
}));
}
Este constructor usa las siguientes clases auxiliares:

SingletonDependencyResolver: proporciona una manera sencilla de resolver los servicios singleton, es
decir, los servicios para los que se devuelve la misma instancia cada vez que se llama a GetService. Los
servicios transitorios suelen registrarse como un generador singleton que se usará para crear instancias
transitorias a petición.
ExecutionStrategyResolver: un solucionador específico para devolver implementaciones de
IExecutionStrategy.
En lugar de usar DbProviderServices. AddDependencyResolver, también es posible invalidar
DbProviderServices. GetService y resolver servicios adicionales directamente. Se llamará a este método
cuando EF necesite un servicio definido por un tipo determinado y, en algunos casos, para una clave
determinada. El método debe devolver el servicio si es posible o devolver null a la cancelación de la
devolución del servicio y, en su lugar, permitir que otra clase la resuelva. Por ejemplo, para resolver el
generador de conexiones predeterminado, el código de GetService podría tener un aspecto similar al
siguiente:
public override object GetService(Type type, object key)
{
if (type == typeof(IDbConnectionFactory))
{
return new SqlConnectionFactory();
}
return null;
}
Orden de registro
Cuando se registran varias implementaciones de DbProviderServices en el archivo de configuración de una
aplicación, se agregarán como resoluciones secundarias en el orden en que se muestran. Puesto que los
solucionadores siempre se agregan a la parte superior de la cadena de resolución secundaria, esto significa
que el proveedor al final de la lista tendrá la oportunidad de resolver las dependencias antes de las demás.
(Esto puede parecer un poco más intuitivo al principio, pero tiene sentido si se deja que cada proveedor esté
fuera de la lista y se apile encima de los proveedores existentes).
Normalmente, esta clasificación no es importante porque la mayoría de los servicios del proveedor son
específicos del proveedor y tienen como clave el nombre invariable del proveedor. Sin embargo, para los
servicios que no están codificados por el nombre invariable del proveedor o alguna otra clave específica del
proveedor, el servicio se resolverá en función de este orden. Por ejemplo, si no se establece explícitamente de
forma distinta en otro lugar, el generador de conexiones predeterminado procederá del proveedor superior de
la cadena.
Registros de archivos de configuración adicionales

Es posible registrar explícitamente algunos de los servicios de proveedor adicionales descritos anteriormente
en el archivo de configuración de una aplicación. Cuando esto se hace, se usará el registro del archivo de
configuración en lugar de cualquier elemento devuelto por el método GetService de la implementación de
DbProviderServices.
Registro del generador de conexiones predeterminado
A partir de EF5, el paquete NuGet de EntityFramework registra automáticamente el generador de conexiones
de SQL Express o el generador de conexiones de LocalDb en el archivo de configuración.
Por ejemplo:
<entityFramework>
<defaultConnectionFactory type="System.Data.Entity.Infrastructure.SqlConnectionFactory, EntityFramework"
>
</entityFramework>
El tipo es el nombre de tipo calificado con el ensamblado para el generador de conexiones predeterminado,
que debe implementar IDbConnectionFactory.
Se recomienda que un paquete NuGet de proveedor establezca el generador de conexiones predeterminado
de este modo cuando se instale. Consulte los paquetes de NuGet para los proveedores siguientes.
Cambios adicionales del proveedor de EF6

Cambios del proveedor espacial
Los proveedores que admiten tipos espaciales ahora deben implementar algunos métodos adicionales en las
clases que derivan de DbSpatialDataReader:
public abstract bool IsGeographyColumn(int ordinal)
public abstract bool IsGeometryColumn(int ordinal)
También hay nuevas versiones asincrónicas de los métodos existentes que se recomienda invalidar como las
implementaciones predeterminadas que se delegan en los métodos sincrónicos y, por tanto, no se ejecutan de
forma asincrónica:
public virtual Task<DbGeography> GetGeographyAsync(int ordinal, CancellationToken cancellationToken)
public virtual Task<DbGeometry> GetGeometryAsync(int ordinal, CancellationToken cancellationToken)
Compatibilidad nativa con Enumerable. Contains

EF6 introduce un nuevo tipo de expresión, DbInExpression, que se ha agregado para solucionar problemas de
rendimiento relacionados con el uso de Enumerable. Contains en consultas LINQ. La clase DbProviderManifest
tiene un nuevo método virtual, SupportsInExpression, al que se llama EF para determinar si un proveedor
controla el nuevo tipo de expresión. Para ofrecer compatibilidad con las implementaciones de proveedor
existentes, el método devuelve false. Para beneficiarse de esta mejora, un proveedor de EF6 puede agregar
código para controlar DbInExpression e invalidar SupportsInExpression para que devuelva true. Se puede crear
una instancia de DbInExpression llamando al método DbExpressionBuilder.In. Una instancia de DbInExpression
se compone de un DbExpression, que normalmente representa una columna de tabla, y una lista de
DbConstantExpression para comprobar si hay coincidencias.
Paquetes NuGet para proveedores

Una manera de hacer que un proveedor de EF6 esté disponible es publicarlo como un paquete de NuGet. El
uso de un paquete NuGet presenta las siguientes ventajas:
Es fácil usar NuGet para agregar el registro del proveedor al archivo de configuración de la aplicación.
Se pueden realizar cambios adicionales en el archivo de configuración para establecer el generador de
conexiones predeterminado de modo que las conexiones realizadas por la Convención utilicen el proveedor
registrado
NuGet controla la adición de redirecciones de enlace para que el proveedor de EF6 siga funcionando
incluso después de que se publique un nuevo paquete EF.
Un ejemplo de esto es el paquete EntityFramework. Sqlservercom que se incluye en el código base de código
abierto. Este paquete proporciona una buena plantilla para crear paquetes NuGet del proveedor de EF.
Comandos de PowerShell
Cuando se instala el paquete NuGet EntityFramework, se registra un módulo de PowerShell que contiene dos
comandos que son muy útiles para los paquetes de proveedor:
Add-EFProvider agrega una nueva entidad para el proveedor en el archivo de configuración del proyecto
de destino y se asegura de que está al final de la lista de proveedores registrados.
Add-EFDefaultConnectionFactory agrega o actualiza el registro de defaultConnectionFactory en el archivo
de configuración del proyecto de destino.
Ambos comandos se encargan de agregar una sección entityFramework al archivo de configuración y agregar
una colección de proveedores si es necesario.
Está previsto que se llame a estos comandos desde el script de NuGet install. ps1. Por ejemplo, install. PS1 para
el proveedor de SQL Compact tiene un aspecto similar al siguiente:
param($installPath, $toolsPath, $package, $project)

Add-EFDefaultConnectionFactory $project 'System.Data.Entity.Infrastructure.SqlCeConnectionFactory,
EntityFramework' -ConstructorArguments 'System.Data.SqlServerCe.4.0'
Add-EFProvider $project 'System.Data.SqlServerCe.4.0'
'System.Data.Entity.SqlServerCompact.SqlCeProviderServices, EntityFramework.SqlServerCompact'</pre>
Puede obtener más información acerca de estos comandos mediante Get-Help en la ventana de la consola del
administrador de paquetes.
Encapsular proveedores
Un proveedor de ajuste es un proveedor EF o ADO.NET que contiene un proveedor existente para extenderlo
con otras funciones, como la generación de perfiles o las capacidades de seguimiento. Los proveedores de
encapsulado se pueden registrar de la manera normal, pero a menudo es más conveniente configurar el
proveedor de ajuste en tiempo de ejecución mediante la interceptación de la resolución de servicios
relacionados con el proveedor. Para ello, se puede usar el evento estático OnLockingConfiguration en la clase
DbConfiguration.
Se llama a OnLockingConfiguration después de que EF haya determinado dónde se obtendrá la configuración
de EF para el dominio de aplicación, pero antes de que se bloquee para su uso. En el inicio de la aplicación
(antes de que se use EF), la aplicación debe registrar un controlador de eventos para este evento. (Se está
considerando la posibilidad de agregar compatibilidad para registrar este controlador en el archivo de
configuración, pero aún no se admite). A continuación, el controlador de eventos debe realizar una llamada a
ReplaceService para cada servicio que debe ajustarse.
Por ejemplo, para ajustar IDbConnectionFactory y DbProviderService, se debe registrar un controlador similar
a este:
DbConfiguration.OnLockingConfiguration +=
(_, a) =>
{
a.ReplaceService<DbProviderServices>(
(s, k) => new MyWrappedProviderServices(s));
a.ReplaceService<IDbConnectionFactory>(
(s, k) => new MyWrappedConnectionFactory(s));
};
El servicio que se ha resuelto y ahora debe ajustarse junto con la clave que se usó para resolver el servicio se
pasa al controlador. Después, el controlador puede encapsular este servicio y reemplazar el servicio devuelto
por la versión ajustada.
Resolver un DbProviderFactory con EF

DbProviderFactory es uno de los tipos fundamentales de proveedor que requiere EF como se describe en la
sección de información general de tipos de proveedor anterior. Como ya se mencionó, no es un tipo EF y el
registro no suele ser parte de la configuración de EF, sino que es el registro del proveedor ADO.NET normal en
el archivo Machine. config y/o el archivo de configuración de la aplicación.
A pesar de que este EF siga usando su mecanismo de resolución de dependencias normal al buscar un
DbProviderFactory para usarlo. El solucionador predeterminado usa el registro ADO.NET normal en los
archivos de configuración y, por lo tanto, esto suele ser transparente. Sin embargo, debido al mecanismo de
resolución de dependencias normal se usa, significa que se puede usar una IDbDependencyResolver para
resolver un DbProviderFactory incluso cuando no se ha realizado el registro de ADO.NET normal.
La resolución de DbProviderFactory de esta manera tiene varias implicaciones:
Una aplicación que usa la configuración basada en código puede agregar llamadas en su clase
DbConfiguration para registrar el DbProviderFactory adecuado. Esto es especialmente útil para las
aplicaciones que no quieren (o no pueden) hacer uso de cualquier configuración basada en archivos.
El servicio se puede ajustar o reemplazar mediante ReplaceService tal como se describe en la sección
anterior de los proveedores de ajuste
Teóricamente, una implementación de DbProviderServices podría resolver un DbProviderFactory.
El punto importante que hay que tener en cuenta es que solo afectará a la búsqueda de DbProviderFactory en
EF. Otro código que no sea EF podría esperar que el proveedor ADO.NET se registre de la forma normal y
puede producir un error si no se encuentra el registro. Por esta razón, suele ser mejor registrar un
DbProviderFactory de la manera normal de ADO.NET.
Servicios relacionados
Si EF se usa para resolver un DbProviderFactory, debe resolver también los servicios IProviderInvariantName y
IDbProviderFactoryResolver.
IProviderInvariantName es un servicio que se usa para determinar un nombre invariable de proveedor para
un tipo determinado de DbProviderFactory. La implementación predeterminada de este servicio utiliza el
registro del proveedor ADO.NET. Esto significa que si el proveedor ADO.NET no está registrado de la manera
normal porque EF está resolviendo DbProviderFactory, también será necesario para resolver este servicio.
Tenga en cuenta que se agrega automáticamente un solucionador para este servicio cuando se usa el método
DbConfiguration. SetProviderFactory.
Tal y como se describe en la sección de información general sobre tipos de proveedores anterior,
IDbProviderFactoryResolver se usa para obtener el DbProviderFactory correcto de un objeto DbConnection
determinado. La implementación predeterminada de este servicio cuando se ejecuta en .NET 4 usa el registro
del proveedor ADO.NET. Esto significa que si el proveedor ADO.NET no está registrado de la manera normal
porque EF está resolviendo DbProviderFactory, también será necesario para resolver este servicio.
Compatibilidad del proveedor con tipos espaciales
Entity Framework admite el trabajo con datos espaciales a través de las clases DbGeography o DbGeometry. Estas
clases se basan en la funcionalidad específica de la base de datos que ofrece el proveedor de Entity Framework.
No todos los proveedores admiten datos espaciales y los que pueden tener requisitos previos adicionales, como la
instalación de ensamblados de tipo espacial. A continuación se proporciona más información sobre la
compatibilidad del proveedor con los tipos espaciales.
Puede encontrar información adicional sobre cómo usar los tipos espaciales en una aplicación en dos tutoriales,
uno para Code First, el otro para Database First o Model First:
Tipos de datos espaciales en Code First
Tipos de datos espaciales en EF Designer
Versiones de EF que admiten tipos espaciales

La compatibilidad con los tipos espaciales se presentó en EF5. Sin embargo, en los tipos espaciales de EF5 solo se
admiten cuando la aplicación tiene como destino y se ejecuta en .NET 4,5.
A partir de EF6, se admiten los tipos espaciales para las aplicaciones que tienen como destino .NET 4 y .NET 4,5.
Proveedores de EF que admiten tipos espaciales

EF5
Los proveedores de Entity Framework para EF5 que somos conscientes de que admiten tipos espaciales son:
Proveedor de Microsoft SQL Server
Este proveedor se incluye como parte de EF5.
Este proveedor depende de algunas bibliotecas adicionales de bajo nivel que puedan ser necesarias para
instalarse; consulte a continuación para obtener más información.
Devart dotConnect para Oracle
Se trata de un proveedor de terceros de Devart.
Si conoce un proveedor de EF5 que admite tipos espaciales, póngase en contacto con y nos alegrará de agregarlo
a esta lista.
EF6
Los proveedores de Entity Framework para EF6 que somos conscientes de que admiten tipos espaciales son:
Proveedor de Microsoft SQL Server
Este proveedor se incluye como parte de EF6.
Este proveedor depende de algunas bibliotecas adicionales de bajo nivel que puedan ser necesarias para
instalarse; consulte a continuación para obtener más información.
Devart dotConnect para Oracle
Se trata de un proveedor de terceros de Devart.
Si conoce un proveedor de EF6 que admite tipos espaciales, póngase en contacto con y nos alegrará de agregarlo
a esta lista.
Requisitos previos para los tipos espaciales con Microsoft SQL Server
SQL Server compatibilidad espacial depende de los tipos de bajo nivel, específicos de SQL Server SqlGeography y
SqlGeometry. Estos tipos viven en el ensamblado Microsoft. SqlServer. types. dll, y este ensamblado no se envía
como parte de EF o como parte de la .NET Framework.
Cuando se instala Visual Studio, a menudo también se instala una versión de SQL Server, lo que incluye la
instalación de Microsoft. SqlServer. types. dll.
Si SQL Server no está instalado en el equipo en el que desea usar tipos espaciales, o si los tipos espaciales se
excluyen de la instalación de SQL Server, deberá instalarlos manualmente. Los tipos se pueden instalar mediante
SQLSysClrTypes.msi , que forma parte de Microsoft SQL Server Feature Pack. Los tipos espaciales son SQL Server
específicos de la versión, por lo que se recomienda Buscar "SQL Server Feature Pack" en el centro de descarga de
Microsoft y, a continuación, seleccionar y descargar la opción correspondiente a la versión de SQL Server que se
va a usar.
Trabajar con servidores proxy
Al crear instancias de tipos de entidad POCO, Entity Framework a menudo crea instancias de un tipo derivado
generado dinámicamente que actúa como un proxy para la entidad. Este proxy invalida algunas propiedades
virtuales de la entidad para insertar enlaces para realizar acciones automáticamente cuando se tiene acceso a la
propiedad. Por ejemplo, este mecanismo se usa para admitir la carga diferida de relaciones. Las técnicas que se
muestran en este tema se aplican igualmente a los modelos creados con Code First y EF Designer.
Deshabilitar la creación de proxy

A veces resulta útil evitar que Entity Framework Cree instancias de proxy. Por ejemplo, la serialización de instancias
que no son de proxy es considerablemente más fácil que serializar instancias de proxy. La creación del proxy se
puede desactivar borrando la marca ProxyCreationEnabled. Un lugar donde podría hacer esto es en el constructor
del contexto. Por ejemplo:

{
{
this.Configuration.ProxyCreationEnabled = false;
}

}
Tenga en cuenta que EF no creará servidores proxy para los tipos en los que no hay nada que pueda realizar el
proxy. Esto significa que también puede evitar servidores proxy si tiene tipos que están sellados o no tienen
ninguna propiedad virtual.
Crear explícitamente una instancia de un proxy

No se creará una instancia de proxy si crea una instancia de una entidad mediante el operador new. Esto puede no
ser un problema, pero si necesita crear una instancia de proxy (por ejemplo, para que la carga diferida o el
seguimiento de cambios de proxy funcionen), puede hacerlo mediante el método Create de DbSet. Por ejemplo:

{
var blog = context.Blogs.Create();
}
La versión genérica de Create se puede usar si desea crear una instancia de un tipo de entidad derivada. Por
ejemplo:

{
var admin = context.Users.Create<Administrator>();
}
Tenga en cuenta que el método Create no agrega ni adjunta la entidad creada al contexto.
Tenga en cuenta que el método Create solo creará una instancia del tipo de entidad si la creación de un tipo de
proxy para la entidad no tiene ningún valor, ya que no haría nada. Por ejemplo, si el tipo de entidad está sellado
y/o no tiene ninguna propiedad virtual, Create solo creará una instancia del tipo de entidad.
Obtener el tipo de entidad real a partir de un tipo de proxy

Los tipos de proxy tienen nombres que tienen un aspecto similar al siguiente:
System. Data. Entity. DynamicProxies.
Blog_5E43C6C196972BF0754973E48C9C941092D86818CD94005E9A759B70BF6E48E6
Puede encontrar el tipo de entidad para este tipo de proxy mediante el método GetObjectType de ObjectContext.
Por ejemplo:

{
var blog = context.Blogs.Find(1);
var entityType = ObjectContext.GetObjectType(blog.GetType());
}
Tenga en cuenta que si el tipo pasado a GetObjectType es una instancia de un tipo de entidad que no es un tipo de
proxy, el tipo de entidad se sigue devolviendo. Esto significa que siempre puede usar este método para obtener el
tipo de entidad real sin ninguna otra comprobación para ver si el tipo es un tipo de proxy.
Probar con un marco ficticio
NOTE
Al escribir pruebas para la aplicación, a menudo es conveniente evitar la llegada de la base de datos. Entity
Framework le permite conseguirlo mediante la creación de un contexto, con el comportamiento definido por las
pruebas, que hace uso de los datos en memoria.
Opciones para crear dobles de pruebas

Existen dos enfoques diferentes que se pueden usar para crear una versión en memoria del contexto.
Crear sus propios dobles de pruebas : este enfoque implica escribir su propia implementación en
memoria de su contexto y DbSets. Esto le ofrece un gran control sobre cómo se comportan las clases, pero
puede implicar la escritura y la propiedad de una cantidad de código razonable.
Usar un marco ficticio para crear dobles de pruebas : mediante un marco ficticio (como MOQ), puede
tener las implementaciones en memoria del contexto y los conjuntos creados dinámicamente en tiempo de
ejecución.
En este artículo se tratará el uso de un marco ficticio. Para crear sus propios dobles de pruebas, consulte pruebas
con los dobles de pruebas.
Para demostrar el uso de EF con un marco ficticio, vamos a usar MOQ. La forma más fácil de obtener MOQ es
instalar el paquete MOQ desde NuGet.
Pruebas con versiones anteriores a EF6

El escenario que se muestra en este artículo depende de algunos cambios realizados en DbSet en EF6. Para realizar
pruebas con EF5 y versiones anteriores, consulte pruebas con un contexto falso.
Limitaciones de los dobles de pruebas en memoria de EF

Los dobles de pruebas en memoria pueden ser una buena manera de proporcionar una cobertura de nivel de
prueba unitaria de bits de la aplicación que usa EF. Sin embargo, al hacerlo, se usa LINQ to Objects para ejecutar
consultas en los datos en memoria. Esto puede dar lugar a un comportamiento diferente al uso del proveedor
LINQ (LINQ to Entities) de EF para traducir las consultas en SQL que se ejecutan en la base de datos.
Un ejemplo de este tipo de diferencia es la carga de datos relacionados. Si crea una serie de blogs en los que cada
uno tiene elementos relacionados, al usar los datos en memoria, los envíos relacionados se cargarán siempre para
cada blog. Sin embargo, cuando se ejecuta en una base de datos, los datos solo se cargarán si se usa el método
include.
Por esta razón, se recomienda incluir siempre cierto nivel de pruebas de un extremo a otro (además de las pruebas
unitarias) para asegurarse de que la aplicación funciona correctamente en una base de datos.
Junto con este artículo

En este artículo se proporcionan listas de código completas que se pueden copiar en Visual Studio para que se
realicen a continuación, si así se desea. Es más fácil crear un proyecto de prueba unitaria y tendrá que tener
como destino .NET Framework 4,5 para completar las secciones que usan Async.
El modelo EF
El servicio que vamos a probar hace uso de un modelo EF compuesto por las clases BloggingContext y blog y post.
Este código puede haber sido generado por EF Designer o ser un modelo de Code First.
namespace TestingDemo
{
{
public virtual DbSet<Blog> Blogs { get; set; }
public virtual DbSet<Post> Posts { get; set; }
}
public class Blog

{

}
public class Post

{

}
}
Propiedades de DbSet virtuales con EF Designer

Tenga en cuenta que las propiedades de DbSet en el contexto se marcan como virtuales. Esto permitirá que el
marco ficticio se derive de nuestro contexto e invalide estas propiedades con una implementación ficticia.
Si usa Code First, puede editar las clases directamente. Si usa el diseñador de EF, tendrá que editar la plantilla T4
que genera el contexto. Abra el>de model_name de <. Archivo Context.tt que está anidado en el archivo edmx,
busque el fragmento de código siguiente y agregue la palabra clave virtual como se muestra.
public string DbSet(EntitySet entitySet)

{
return string.Format(
CultureInfo.InvariantCulture,
"{0} virtual DbSet\<{1}> {2} {{ get; set; }}",
Accessibility.ForReadOnlyProperty(entitySet),
_typeMapper.GetTypeName(entitySet.ElementType),
_code.Escape(entitySet));
}
Servicio que se va a probar

Para demostrar las pruebas con los dobles de pruebas en memoria, vamos a escribir un par de pruebas para un
BlogService. El servicio es capaz de crear nuevos blogs (AddBlog) y devolver todos los blogs ordenados por
nombre (GetAllBlogs). Además de GetAllBlogs, también se proporciona un método que obtendrá de forma
asincrónica todos los blogs ordenados por nombre (GetAllBlogsAsync).
using System.Linq;
{
{

{
_context = context;
}
public Blog AddBlog(string name, string url)

{
var blog = _context.Blogs.Add(new Blog { Name = name, Url = url });
return blog;
}
public List<Blog> GetAllBlogs()

{
var query = from b in _context.Blogs
orderby b.Name
select b;
return query.ToList();
}
public async Task<List<Blog>> GetAllBlogsAsync()

{
orderby b.Name
select b;
return await query.ToListAsync();

}
}
}
Probar escenarios que no son de consulta

Eso es todo lo que necesitamos hacer para empezar a probar los métodos que no son de consulta. La prueba
siguiente usa MOQ para crear un contexto. Después crea un> de blog de DbSet<y lo conecta para que se devuelva
desde la propiedad blogs del contexto. Después, el contexto se usa para crear un nuevo BlogService que se usa
para crear un nuevo blog: mediante el método AddBlog. Por último, la prueba comprueba que el servicio agregó
un nuevo blog y se llama SaveChanges en el contexto.
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Moq;
{
[TestClass]
public class NonQueryTests
{
[TestMethod]
public void CreateBlog_saves_a_blog_via_context()
{
var mockSet = new Mock<DbSet<Blog>>();
var mockContext = new Mock<BloggingContext>();

mockContext.Setup(m => m.Blogs).Returns(mockSet.Object);
var service = new BlogService(mockContext.Object);

service.AddBlog("ADO.NET Blog", "http://blogs.msdn.com/adonet");
mockSet.Verify(m => m.Add(It.IsAny<Blog>()), Times.Once());

mockContext.Verify(m => m.SaveChanges(), Times.Once());
}
}
}
Probar escenarios de consulta

Para poder ejecutar consultas en nuestra prueba de DbSet doble, es necesario configurar una implementación de
IQueryable. El primer paso es crear algunos datos en memoria: usamos una lista<blog>. A continuación, creamos
un contexto y DBSet<blog>, a continuación, conectaremos la implementación de IQueryable para DbSet:
simplemente están delegando en el proveedor de LINQ to Objects que funciona con la lista<T>.
A continuación, podemos crear un BlogService basado en los dobles de pruebas y asegurarse de que los datos que
se obtienen de GetAllBlogs se ordenan por nombre.
using Moq;
using System.Linq;
{
[TestClass]
public class QueryTests
{
[TestMethod]
public void GetAllBlogs_orders_by_name()
{
var data = new List<Blog>
{
new Blog { Name = "BBB" },
new Blog { Name = "ZZZ" },
new Blog { Name = "AAA" },
}.AsQueryable();

mockSet.As<IQueryable<Blog>>().Setup(m => m.Provider).Returns(data.Provider);
mockSet.As<IQueryable<Blog>>().Setup(m => m.Expression).Returns(data.Expression);
mockSet.As<IQueryable<Blog>>().Setup(m => m.ElementType).Returns(data.ElementType);
mockSet.As<IQueryable<Blog>>().Setup(m => m.GetEnumerator()).Returns(data.GetEnumerator());

mockContext.Setup(c => c.Blogs).Returns(mockSet.Object);

var blogs = service.GetAllBlogs();
Assert.AreEqual(3, blogs.Count);
Assert.AreEqual("AAA", blogs[0].Name);
Assert.AreEqual("BBB", blogs[1].Name);
Assert.AreEqual("ZZZ", blogs[2].Name);
}
}
}
Pruebas con consultas asincrónicas

Entity Framework 6 presentó un conjunto de métodos de extensión que se pueden usar para ejecutar una consulta
de forma asincrónica. Entre los ejemplos de estos métodos se incluyen ToListAsync, FirstAsync, ForEachAsync, etc.
Dado que Entity Framework consultas usan LINQ, los métodos de extensión se definen en IQueryable y
IEnumerable. Sin embargo, dado que solo están diseñados para usarse con Entity Framework puede recibir el
siguiente error si intenta utilizarlos en una consulta LINQ que no es una consulta de Entity Framework:
IQueryable de origen no implementa IDbAsyncEnumerable{0}. Solo los orígenes que implementan

IDbAsyncEnumerable se pueden usar para las operaciones asincrónicas de Entity Framework. Para obtener
más información, consulte http://go.microsoft.com/fwlink/?LinkId=287068.
Mientras que los métodos asincrónicos solo se admiten cuando se ejecuta en una consulta EF, puede que desee
usarlos en la prueba unitaria cuando se ejecuta en una prueba en memoria Double de un DbSet.
Para utilizar los métodos asincrónicos, es necesario crear un DbAsyncQueryProvider en memoria para procesar la
consulta asincrónica. Aunque sería posible configurar un proveedor de consultas mediante MOQ, es mucho más
fácil crear una implementación de prueba Double en el código. El código para esta implementación es el siguiente:
using System.Linq;
using System.Linq.Expressions;
using System.Threading;
{
internal class TestDbAsyncQueryProvider<TEntity> : IDbAsyncQueryProvider
{
private readonly IQueryProvider _inner;
internal TestDbAsyncQueryProvider(IQueryProvider inner)

{
_inner = inner;
}
public IQueryable CreateQuery(Expression expression)

{
return new TestDbAsyncEnumerable<TEntity>(expression);
}
public IQueryable<TElement> CreateQuery<TElement>(Expression expression)

{
return new TestDbAsyncEnumerable<TElement>(expression);
}
public object Execute(Expression expression)

{
return _inner.Execute(expression);
}
public TResult Execute<TResult>(Expression expression)

{
return _inner.Execute<TResult>(expression);
}
public Task<object> ExecuteAsync(Expression expression, CancellationToken cancellationToken)

{
return Task.FromResult(Execute(expression));
}
public Task<TResult> ExecuteAsync<TResult>(Expression expression, CancellationToken cancellationToken)

{
return Task.FromResult(Execute<TResult>(expression));
}
}
internal class TestDbAsyncEnumerable<T> : EnumerableQuery<T>, IDbAsyncEnumerable<T>, IQueryable<T>

{
public TestDbAsyncEnumerable(IEnumerable<T> enumerable)
: base(enumerable)
{ }
public TestDbAsyncEnumerable(Expression expression)

: base(expression)
{ }
public IDbAsyncEnumerator<T> GetAsyncEnumerator()

{
return new TestDbAsyncEnumerator<T>(this.AsEnumerable().GetEnumerator());
}
IDbAsyncEnumerator IDbAsyncEnumerable.GetAsyncEnumerator()
{
return GetAsyncEnumerator();
}
IQueryProvider IQueryable.Provider
{
{
get { return new TestDbAsyncQueryProvider<T>(this); }
}
}
internal class TestDbAsyncEnumerator<T> : IDbAsyncEnumerator<T>

{
private readonly IEnumerator<T> _inner;
public TestDbAsyncEnumerator(IEnumerator<T> inner)

{
_inner = inner;
}
public void Dispose()

{
_inner.Dispose();
}
public Task<bool> MoveNextAsync(CancellationToken cancellationToken)

{
return Task.FromResult(_inner.MoveNext());
}
public T Current
{
get { return _inner.Current; }
}
object IDbAsyncEnumerator.Current
{
get { return Current; }
}
}
}
Ahora que tenemos un proveedor de consultas asincrónicas, podemos escribir una prueba unitaria para el nuevo
método GetAllBlogsAsync.
using Moq;
using System.Linq;
{
[TestClass]
public class AsyncQueryTests
{
[TestMethod]
public async Task GetAllBlogsAsync_orders_by_name()
{
var data = new List<Blog>

{
new Blog { Name = "BBB" },
new Blog { Name = "ZZZ" },
new Blog { Name = "AAA" },
}.AsQueryable();

mockSet.As<IDbAsyncEnumerable<Blog>>()
.Setup(m => m.GetAsyncEnumerator())
.Returns(new TestDbAsyncEnumerator<Blog>(data.GetEnumerator()));
mockSet.As<IQueryable<Blog>>()
.Setup(m => m.Provider)
.Returns(new TestDbAsyncQueryProvider<Blog>(data.Provider));
mockSet.As<IQueryable<Blog>>().Setup(m => m.Expression).Returns(data.Expression);

mockSet.As<IQueryable<Blog>>().Setup(m => m.ElementType).Returns(data.ElementType);
mockSet.As<IQueryable<Blog>>().Setup(m => m.GetEnumerator()).Returns(data.GetEnumerator());

mockContext.Setup(c => c.Blogs).Returns(mockSet.Object);

var blogs = await service.GetAllBlogsAsync();
}
}
}
Pruebas con sus propias dobles de pruebas
NOTE
Al escribir pruebas para la aplicación, a menudo es conveniente evitar la llegada de la base de datos. Entity
Framework le permite conseguirlo mediante la creación de un contexto, con el comportamiento definido por las
pruebas, que hace uso de los datos en memoria.
Opciones para crear dobles de pruebas

Existen dos enfoques diferentes que se pueden usar para crear una versión en memoria del contexto.
Crear sus propios dobles de pruebas : este enfoque implica escribir su propia implementación en
memoria de su contexto y DbSets. Esto le ofrece un gran control sobre cómo se comportan las clases, pero
puede implicar la escritura y la propiedad de una cantidad de código razonable.
Usar un marco ficticio para crear dobles de pruebas : mediante un marco ficticio (como MOQ), puede
tener las implementaciones en memoria de contexto y conjuntos creados dinámicamente en tiempo de
ejecución.
En este artículo se tratará la creación de su propio Double de prueba. Para obtener información sobre el uso de un
marco ficticio, vea probar con un marco ficticio.
Pruebas con versiones anteriores a EF6

El código que se muestra en este artículo es compatible con EF6. Para realizar pruebas con EF5 y versiones
anteriores, consulte pruebas con un contexto falso.
Limitaciones de los dobles de pruebas en memoria de EF

Los dobles de pruebas en memoria pueden ser una buena manera de proporcionar una cobertura de nivel de
prueba unitaria de bits de la aplicación que usa EF. Sin embargo, al hacerlo, se usa LINQ to Objects para ejecutar
consultas en los datos en memoria. Esto puede dar lugar a un comportamiento diferente al uso del proveedor
LINQ (LINQ to Entities) de EF para traducir las consultas en SQL que se ejecutan en la base de datos.
Un ejemplo de este tipo de diferencia es la carga de datos relacionados. Si crea una serie de blogs en los que cada
uno tiene elementos relacionados, al usar los datos en memoria, los envíos relacionados se cargarán siempre para
cada blog. Sin embargo, cuando se ejecuta en una base de datos, los datos solo se cargarán si se usa el método
include.
Por esta razón, se recomienda incluir siempre cierto nivel de pruebas de un extremo a otro (además de las
pruebas unitarias) para asegurarse de que la aplicación funciona correctamente en una base de datos.
Junto con este artículo

En este artículo se proporcionan listas de código completas que se pueden copiar en Visual Studio para que se
realicen a continuación, si así se desea. Es más fácil crear un proyecto de prueba unitaria y tendrá que tener
como destino .NET Framework 4,5 para completar las secciones que usan Async.
Crear una interfaz de contexto

Vamos a echar un vistazo a la prueba de un servicio que hace uso de un modelo EF. Para poder reemplazar el
contexto de EF con una versión en memoria para las pruebas, vamos a definir una interfaz que implementará el
contexto de EF (y el valor Double en memoria).
El servicio que se va a probar consultará y modificará los datos mediante las propiedades DbSet de nuestro
contexto y también llamará a SaveChanges para enviar los cambios a la base de datos. Por tanto, vamos a incluir
estos miembros en la interfaz.
{
public interface IBloggingContext
{
DbSet<Blog> Blogs { get; }
DbSet<Post> Posts { get; }
int SaveChanges();
}
}
El modelo EF
El servicio que vamos a probar hace uso de un modelo EF compuesto por las clases BloggingContext y blog y post.
Este código puede haber sido generado por EF Designer o ser un modelo de Code First.
{
public class BloggingContext : DbContext, IBloggingContext
{
}
public class Blog

{

}
public class Post

{

}
}
Implementar la interfaz de contexto con EF Designer

Tenga en cuenta que nuestro contexto implementa la interfaz IBloggingContext.
Si usa Code First, puede modificar el contexto directamente para implementar la interfaz. Si usa el diseñador de EF,
tendrá que editar la plantilla T4 que genera el contexto. Abra el>de model_name de <. Archivo Context.tt que está
anidado en el archivo edmx, busque el fragmento de código siguiente y agréguelo en la interfaz como se muestra.
<#=Accessibility.ForType(container)#> partial class <#=code.Escape(container)#> : DbContext, IBloggingContext
Servicio que se va a probar

Para demostrar las pruebas con los dobles de pruebas en memoria, vamos a escribir un par de pruebas para un
BlogService. El servicio es capaz de crear nuevos blogs (AddBlog) y devolver todos los blogs ordenados por
nombre (GetAllBlogs). Además de GetAllBlogs, también se proporciona un método que obtendrá de forma
asincrónica todos los blogs ordenados por nombre (GetAllBlogsAsync).
using System.Linq;
{
{
private IBloggingContext _context;
public BlogService(IBloggingContext context)

{
_context = context;
}
public Blog AddBlog(string name, string url)

{
var blog = new Blog { Name = name, Url = url };
return blog;
}
public List<Blog> GetAllBlogs()

{
orderby b.Name
select b;
return query.ToList();
}
public async Task<List<Blog>> GetAllBlogsAsync()

{
orderby b.Name
select b;
return await query.ToListAsync();

}
}
}
Crear dobles de pruebas en memoria

Ahora que tenemos el modelo de EF real y el servicio que puede usarlo, es el momento de crear el doble de
prueba en memoria que se puede usar para las pruebas. Hemos creado un Double de prueba de TestContext para
nuestro contexto. En la prueba, se puede elegir el comportamiento que se desea para admitir las pruebas que se
van a ejecutar. En este ejemplo, vamos a capturar el número de veces que se llama a SaveChanges, pero puede
incluir la lógica que se necesita para comprobar el escenario que se está probando.
También hemos creado un TestDbSet que proporciona una implementación en memoria de DbSet. Hemos
proporcionado una implementación completa de todos los métodos de DbSet (excepto buscar), pero solo tiene
que implementar los miembros que usará el escenario de prueba.
TestDbSet usa algunas otras clases de infraestructura que hemos incluido para asegurarse de que se puedan
procesar las consultas asincrónicas.
using System;
using System.Linq;
using System.Linq.Expressions;
using System.Threading;
{
public class TestContext : IBloggingContext
{
public TestContext()
{
this.Blogs = new TestDbSet<Blog>();
this.Posts = new TestDbSet<Post>();
}

public int SaveChangesCount { get; private set; }
public int SaveChanges()
{
this.SaveChangesCount++;
return 1;
}
}
public class TestDbSet<TEntity> : DbSet<TEntity>, IQueryable, IEnumerable<TEntity>,

IDbAsyncEnumerable<TEntity>
where TEntity : class
{
ObservableCollection<TEntity> _data;
IQueryable _query;
public TestDbSet()
{
_data = new ObservableCollection<TEntity>();
_query = _data.AsQueryable();
}
public override TEntity Add(TEntity item)

{
_data.Add(item);
return item;
}
public override TEntity Remove(TEntity item)

{
_data.Remove(item);
return item;
return item;
}
public override TEntity Attach(TEntity item)

{
_data.Add(item);
return item;
}
public override TEntity Create()

{
return Activator.CreateInstance<TEntity>();
}
public override TDerivedEntity Create<TDerivedEntity>()

{
return Activator.CreateInstance<TDerivedEntity>();
}
public override ObservableCollection<TEntity> Local

{
get { return _data; }
}
Type IQueryable.ElementType
{
get { return _query.ElementType; }
}
Expression IQueryable.Expression
{
get { return _query.Expression; }
}
{
get { return new TestDbAsyncQueryProvider<TEntity>(_query.Provider); }
}
System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator()
{
return _data.GetEnumerator();
}
IEnumerator<TEntity> IEnumerable<TEntity>.GetEnumerator()
{
return _data.GetEnumerator();
}
IDbAsyncEnumerator<TEntity> IDbAsyncEnumerable<TEntity>.GetAsyncEnumerator()
{
return new TestDbAsyncEnumerator<TEntity>(_data.GetEnumerator());
}
}
internal class TestDbAsyncQueryProvider<TEntity> : IDbAsyncQueryProvider

{
private readonly IQueryProvider _inner;
internal TestDbAsyncQueryProvider(IQueryProvider inner)

{
_inner = inner;
}
public IQueryable CreateQuery(Expression expression)

{
return new TestDbAsyncEnumerable<TEntity>(expression);
}

{
return new TestDbAsyncEnumerable<TElement>(expression);
}
public object Execute(Expression expression)

{
return _inner.Execute(expression);
}
public TResult Execute<TResult>(Expression expression)

{
return _inner.Execute<TResult>(expression);
}
public Task<object> ExecuteAsync(Expression expression, CancellationToken cancellationToken)

{
return Task.FromResult(Execute(expression));
}
public Task<TResult> ExecuteAsync<TResult>(Expression expression, CancellationToken cancellationToken)

{
return Task.FromResult(Execute<TResult>(expression));
}
}
internal class TestDbAsyncEnumerable<T> : EnumerableQuery<T>, IDbAsyncEnumerable<T>, IQueryable<T>

{
public TestDbAsyncEnumerable(IEnumerable<T> enumerable)
: base(enumerable)
{ }
public TestDbAsyncEnumerable(Expression expression)

: base(expression)
{ }
public IDbAsyncEnumerator<T> GetAsyncEnumerator()

{
return new TestDbAsyncEnumerator<T>(this.AsEnumerable().GetEnumerator());
}
IDbAsyncEnumerator IDbAsyncEnumerable.GetAsyncEnumerator()
{
return GetAsyncEnumerator();
}
{
get { return new TestDbAsyncQueryProvider<T>(this); }
}
}
internal class TestDbAsyncEnumerator<T> : IDbAsyncEnumerator<T>

{
private readonly IEnumerator<T> _inner;
public TestDbAsyncEnumerator(IEnumerator<T> inner)

{
_inner = inner;
}
public void Dispose()

{
_inner.Dispose();
}
public Task<bool> MoveNextAsync(CancellationToken cancellationToken)

{
return Task.FromResult(_inner.MoveNext());
}
public T Current
{
get { return _inner.Current; }
}
object IDbAsyncEnumerator.Current
{
get { return Current; }
}
}
}
Implementación de Find
El método Find es difícil de implementar de forma genérica. Si necesita probar el código que hace uso del método
Find, es más fácil crear un DbSet de prueba para cada uno de los tipos de entidad que deben admitir la búsqueda.
Después, puede escribir lógica para buscar ese tipo de entidad concreto, como se muestra a continuación.
using System.Linq;
{
class TestBlogDbSet : TestDbSet<Blog>
{
public override Blog Find(params object[] keyValues)
{
var id = (int)keyValues.Single();
return this.SingleOrDefault(b => b.BlogId == id);
}
}
}
Escribir algunas pruebas

Eso es todo lo que necesitamos hacer para iniciar las pruebas. La prueba siguiente crea una TestContext y luego un
servicio basado en este contexto. Después, el servicio se usa para crear un nuevo blog: mediante el método
AddBlog. Por último, la prueba comprueba que el servicio agregó un nuevo blog a la propiedad blogs del contexto
y que se llama SaveChanges en el contexto.
Este es solo un ejemplo de los tipos de cosas que puede probar con una prueba en memoria Double y puede
ajustar la lógica de los dobles de pruebas y la comprobación para satisfacer sus requisitos.
using System.Linq;
{
[TestClass]
public class NonQueryTests
{
[TestMethod]
public void CreateBlog_saves_a_blog_via_context()
{
var context = new TestContext();

service.AddBlog("ADO.NET Blog", "http://blogs.msdn.com/adonet");
Assert.AreEqual(1, context.Blogs.Count());
Assert.AreEqual("ADO.NET Blog", context.Blogs.Single().Name);
Assert.AreEqual("http://blogs.msdn.com/adonet", context.Blogs.Single().Url);
Assert.AreEqual(1, context.SaveChangesCount);
}
}
}
Este es otro ejemplo de una prueba; esta vez, una que realiza una consulta. La prueba se inicia creando un contexto
de prueba con algunos datos en su propiedad de blog. tenga en cuenta que los datos no están en orden alfabético.
A continuación, podemos crear un BlogService basado en nuestro contexto de prueba y asegurarse de que los
datos que obtenemos de GetAllBlogs estén ordenados por nombre.
{
[TestClass]
public class QueryTests
{
[TestMethod]
public void GetAllBlogs_orders_by_name()
{
context.Blogs.Add(new Blog { Name = "BBB" });
context.Blogs.Add(new Blog { Name = "ZZZ" });
context.Blogs.Add(new Blog { Name = "AAA" });

var blogs = service.GetAllBlogs();
}
}
}
Por último, vamos a escribir una prueba más que use nuestro método asincrónico para asegurarse de que la
infraestructura asincrónica incluida en TestDbSet funciona.
using System.Linq;
{
[TestClass]
public class AsyncQueryTests
{
[TestMethod]
public async Task GetAllBlogsAsync_orders_by_name()
{
context.Blogs.Add(new Blog { Name = "BBB" });
context.Blogs.Add(new Blog { Name = "ZZZ" });
context.Blogs.Add(new Blog { Name = "AAA" });

var blogs = await service.GetAllBlogsAsync();
}
}
}
Capacidad de prueba y Entity Framework 4,0
Scott Allen
Publicación: mayo de 2010
Introducción
En estas notas del producto se describe y se muestra cómo escribir código que se pueda probar con ADO.NET
Entity Framework 4,0 y Visual Studio 2010. Este documento no intenta centrarse en una metodología de prueba
específica, como el diseño basado en pruebas (TDD) o el diseño controlado por comportamientos (BDD). En su
lugar, este documento se centrará en cómo escribir código que use el Entity Framework de ADO.NET, pero sigue
siendo fácil aislar y probar de forma automatizada. Veremos patrones de diseño comunes que facilitan las pruebas
en escenarios de acceso a datos y ven cómo aplicar esos patrones al usar el marco de trabajo. También veremos
características específicas del marco de trabajo para ver cómo estas características pueden funcionar en código
comprobable.
¿Qué es el código que se pueda probar?

La capacidad de comprobar una parte del software mediante pruebas unitarias automatizadas ofrece muchas
ventajas deseadas. Todo el mundo sabe que las buenas pruebas reducirán el número de defectos de software de
una aplicación y aumentarán la calidad de la aplicación, pero si tiene pruebas unitarias en su lugar, más allá de
buscar errores.
Un buen conjunto de pruebas unitarias permite que un equipo de desarrollo Ahorre tiempo y mantenga el control
del software que crean. Un equipo puede realizar cambios en el código existente, refactorizar, rediseñar y
reestructurar el software para cumplir los requisitos nuevos y agregar nuevos componentes a una aplicación, al
tiempo que sabe que el conjunto de pruebas puede comprobar el comportamiento de la aplicación. Las pruebas
unitarias forman parte de un ciclo de comentarios rápido para facilitar el cambio y preservar el mantenimiento del
software a medida que aumenta la complejidad.
Sin embargo, las pruebas unitarias incluyen un precio. Un equipo tiene que invertir el tiempo de creación y
mantenimiento de las pruebas unitarias. La cantidad de esfuerzo necesaria para crear estas pruebas está
directamente relacionada con la capacidad de prueba del software subyacente. ¿Es fácil probar el software? Un
equipo que diseñe software con capacidad de prueba en mente creará pruebas eficaces más rápido que el equipo
que trabaja con un software no comprobable.
Microsoft diseñó el ADO.NET Entity Framework 4,0 (EF4), teniendo en cuenta la capacidad de prueba. Esto no
significa que los desarrolladores vayan a escribir pruebas unitarias en el propio código del marco. En su lugar, los
objetivos de capacidad de prueba de EF4 facilitan la creación de código comprobable que se basa en el marco de
trabajo. Antes de ver ejemplos específicos, merece la pena comprender las cualidades del código comprobable.
Las cualidades del código comprobable
El código que es fácil de probar siempre presentará al menos dos rasgos. En primer lugar, el código comprobable
se obser va fácilmente. Dado un conjunto de entradas, debe ser fácil observar la salida del código. Por ejemplo, es
fácil probar el método siguiente porque el método devuelve directamente el resultado de un cálculo.
public int Add(int x, int y) {
return x + y;
}
Probar un método es difícil si el método escribe el valor calculado en un socket de red, una tabla de base de datos o
un archivo como el código siguiente. La prueba tiene que realizar trabajo adicional para recuperar el valor.
public void AddAndSaveToFile(int x, int y) {

var results = string.Format("The answer is {0}", x + y);
File.WriteAllText("results.txt", results);
}
En segundo lugar, el código comprobable es fácil de aislar . Vamos a usar el siguiente pseudocódigo como ejemplo
incorrecto de código comprobable.
public int ComputePolicyValue(InsurancePolicy policy) {

using (var connection = new SqlConnection("dbConnection"))
using (var command = new SqlCommand(query, connection)) {
// business calculations omitted ...
if (totalValue > notificationThreshold) {

var message = new MailMessage();
message.Subject = "Warning!";
var client = new SmtpClient();
client.Send(message);
}
}
return totalValue;
}
El método es fácil de observar: podemos pasar una directiva de seguros y comprobar que el valor devuelto
coincide con un resultado esperado. Sin embargo, para probar el método, es necesario tener una base de datos de
instalada con el esquema correcto y configurar el servidor SMTP en caso de que el método intente enviar un correo
electrónico.
La prueba unitaria solo desea comprobar la lógica de cálculo dentro del método, pero puede producirse un error en
la prueba porque el servidor de correo electrónico está sin conexión o porque se ha desconectado el servidor de
base de datos. Ambos errores no están relacionados con el comportamiento que la prueba desea comprobar. Es
difícil aislar el comportamiento.
Los desarrolladores de software que se esfuerzan por escribir código comprobable a menudo esfuerzan por
mantener una separación de preocupaciones en el código que escriben. El método anterior debe centrarse en los
cálculos empresariales y delegar la base de datos y los detalles de implementación de correo electrónico a otros
componentes. Robert C. Martin llama a este principio de responsabilidad única. Un objeto debe encapsular una
única responsabilidad estrecha, como calcular el valor de una directiva. El resto de la base de datos y el trabajo de
notificación deben ser responsabilidad de algún otro objeto. El código escrito de este modo es más fácil de aislar
porque se centra en una sola tarea.
En .NET tenemos las abstracciones que necesitamos seguir el principio de responsabilidad única y conseguir el
aislamiento. Podemos usar las definiciones de interfaz y forzar que el código use la abstracción de la interfaz en
lugar de un tipo concreto. Más adelante en este documento veremos cómo un método como el ejemplo incorrecto
presentado anteriormente puede funcionar con interfaces que parecen que se comunicarán con la base de datos.
Sin embargo, en el momento de la prueba, podemos sustituir una implementación ficticia que no se comunica con
la base de datos, sino que almacena los datos en la memoria. Esta implementación ficticia aislará el código de
problemas no relacionados en el código de acceso a datos o la configuración de la base de datos.
Existen ventajas adicionales para el aislamiento. El cálculo empresarial en el último método solo debe tardar unos
milisegundos en ejecutarse, pero la propia prueba podría ejecutarse durante varios segundos a medida que el
código se salto alrededor de la red y se comunique con varios servidores. Las pruebas unitarias se deben ejecutar
rápidamente para facilitar pequeños cambios. Las pruebas unitarias también se deben repetir y no generar un error
porque un componente no relacionado con la prueba tiene un problema. Escribir código que sea fácil de observar y
aislar significa que los desarrolladores tendrán un tiempo más sencillo escribiendo las pruebas para el código,
dedique menos tiempo a esperar a que se ejecuten las pruebas y, lo que es más importante, dedique menos tiempo
a realizar un seguimiento de los errores que no existen.
Espero que pueda apreciar las ventajas de las pruebas y comprender las cualidades que exhibe el código. Estamos a
punto de tratar cómo escribir código que funcione con EF4 para guardar datos en una base de datos, mientras que
el resto es visible y fácil aislar, pero en primer lugar limitaremos nuestro enfoque para analizar los diseños que se
pueden probar para el acceso a los datos.
Modelos de diseño para la persistencia de datos

Los dos ejemplos no válidos que se presentaron anteriormente tenían demasiadas responsabilidades. El primer
ejemplo incorrecto tenía que realizar un cálculo y escribir en un archivo. El segundo ejemplo incorrecto tenía que
leer los datos de una base de datos y realizar un cálculo empresarial y enviar un correo electrónico. Al diseñar
métodos más pequeños que separan los problemas y delegar la responsabilidad en otros componentes, hará
grandes progresos en la escritura de código comprobable. El objetivo es crear la funcionalidad mediante la
composición de acciones a partir de abstracciones pequeñas y centradas.
En cuanto a la persistencia de los datos, las abstracciones pequeñas y centradas que se buscan son tan comunes
que se han documentado como modelos de diseño. Los patrones de libros de Martin Fowler de la arquitectura de
aplicaciones empresariales fueron el primer trabajo para describir estos patrones en la impresión.
Proporcionaremos una breve descripción de estos patrones en las secciones siguientes antes de mostrar cómo
estos ADO.NET Entity Framework implementan y funcionan con estos patrones.
The Repository Pattern (El modelo de repositorio )
Fowler indica un repositorio "media entre las capas de asignación de datos y dominio mediante una interfaz similar
a la colección para tener acceso a los objetos de dominio". El objetivo del patrón de repositorio es aislar el código
del Minutiae de acceso a datos y, como vimos, el aislamiento anterior es un rasgo necesario para la prueba.
La clave del aislamiento es cómo expone los objetos el repositorio mediante una interfaz similar a la de una
colección. La lógica que escriba para usar el repositorio no tiene ninguna idea de cómo el repositorio materializará
los objetos que solicite. El repositorio puede comunicarse con una base de datos o simplemente devolver objetos
de una colección en memoria. Todo el código debe saber que el repositorio parece mantener la colección, y puede
recuperar, agregar y eliminar objetos de la colección.
En las aplicaciones .NET existentes, un repositorio concreto a menudo hereda de una interfaz genérica como la
siguiente:
public interface IRepository<T> {

IEnumerable<T> FindAll();
IEnumerable<T> FindBy(Expression<Func\<T, bool>> predicate);
T FindById(int id);
void Add(T newEntity);
void Remove(T entity);
}
Realizaremos algunos cambios en la definición de interfaz cuando se proporciona una implementación para EF4,
pero el concepto básico sigue siendo el mismo. El código puede usar un repositorio concreto que implemente esta
interfaz para recuperar una entidad por su valor de clave principal, para recuperar una colección de entidades en
función de la evaluación de un predicado, o simplemente para recuperar todas las entidades disponibles. El código
también puede Agregar y quitar entidades a través de la interfaz del repositorio.
Dado un IRepository de objetos de empleado, el código puede realizar las siguientes operaciones.
var employeesNamedScott =
repository
.FindBy(e => e.Name == "Scott")
.OrderBy(e => e.HireDate);
var firstEmployee = repository.FindById(1);
var newEmployee = new Employee() {/*... */};
repository.Add(newEmployee);
Dado que el código está usando una interfaz (IRepository de Employee), podemos proporcionar el código con
diferentes implementaciones de la interfaz. Una implementación puede ser una implementación respaldada por
EF4 y almacenar objetos en una base de datos Microsoft SQL Server. Una implementación diferente (una que
usamos durante las pruebas) puede estar respaldada por una lista en memoria de objetos de empleado. La interfaz
le ayudará a lograr el aislamiento en el código.
Observe que la interfaz IRepository<T> no expone una operación de guardar. ¿Cómo se actualizan los objetos
existentes? Puede que se encuentre entre las definiciones de IRepository que incluyen la operación de guardar, y las
implementaciones de estos repositorios deberán conservar de forma inmediata un objeto en la base de datos. Sin
embargo, en muchas aplicaciones no queremos conservar los objetos individualmente. En su lugar, queremos traer
objetos a la vida, quizás desde diferentes repositorios, modificar esos objetos como parte de una actividad
económica y, a continuación, conservar todos los objetos como parte de una única operación atómica.
Afortunadamente, hay un patrón que permite este tipo de comportamiento.
Patrón de unidad de trabajo
Fowler indica que una unidad de trabajo "mantendrá una lista de objetos afectados por una transacción
empresarial y coordina la escritura de los cambios y la resolución de los problemas de simultaneidad". Es
responsabilidad de la unidad de trabajo realizar un seguimiento de los cambios en los objetos que aportamos a la
vida desde un repositorio y que conservan los cambios realizados en los objetos cuando se indica a la unidad de
trabajo que confirme los cambios. También es responsabilidad de la unidad de trabajo realizar los nuevos objetos
que hemos agregado a todos los repositorios e insertar los objetos en una base de datos, así como administrar la
eliminación.
Si alguna vez ha realizado algún trabajo con conjuntos de valores de ADO.NET, ya estará familiarizado con el patrón
de unidad de trabajo. Los conjuntos de datos de ADO.NET tenían la capacidad de realizar un seguimiento de las
actualizaciones, eliminaciones e inserción de objetos DataRow y podrían (con la ayuda de un TableAdapter) conciliar
todos los cambios en una base de datos. Sin embargo, los objetos DataSet modelan un subconjunto desconectado
de la base de datos subyacente. El patrón de unidad de trabajo exhibe el mismo comportamiento, pero funciona
con objetos de negocio y objetos de dominio que están aislados del código de acceso a datos y sin tener en cuenta
la base de datos.
Una abstracción para modelar la unidad de trabajo en código .NET podría ser similar a la siguiente:
public interface IUnitOfWork {

IRepository<Employee> Employees { get; }
IRepository<Order> Orders { get; }
IRepository<Customer> Customers { get; }
void Commit();
}
Al exponer las referencias del repositorio a partir de la unidad de trabajo, se puede asegurar de que un solo objeto
de unidad de trabajo tiene la capacidad de realizar un seguimiento de todas las entidades materializadas durante
una transacción empresarial. La implementación del método commit para una unidad de trabajo real es donde se
produce toda la instrucción mágica para conciliar los cambios en memoria con la base de datos.
Dada una referencia IUnitOfWork, el código puede realizar cambios en los objetos comerciales recuperados de uno
o varios repositorios y guardar todos los cambios mediante la operación de confirmación atómica.
var firstEmployee = unitofWork.Employees.FindById(1);

var firstCustomer = unitofWork.Customers.FindById(1);
firstEmployee.Name = "Alex";
firstCustomer.Name = "Christopher";
unitofWork.Commit();
El modelo de carga diferida

Fowler usa el nombre Lazy LOAD para describir "un objeto que no contiene todos los datos que necesita, pero sabe
cómo obtenerlo". La carga diferida transparente es una característica importante que se debe tener al escribir
código empresarial comprobable y al trabajar con una base de datos relacional. Como ejemplo, considere el
siguiente código.
var employee = repository.FindById(id);

// ... and later ...
foreach(var timeCard in employee.TimeCards) {
// .. manipulate the timeCard
}
¿Cómo se rellena la colección de tarjetas de horas? Hay dos posibles respuestas. Una respuesta es que el
repositorio del empleado, cuando se le pide que capture un empleado, emite una consulta para recuperar el
empleado junto con la información de la tarjeta de tiempo asociada al empleado. En las bases de datos relacionales,
esto normalmente requiere una consulta con una cláusula JOIN y puede dar lugar a la recuperación de más
información de la que necesita una aplicación. ¿Qué ocurre si la aplicación no necesita tocar la propiedad de las
tarjetas de información.
Una segunda respuesta es cargar la propiedad "a petición" de las tarjetas de horas. Esta carga diferida es implícita y
transparente para la lógica de negocios, ya que el código no invoca API especiales para recuperar la información de
la tarjeta de tiempo. El código asume que la información de la tarjeta de tiempo está presente cuando sea
necesario. Hay una especial participación en la carga diferida que generalmente implica la interceptación en tiempo
de ejecución de las invocaciones de método. El código de interceptación es responsable de comunicarse con la base
de datos y recuperar la información de la tarjeta de tiempo, a la vez que la lógica de negocios queda libre para ser
lógica empresarial. Esta magia de carga diferida permite al código de negocio aislarse de las operaciones de
recuperación de datos y da como resultado un código más comprobable.
El inconveniente de una carga diferida es que cuando una aplicación necesita la información de la tarjeta de tiempo,
el código ejecutará una consulta adicional. Esto no supone un problema para muchas aplicaciones, pero para las
aplicaciones o aplicaciones sensibles al rendimiento se repiten por un número de objetos de empleado y la
ejecución de una consulta para recuperar las tarjetas de tiempo durante cada iteración del bucle (un problema que
se suele denominar N + 1 problema de consulta), la carga diferida es un arrastre. En estos escenarios, es posible
que una aplicación quiera cargar la información de la tarjeta de tiempo de la manera más eficaz posible.
Afortunadamente, veremos cómo EF4 admite las cargas diferidas implícitas y las cargas diligentes eficaces a
medida que avanzamos en la siguiente sección e implementamos estos patrones.
Implementar patrones con el Entity Framework

La buena noticia es que todos los patrones de diseño que se describen en la última sección son sencillos de
implementar con EF4. Para demostrar que vamos a usar una sencilla aplicación ASP.NET MVC para editar y mostrar
los empleados y la información de su tarjeta de tiempo asociada. Comenzaremos usando los siguientes "objetos
CLR antiguos sin formato" (POCO).
public class Employee {
public DateTime HireDate { get; set; }
public ICollection<TimeCard> TimeCards { get; set; }
}
public class TimeCard {

public int Hours { get; set; }
public DateTime EffectiveDate { get; set; }
}
Estas definiciones de clase cambiarán ligeramente a medida que exploramos diferentes enfoques y características
de EF4, pero el objetivo es mantener estas clases como la persistencia ignorada (PI) como sea posible. Un objeto PI
no sabe Cómo, o incluso si, el estado que contiene reside en una base de datos. PI y POCO go están a mano con el
software que se pueda probar. Los objetos que usan un enfoque POCO son menos restrictivos, más flexibles y
fáciles de probar porque pueden funcionar sin una base de datos presente.
Con los POCO en vigor, podemos crear un Entity Data Model (EDM) en Visual Studio (vea la ilustración 1). No
usaremos el EDM para generar código para nuestras entidades. En su lugar, queremos usar las entidades que
lovinglymos de forma manual. Solo usaremos el EDM para generar el esquema de la base de datos y proporcionar
los metadatos que EF4 necesita para asignar objetos a la base de datos.
Ilustración 1
Nota: Si desea desarrollar el modelo EDM en primer lugar, es posible generar código limpio y POCO a partir del
EDM. Puede hacerlo con una extensión de Visual Studio 2010 proporcionada por el equipo de programación de
datos. Para descargar la extensión, inicie el administrador de extensiones desde el menú herramientas de Visual
Studio y busque "POCO" en la galería en línea de plantillas (consulte la figura 2). Hay varias plantillas POCO
disponibles para EF. Para obtener más información sobre el uso de la plantilla, vea " Tutorial: poco plantilla para el
Entity Framework".
Ilustración 2
Desde este punto de partida POCO, exploraremos dos enfoques diferentes para el código comprobable. El primer
enfoque que se llama al enfoque EF porque aprovecha las abstracciones de la API de Entity Framework para
implementar unidades de trabajo y repositorios. En el segundo enfoque, crearemos nuestras propias abstracciones
de repositorio personalizadas y, a continuación, veremos las ventajas y desventajas de cada enfoque.
Comenzaremos explorando el enfoque de EF.
Una implementación centrada en EF
Considere la siguiente acción del controlador de un proyecto de MVC de ASP.NET. La acción recupera un objeto de
empleado y devuelve un resultado para mostrar una vista detallada del empleado.
public ViewResult Details(int id) {

var employee = _unitOfWork.Employees
.Single(e => e.Id == id);
return View(employee);
}
¿Se va a probar el código? Hay al menos dos pruebas que necesitamos para comprobar el comportamiento de la
acción. En primer lugar, nos gustaría comprobar que la acción devuelve la vista correcta (una prueba sencilla).
También deseamos escribir una prueba para comprobar que la acción recupera el empleado correcto y nos gustaría
hacerlo sin ejecutar código para consultar la base de datos. Recuerde que queremos aislar el código sometido a
prueba. El aislamiento garantizará que la prueba no produzca un error debido a un error en el código de acceso a
datos o la configuración de la base de datos. Si se produce un error en la prueba, se sabrá que tenemos un error en
la lógica del controlador y no en un componente del sistema de nivel inferior.
Para lograr el aislamiento, necesitamos algunas abstracciones como las interfaces que presentamos anteriormente
para los repositorios y las unidades de trabajo. Recuerde que el patrón de repositorio está diseñado para mediar
entre objetos de dominio y la capa de asignación de datos. En este escenario, EF4 es la capa de asignación de datos
y ya proporciona una abstracción similar a la del repositorio denominada IObjectSet<t> (del espacio de nombres
System. Data. Objects). La definición de la interfaz es similar a la siguiente.
public interface IObjectSet<TEntity> :
IQueryable<TEntity>,
IEnumerable<TEntity>,
IQueryable,
IEnumerable
where TEntity : class
{
void AddObject(TEntity entity);
void Attach(TEntity entity);
void DeleteObject(TEntity entity);
void Detach(TEntity entity);
}
IObjectSet<T> cumple los requisitos de un repositorio porque se parece a una colección de objetos (a través de
IEnumerable<T>) y proporciona métodos para agregar y quitar objetos de la colección simulada. Los métodos
Attach y detach exponen funcionalidades adicionales de la API de EF4. Para usar IObjectSet<T> como la interfaz de
los repositorios, se necesita una abstracción de unidad de trabajo para enlazar repositorios juntos.

IObjectSet<Employee> Employees { get; }
IObjectSet<TimeCard> TimeCards { get; }
void Commit();
}
Una implementación concreta de esta interfaz se comunicará con SQL Server y es fácil de crear mediante la clase
ObjectContext desde EF4. La clase ObjectContext es la unidad real de trabajo de la API de EF4.
public class SqlUnitOfWork : IUnitOfWork {

public SqlUnitOfWork() {
var connectionString =
ConfigurationManager
.ConnectionStrings[ConnectionStringName]
.ConnectionString;
_context = new ObjectContext(connectionString);
}
public IObjectSet<Employee> Employees {

get { return _context.CreateObjectSet<Employee>(); }
}
public IObjectSet<TimeCard> TimeCards {

get { return _context.CreateObjectSet<TimeCard>(); }
}
public void Commit() {

}
readonly ObjectContext _context;

const string ConnectionStringName = "EmployeeDataModelContainer";
}
Poner un IObjectSet<T> a la vida es tan sencillo como invocar el método método createobjectset del objeto
ObjectContext. En segundo plano, el marco de trabajo usará los metadatos proporcionados en el EDM para generar
un ObjectSet concreto<T>. Nos centraremos en la devolución de la interfaz IObjectSet<T> porque le ayudará a
mantener la capacidad de prueba en el código de cliente.
Esta implementación concreta es útil en producción, pero es necesario centrarnos en cómo usaremos nuestra
abstracción IUnitOfWork para facilitar las pruebas.
La prueba se duplica
Para aislar la acción del controlador, se necesita la capacidad de cambiar entre la unidad de trabajo real (respaldada
por un ObjectContext) y una unidad de trabajo de prueba doble o "falsa" (realizando operaciones en memoria). El
método común para realizar este tipo de conmutación es no permitir que el controlador de MVC cree una instancia
de una unidad de trabajo, sino que en su lugar pasa la unidad de trabajo al controlador como un parámetro de
constructor.
class EmployeeController : Controller {

publicEmployeeController(IUnitOfWork unitOfWork) {
_unitOfWork = unitOfWork;
}
...
}
El código anterior es un ejemplo de inserción de dependencias. No permitimos que el controlador cree su

dependencia (la unidad de trabajo), sino que inserte la dependencia en el controlador. En un proyecto de MVC, es
habitual usar un generador de controlador personalizado en combinación con un contenedor de inversión de
control (IoC) para automatizar la inserción de dependencias. Estos temas están fuera del ámbito de este artículo,
pero puede leer más mediante las referencias que se indican al final de este artículo.
Una implementación de unidad de trabajo falsa que se puede usar para las pruebas podría ser similar a la
siguiente.
public class InMemoryUnitOfWork : IUnitOfWork {

public InMemoryUnitOfWork() {
Committed = false;
}
public IObjectSet<Employee> Employees {
get;
set;
}
public IObjectSet<TimeCard> TimeCards {

get;
set;
}
public bool Committed { get; set; }

Committed = true;
}
}
Observe que la unidad de trabajo falsa expone una propiedad confirmada. A veces resulta útil agregar
características a una clase falsa que facilitan las pruebas. En este caso, es fácil observar si el código confirma una
unidad de trabajo mediante la comprobación de la propiedad confirmada.
También se necesitará una<falsa IObjectSet> para almacenar los objetos de la tarjeta de la Se puede proporcionar
una implementación única mediante genéricos.
public class InMemoryObjectSet<T> : IObjectSet<T> where T : class
public InMemoryObjectSet()
: this(Enumerable.Empty<T>()) {
}
public InMemoryObjectSet(IEnumerable<T> entities) {
_set = new HashSet<T>();
foreach (var entity in entities) {
_set.Add(entity);
}
_queryableSet = _set.AsQueryable();
}
public void AddObject(T entity) {
_set.Add(entity);
}
public void Attach(T entity) {
_set.Add(entity);
}
public void DeleteObject(T entity) {
_set.Remove(entity);
}
public void Detach(T entity) {
_set.Remove(entity);
}
public Type ElementType {
get { return _queryableSet.ElementType; }
}
public Expression Expression {
get { return _queryableSet.Expression; }
}
public IQueryProvider Provider {
get { return _queryableSet.Provider; }
}
public IEnumerator<T> GetEnumerator() {
return _set.GetEnumerator();
}
IEnumerator IEnumerable.GetEnumerator() {
return GetEnumerator();
}
readonly HashSet<T> _set;

readonly IQueryable<T> _queryableSet;
}
Esta prueba Double delega la mayor parte de su trabajo en un objeto de> HashSet<T subyacente. Tenga en cuenta
que IObjectSet<T> requiere una restricción genérica que aplique T como clase (un tipo de referencia) y también
obliga a implementar IQueryable<T>. Es fácil hacer que una colección en memoria aparezca como IQueryable<T>
mediante el operador estándar LINQ que se pueda consultar.
Las pruebas
Las pruebas unitarias tradicionales usarán una sola clase de prueba para contener todas las pruebas de todas las
acciones en un solo controlador de MVC. Podemos escribir estas pruebas, o cualquier tipo de prueba unitaria,
mediante el uso de las falsificaciones de memoria que hemos creado. Sin embargo, en este artículo se evitará el
enfoque de la clase de prueba monolítica y, en su lugar, se agruparán las pruebas para centrarse en una parte
específica de la funcionalidad. Por ejemplo, "crear nuevo empleado" podría ser la funcionalidad que queremos
probar, por lo que usaremos una sola clase de prueba para comprobar la acción de controlador único responsable
de crear un nuevo empleado.
Hay algún código de instalación común que necesitamos para todas estas clases de prueba concretas. Por ejemplo,
siempre tenemos que crear los repositorios en memoria y la unidad de trabajo falsa. También se necesita una
instancia del controlador de empleados con la unidad falsa de trabajo insertada. Se compartirá este código de
instalación común en todas las clases de prueba mediante una clase base.
public class EmployeeControllerTestBase {
public EmployeeControllerTestBase() {
_employeeData = EmployeeObjectMother.CreateEmployees()
.ToList();
_repository = new InMemoryObjectSet<Employee>(_employeeData);
_unitOfWork = new InMemoryUnitOfWork();
_unitOfWork.Employees = _repository;
_controller = new EmployeeController(_unitOfWork);
}
protected IList<Employee> _employeeData;

protected EmployeeController _controller;
protected InMemoryObjectSet<Employee> _repository;
protected InMemoryUnitOfWork _unitOfWork;
}
El "objeto madre" que usamos en la clase base es un patrón común para crear datos de prueba. Un objeto Mother
contiene métodos de generador para crear instancias de entidades de prueba para su uso en varios extras de
prueba.
public static class EmployeeObjectMother {

public static IEnumerable<Employee> CreateEmployees() {
yield return new Employee() {
Id = 1, Name = "Scott", HireDate=new DateTime(2002, 1, 1)
};
Id = 2, Name = "Poonam", HireDate=new DateTime(2001, 1, 1)
};
Id = 3, Name = "Simon", HireDate=new DateTime(2008, 1, 1)
};
}
// ... more fake data for different scenarios
}
Podemos usar EmployeeControllerTestBase como la clase base para una serie de accesorios de prueba (vea la
figura 3). Cada accesorio de prueba probará una acción de controlador específica. Por ejemplo, un accesorio de
prueba se centrará en probar la acción de creación que se usa durante una solicitud GET de HTTP (para mostrar la
vista de creación de un empleado) y otro accesorio se centrará en la acción de creación usada en una solicitud HTTP
POST (para tomar la información enviada por el usuario para crear un empleado). Cada clase derivada solo es
responsable de la configuración necesaria en su contexto específico y de proporcionar las aserciones necesarias
para comprobar los resultados de su contexto de prueba específico.
Ilustración 3
La Convención de nomenclatura y el estilo de prueba presentados aquí no son necesarios para el código
comprobable, sino solo un enfoque. En la figura 4 se muestran las pruebas que se ejecutan en el complemento del
Ejecutor de pruebas de jet cerebro ReSharper para Visual Studio 2010.
Ilustración 4
Con una clase base para controlar el código compartido de la instalación, las pruebas unitarias para cada acción de
controlador son pequeñas y fáciles de escribir. Las pruebas se ejecutarán rápidamente (dado que se están
realizando operaciones en memoria) y no se debería producir un error debido a la infraestructura no relacionada o
a problemas ambientales (porque hemos aislado la unidad en pruebas).
[TestClass]
public class EmployeeControllerCreateActionPostTests
: EmployeeControllerTestBase {
[TestMethod]
public void ShouldAddNewEmployeeToRepository() {
_controller.Create(_newEmployee);
Assert.IsTrue(_repository.Contains(_newEmployee));
}
[TestMethod]
public void ShouldCommitUnitOfWork() {
Assert.IsTrue(_unitOfWork.Committed);
}
// ... more tests
Employee _newEmployee = new Employee() {

Name = "NEW EMPLOYEE",
HireDate = new System.DateTime(2010, 1, 1)
};
}
En estas pruebas, la clase base realiza la mayor parte del trabajo de configuración. Recuerde que el constructor de
clase base crea el repositorio en memoria, una unidad de trabajo falsa y una instancia de la clase
EmployeeController. La clase de prueba se deriva de esta clase base y se centra en los detalles de la prueba del
método Create. En este caso, las características específicas se reducen a los pasos "Arrange, Act y Assert" que verá
en cualquier procedimiento de prueba unitaria:
Cree un objeto newEmployee para simular los datos entrantes.
Invocar la acción de creación de EmployeeController y pasar newEmployee.
Compruebe que la acción crear produce los resultados esperados (el empleado aparece en el repositorio).
Lo que hemos creado nos permite probar cualquiera de las acciones de EmployeeController. Por ejemplo, cuando
se escriben pruebas para la acción de índice del controlador de empleado, se puede heredar de la clase base de
prueba para establecer la misma configuración base para nuestras pruebas. De nuevo, la clase base creará el
repositorio en memoria, la unidad de trabajo falsa y una instancia de EmployeeController. Las pruebas para la
acción de índice solo deben centrarse en la invocación de la acción de índice y en la prueba de las cualidades del
modelo que devuelve la acción.
[TestClass]
public class EmployeeControllerIndexActionTests
[TestMethod]
public void ShouldBuildModelWithAllEmployees() {
var result = _controller.Index();
var model = result.ViewData.Model
as IEnumerable<Employee>;
Assert.IsTrue(model.Count() == _employeeData.Count);
}
[TestMethod]
public void ShouldOrderModelByHiredateAscending() {
Assert.IsTrue(model.SequenceEqual(
_employeeData.OrderBy(e => e.HireDate)));
}
// ...
}
Las pruebas que creamos con las falsificaciones en memoria están orientadas a probar el Estado del software. Por
ejemplo, al probar la acción de creación, queremos inspeccionar el estado del repositorio después de que se ejecute
la acción de creación: ¿el repositorio mantiene el nuevo empleado?
[TestMethod]
public void ShouldAddNewEmployeeToRepository() {
Assert.IsTrue(_repository.Contains(_newEmployee));
}
Más adelante veremos las pruebas basadas en la interacción. Las pruebas basadas en interacción le preguntarán si
el código sometido a prueba invocó los métodos adecuados en nuestros objetos y pasa los parámetros correctos.
Por ahora, pasaremos a la portada otro patrón de diseño: la carga diferida.
Carga diligente y carga diferida

En algún momento de la aplicación web MVC de ASP.NET podríamos querer Mostrar la información de un
empleado e incluir las tarjetas de tiempo asociadas del empleado. Por ejemplo, es posible que tengamos una
pantalla de Resumen de tarjeta de tiempo que muestre el nombre del empleado y el número total de tarjetas de
tiempo del sistema. Existen varios enfoques que se pueden seguir para implementar esta característica.
Proyección
Un enfoque sencillo para crear el resumen es construir un modelo dedicado a la información que queremos
mostrar en la vista. En este escenario, el modelo podría ser similar al siguiente.
public class EmployeeSummaryViewModel {
public int TotalTimeCards { get; set; }
}
Tenga en cuenta que EmployeeSummaryViewModel no es una entidad; es decir, no es algo que queremos
conservar en la base de datos. Solo vamos a usar esta clase para ordenar los datos en la vista de forma
fuertemente tipada. El modelo de vista es como un objeto de transferencia de datos (DTO) porque no contiene
ningún comportamiento (sin métodos): solo propiedades. Las propiedades contendrán los datos que necesitamos
trasladar. Es fácil crear instancias de este modelo de vista mediante el operador de proyección estándar de LINQ: el
operador Select.
public ViewResult Summary(int id) {

var model = _unitOfWork.Employees
.Where(e => e.Id == id)
.Select(e => new EmployeeSummaryViewModel
{
Name = e.Name,
TotalTimeCards = e.TimeCards.Count()
})
.Single();
return View(model);
}
Hay dos características importantes para el código anterior. En primer lugar, el código es fácil de probar porque
todavía es fácil de observar y aislar. El operador Select funciona igual que en las falsificaciones en memoria que en
la unidad de trabajo real.
[TestClass]
public class EmployeeControllerSummaryActionTests
[TestMethod]
public void ShouldBuildModelWithCorrectEmployeeSummary() {
var id = 1;
var result = _controller.Summary(id);
var model = result.ViewData.Model as EmployeeSummaryViewModel;
Assert.IsTrue(model.TotalTimeCards == 3);
}
// ...
}
La segunda característica importante es la forma en que el código permite a EF4 generar una consulta única y
eficaz para ensamblar la información de los empleados y la tarjeta de tiempo conjuntamente. Hemos cargado
información de empleados e información de la tarjeta de tiempo en el mismo objeto sin usar ninguna API especial.
El código simplemente expresó la información necesaria para usar operadores LINQ estándar que funcionan con
orígenes de datos en memoria y con orígenes de datos remotos. EF4 pudo traducir los árboles de expresión
generados por la consulta LINQ y C# compilador en una consulta T-SQL eficaz y única.
SELECT
[Limit1].[Id] AS [Id],
[Limit1].[Name] AS [Name],
[Limit1].[C1] AS [C1]
FROM (SELECT TOP (2)
[Project1].[Id] AS [Id],
[Project1].[Name] AS [Name],
[Project1].[C1] AS [C1]
FROM (SELECT
[Extent1].[Name] AS [Name],
(SELECT COUNT(1) AS [A1]
FROM [dbo].[TimeCards] AS [Extent2]
WHERE [Extent1].[Id] =
[Extent2].[EmployeeTimeCard_TimeCard_Id]) AS [C1]
FROM [dbo].[Employees] AS [Extent1]
WHERE [Extent1].[Id] = @p__linq__0
) AS [Project1]
) AS [Limit1]
Hay otras ocasiones en las que no se desea trabajar con un modelo de vista o un objeto DTO, sino con entidades
reales. Cuando sabemos que necesitamos un empleado y las tarjetas de tiempo del empleado, podemos cargar
diligentemente los datos relacionados de manera discreta y eficaz.
Carga diligente explícita
Cuando queremos cargar diligentemente la información relacionada de la entidad, necesitamos algún mecanismo
para la lógica de negocios (o en este escenario, la lógica de acción del controlador) para expresar su deseo en el
repositorio. La clase EF4 ObjectQuery<T> define un método include para especificar los objetos relacionados que
se van a recuperar durante una consulta. Recuerde que EF4 ObjectContext expone entidades a través de la clase>
de ObjectSet<T concreta, que hereda de ObjectQuery<T>. Si usamos las referencias de ObjectSet<T> en nuestra
acción del controlador, podríamos escribir el código siguiente para especificar una carga diligente de información
de la tarjeta de tiempo para cada empleado.
_employees.Include("TimeCards")
.Where(e => e.HireDate.Year > 2009);
Sin embargo, puesto que estamos intentando mantener el código comprobable, no exponemos el ObjectSet<T>
desde fuera de la clase real de la unidad de trabajo. En su lugar, confiamos en la interfaz IObjectSet<T> que es más
fácil de falsificar, pero IObjectSet<T> no define un método include. La belleza de LINQ es que podemos crear
nuestro propio operador include.
public static class QueryableExtensions {

public static IQueryable<T> Include<T>
(this IQueryable<T> sequence, string path) {
var objectQuery = sequence as ObjectQuery<T>;
if(objectQuery != null)
{
return objectQuery.Include(path);
}
return sequence;
}
}
Observe que este operador include está definido como método de extensión para IQueryable<T> en lugar de
IObjectSet<T>. Esto nos da la posibilidad de usar el método con una gama más amplia de tipos posibles, incluidos
IQueryable<T>, IObjectSet<T>, ObjectQuery<T>y ObjectSet<T>. En el caso de que la secuencia subyacente no sea
una EF4 genuina<T>, no se produce ningún daño y el operador include es una operación no operativa. Si la
secuencia subyacente es un> de ObjectQuery<t (o derivado de ObjectQuery<t>), EF4 verá nuestro requisito de
datos adicionales y formulará la consulta SQL adecuada.
Con este nuevo operador en su lugar, podemos solicitar explícitamente una carga diligente de información de la
tarjeta de tiempo del repositorio.
public ViewResult Index() {

var model = _unitOfWork.Employees
.Include("TimeCards")
return View(model);
}
Cuando se ejecuta en un ObjectContext real, el código genera la siguiente consulta única. La consulta recopila
suficiente información de la base de datos en un recorrido para materializar los objetos de empleado y rellenar
completamente su propiedad de tarjetas de seguridad.
SELECT
[Project1].[Id] AS [Id],
[Project1].[Name] AS [Name],
[Project1].[HireDate] AS [HireDate],
[Project1].[Id1] AS [Id1],
[Project1].[Hours] AS [Hours],
[Project1].[EffectiveDate] AS [EffectiveDate],
[Project1].[EmployeeTimeCard_TimeCard_Id] AS [EmployeeTimeCard_TimeCard_Id]
FROM ( SELECT
[Extent1].[Name] AS [Name],
[Extent1].[HireDate] AS [HireDate],
[Extent2].[Id] AS [Id1],
[Extent2].[Hours] AS [Hours],
[Extent2].[EffectiveDate] AS [EffectiveDate],
[Extent2].[EmployeeTimeCard_TimeCard_Id] AS
[EmployeeTimeCard_TimeCard_Id],
CASE WHEN ([Extent2].[Id] IS NULL) THEN CAST(NULL AS int)
ELSE 1 END AS [C1]
FROM [dbo].[Employees] AS [Extent1]
LEFT OUTER JOIN [dbo].[TimeCards] AS [Extent2] ON [Extent1].[Id] = [Extent2].
[EmployeeTimeCard_TimeCard_Id]
) AS [Project1]
ORDER BY [Project1].[HireDate] ASC,
[Project1].[Id] ASC, [Project1].[C1] ASC
La gran noticia es que el código dentro del método de acción sigue siendo totalmente comprobable. No es
necesario proporcionar ninguna característica adicional para nuestras falsificaciones para admitir el operador
include. La mala noticia es que teníamos que usar el operador include en el código que deseamos para mantener la
persistencia. Este es un buen ejemplo del tipo de inconvenientes que debe evaluar al compilar código comprobable.
Hay ocasiones en las que es necesario dejar que la persistencia tenga pérdidas fuera de la abstracción del
repositorio para satisfacer los objetivos de rendimiento.
La alternativa a la carga diligente es la carga diferida. La carga diferida significa que no es necesario que nuestro
código de negocio anuncie explícitamente el requisito de los datos asociados. En su lugar, usamos nuestras
entidades en la aplicación y si se necesitan datos adicionales Entity Framework cargarán los datos a petición.
Carga diferida
Es fácil imaginar un escenario en el que no se sepa qué datos necesitará una lógica de negocios. Podríamos saber
que la lógica necesita un objeto de empleado, pero podemos crear una rama en diferentes rutas de ejecución,
donde algunas de esas rutas requieren información de tarjeta de tiempo del empleado y otras no. Los escenarios
como este son idóneos para la carga diferida implícita porque los datos aparecen de forma mágica según sea
necesario.
La carga diferida, también conocida como carga aplazada, impone algunos requisitos en nuestros objetos entidad.
Un POCO con persistencia real omisión no tendría ningún requisito de la capa de persistencia, pero la persistencia
real omisión es prácticamente imposible de lograr. En su lugar, medimos la persistencia omisión en grados
relativos. Sería desafortunable si era necesario heredar de una clase base orientada a la persistencia o usar una
colección especializada para lograr la carga diferida en POCO. Afortunadamente, EF4 tiene una solución menos
intrusiva.
Prácticamente no detectable
Cuando se usan objetos POCO, EF4 puede generar dinámicamente servidores proxy en tiempo de ejecución para
las entidades. Estos proxies invisiblemente encapsulan los POCO materializados y proporcionan servicios
adicionales interceptando cada operación get y set de cada propiedad para realizar trabajo adicional. Uno de estos
servicios es la característica de carga diferida que estamos buscando. Otro servicio es un mecanismo de
seguimiento de cambios eficaz que puede grabar cuando el programa cambia los valores de propiedad de una
entidad. El ObjectContext usa la lista de cambios durante el método SaveChanges para conservar las entidades
modificadas mediante comandos UPDATE.
Sin embargo, para que estos proxies funcionen, necesitan una manera de enlazar las operaciones GET y set de la
propiedad en una entidad, y los proxies logran este objetivo mediante la invalidación de los miembros virtuales.
Por lo tanto, si queremos tener una carga diferida implícita y un seguimiento de cambios eficaz, es necesario volver
a las definiciones de clase POCO y marcar las propiedades como virtuales.
public class Employee {

public virtual int Id { get; set; }
public virtual string Name { get; set; }
public virtual DateTime HireDate { get; set; }
public virtual ICollection<TimeCard> TimeCards { get; set; }
}
Todavía podemos decir que la entidad Employee es la que ignora la persistencia. El único requisito es usar
miembros virtuales y esto no afecta a la capacidad de prueba del código. No es necesario derivar de ninguna clase
base especial ni siquiera usar una colección especial dedicada a la carga diferida. Como se muestra en el código,
cualquier clase que implemente ICollection<T> está disponible para contener entidades relacionadas.
También hay un pequeño cambio que necesitamos hacer dentro de nuestra unidad de trabajo. La carga diferida
está desactivada de forma predeterminada cuando se trabaja directamente con un objeto ObjectContext. Hay una
propiedad que se puede establecer en la propiedad ContextOptions para habilitar la carga aplazada y podemos
establecer esta propiedad dentro de nuestra unidad real de trabajo si queremos habilitar la carga diferida en todas
partes.

// ...
_context.ContextOptions.LazyLoadingEnabled = true;
}
// ...
}
Con la carga diferida implícita habilitada, el código de aplicación puede usar un empleado y las tarjetas de tiempo
asociadas del empleado, mientras que el resto de completamente no es consciente del trabajo necesario para que
EF cargue los datos adicionales.
var employee = _unitOfWork.Employees
.Single(e => e.Id == id);
foreach (var card in employee.TimeCards) {
// ...
}
La carga diferida facilita la escritura del código de la aplicación y, con el proxy mágico, el código sigue siendo
totalmente comprobable. Las falsificaciones en memoria de la unidad de trabajo pueden simplemente precargar las
entidades falsas con datos asociados cuando sea necesario durante una prueba.
Llegados a este punto, nos centraremos en la creación de repositorios con IObjectSet<T> y veremos las
abstracciones para ocultar todos los signos del marco de persistencia.
Repositorios personalizados
La primera vez que se presentó el patrón de diseño de unidad de trabajo en este artículo se proporciona código de
ejemplo para el aspecto que podría tener la unidad de trabajo. Vamos a presentar esta idea original con el
escenario de tarjeta de tiempo empleado y empleado con el que hemos trabajado.

IRepository<Employee> Employees { get; }
IRepository<TimeCard> TimeCards { get; }
void Commit();
}
La principal diferencia entre esta unidad de trabajo y la unidad de trabajo que creamos en la última sección es
cómo esta unidad de trabajo no usa ninguna abstracción del marco de EF4 (no hay ninguna><T). IObjectSet<T>
funciona bien como una interfaz de repositorio, pero es posible que la API que expone no se alinee perfectamente
con las necesidades de la aplicación. En este próximo enfoque, se representarán los repositorios con una
abstracción personalizada de IRepository<T>.
Muchos desarrolladores que siguen el diseño basado en pruebas, el diseño controlado por el comportamiento y las
metodologías controladas por el dominio prefieren el enfoque IRepository<T> por varias razones. En primer lugar,
la interfaz IRepository<T> representa una capa "contra daños". Tal como se describe en Eric Evans en su libro de
diseño controlado por dominios, una capa contra daños mantiene el código de dominio fuera de las API de
infraestructura, como una API de persistencia. En segundo lugar, los desarrolladores pueden crear métodos en el
repositorio que satisfagan las necesidades exactas de una aplicación (como se detectó al escribir pruebas). Por
ejemplo, con frecuencia es necesario buscar una sola entidad con un valor de identificador, por lo que podemos
agregar un método FindById a la interfaz de repositorio. La definición de IRepository<T> tendrá un aspecto similar
al siguiente.
public interface IRepository<T>

where T : class, IEntity {
IQueryable<T> FindAll();
IQueryable<T> FindWhere(Expression<Func\<T, bool>> predicate);
T FindById(int id);
void Add(T newEntity);
void Remove(T entity);
}
Observe que volveremos a usar una interfaz IQueryable<T> para exponer colecciones de entidades.
IQueryable<T> permite a los árboles de expresión LINQ fluir en el proveedor EF4 y proporcionar al proveedor una
vista holística de la consulta. Una segunda opción sería devolver IEnumerable<T>, lo que significa que el proveedor
EF4 LINQ solo verá las expresiones compiladas dentro del repositorio. Cualquier agrupación, ordenación y
proyección realizadas fuera del repositorio no se creará en el comando SQL enviado a la base de datos, lo que
puede afectar negativamente al rendimiento. Por otro lado, un repositorio que solo devuelva IEnumerable<T>
resultados nunca le sorprenderá con un nuevo comando SQL. Ambos enfoques funcionarán y ambos enfoques
seguirán siendo comprobables.
Es sencillo proporcionar una única implementación de la interfaz IRepository<T> mediante genéricos y la API de
ObjectContext EF4.
public class SqlRepository<T> : IRepository<T>

where T : class, IEntity {
public SqlRepository(ObjectContext context) {
_objectSet = context.CreateObjectSet<T>();
}
public IQueryable<T> FindAll() {
return _objectSet;
}
public IQueryable<T> FindWhere(
Expression<Func\<T, bool>> predicate) {
return _objectSet.Where(predicate);
}
public T FindById(int id) {
return _objectSet.Single(o => o.Id == id);
}
public void Add(T newEntity) {
_objectSet.AddObject(newEntity);
}
public void Remove(T entity) {
_objectSet.DeleteObject(entity);
}
protected ObjectSet<T> _objectSet;
}
El enfoque IRepository<T> nos proporciona un control adicional sobre nuestras consultas porque un cliente tiene
que invocar un método para llegar a una entidad. Dentro del método, podríamos proporcionar comprobaciones
adicionales y operadores LINQ para aplicar las restricciones de la aplicación. Observe que la interfaz tiene dos
restricciones en el parámetro de tipo genérico. La primera restricción es la clase cons que requiere el
ObjectSet<T>y la segunda restricción obliga a nuestras entidades a implementar IEntity: una abstracción creada
para la aplicación. La interfaz IEntity fuerza a las entidades a tener una propiedad de identificador legible y, a
continuación, podemos usar esta propiedad en el método FindById. IEntity se define con el código siguiente.
public interface IEntity {

int Id { get; }
}
IEntity podría considerarse una pequeña infracción de la persistencia omisión, ya que las entidades necesitan
implementar esta interfaz. Recuerde que la persistencia omisión se refiere a las ventajas y, para muchas de las
funciones de FindById, la restricción impuesta por la interfaz. La interfaz no tiene ningún impacto en la capacidad
de prueba.
La creación de una instancia de Live IRepository<T> requiere un ObjectContext de EF4, por lo que una
implementación de unidad de trabajo concreta debe administrar la creación de instancias.
var connectionString =
ConfigurationManager
.ConnectionStrings[ConnectionStringName]
.ConnectionString;

_context.ContextOptions.LazyLoadingEnabled = true;
}
public IRepository<Employee> Employees {

get {
if (_employees == null) {
_employees = new SqlRepository<Employee>(_context);
}
return _employees;
}
}
public IRepository<TimeCard> TimeCards {

get {
if (_timeCards == null) {
_timeCards = new SqlRepository<TimeCard>(_context);
}
return _timeCards;
}
}

}
SqlRepository<Employee> _employees = null;

SqlRepository<TimeCard> _timeCards = null;
readonly ObjectContext _context;
const string ConnectionStringName = "EmployeeDataModelContainer";
}
Uso del repositorio personalizado

El uso del repositorio personalizado no es significativamente diferente del uso del repositorio basado en
IObjectSet<T>. En lugar de aplicar operadores LINQ directamente a una propiedad, primero debemos invocar los
métodos del repositorio para obtener una referencia IQueryable<T>.
public ViewResult Index() {

var model = _repository.FindAll()
.Include("TimeCards")
return View(model);
}
Observe que el operador de inclusión personalizado implementado anteriormente funcionará sin cambios. El
método FindById del repositorio quita la lógica duplicada de acciones que intentan recuperar una sola entidad.
public ViewResult Details(int id) {

var model = _repository.FindById(id);
return View(model);
}
No hay ninguna diferencia significativa en la capacidad de prueba de los dos métodos que hemos examinado.
Podríamos proporcionar implementaciones falsas de IRepository<T> compilando clases concretas respaldadas por
HashSet<Employee>, al igual que lo hicimos en la última sección. Sin embargo, algunos desarrolladores prefieren
usar objetos ficticios y marcos de objetos ficticios en lugar de crear simulaciones. Veremos el uso de simulacros
para probar nuestra implementación y analizar las diferencias entre los simulacros y las simulaciones en la sección
siguiente.
Pruebas con simulacros
Hay diferentes enfoques para crear lo que Martin Fowler llama "Double de prueba". Una prueba Double (como una
película Stunt Double) es un objeto que se compila en "out" para objetos reales de producción durante las pruebas.
Los repositorios en memoria creados son dobles de pruebas para los repositorios que se comunican con SQL
Server. Hemos visto cómo usar estas pruebas dobles durante las pruebas unitarias para aislar el código y mantener
la ejecución rápida de las pruebas.
Los dobles de pruebas que hemos creado son implementaciones reales y en funcionamiento. En segundo plano,
cada uno almacena una colección concreta de objetos y agrega y quita objetos de esta colección mientras se
manipula el repositorio durante una prueba. Algunos desarrolladores como para compilar la prueba se duplican de
esta manera: con código real y implementaciones de trabajo. Estos dobles de pruebas son lo que llamamos
imitaciones. Tienen implementaciones en funcionamiento, pero no son lo suficientemente reales para su uso en
producción. El repositorio falso no escribe realmente en la base de datos. El servidor SMTP falso no envía un
mensaje de correo electrónico a través de la red.
Simuladores frente a falsificaciones
Hay otro tipo de prueba doble conocido como ficticio. Mientras que las simulaciones tienen implementaciones en
funcionamiento, los simulacros se incluyen sin implementación. Con la ayuda de un marco de objeto ficticio,
construimos estos objetos ficticios en tiempo de ejecución y los usamos como dobles de pruebas. En esta sección
vamos a usar el marco de trabajo ficticio de código abierto MOQ. Este es un ejemplo sencillo del uso de MOQ para
crear dinámicamente una prueba Double para un repositorio de empleados.
Mock<IRepository<Employee>> mock =
new Mock<IRepository<Employee>>();
IRepository<Employee> repository = mock.Object;
repository.Add(new Employee());
var employee = repository.FindById(1);
Solicitamos a MOQ una implementación de IRepository<empleado> y crea una dinámicamente. Podemos obtener
el objeto que implementa IRepository<empleado> accediendo a la propiedad Object del objeto ficticio<T>. Es este
objeto interno que se puede pasar a nuestros controladores y no sabrá si se trata de un doble de prueba o del
repositorio real. Se pueden invocar métodos en el objeto del mismo modo que se invocan los métodos en un
objeto con una implementación real.
Debe preguntarse lo que hará el repositorio ficticio cuando se invoque el método Add. Dado que no hay ninguna
implementación detrás del objeto ficticio, Add no hace nada. No hay ninguna colección concreta en segundo plano
como teníamos con las falsificaciones que escribimos, por lo que el empleado se descarta. ¿Qué ocurre con el valor
devuelto de FindById? En este caso, el objeto ficticio hace lo único que puede hacer, que devuelve un valor
predeterminado. Dado que se devuelve un tipo de referencia (un empleado), el valor devuelto es un valor null.
Los simulacros podrían parecer no útil; sin embargo, hay dos características más de los simulacros que no hemos
hablado. En primer lugar, el marco MOQ registra todas las llamadas realizadas en el objeto ficticio. Más adelante en
el código, se puede preguntar a MOQ si alguien invocó el método Add o si alguien invocó el método FindById. Más
adelante veremos cómo podemos usar esta característica de grabación de "caja negra" en las pruebas.
La segunda característica excelente es cómo se puede usar MOQ para programar un objeto ficticio con las
expectativas. Una expectativa indica al objeto ficticio cómo responder a cualquier interacción determinada. Por
ejemplo, se puede programar una expectativa en nuestro simulacro e indicar a que devuelva un objeto de
empleado cuando alguien invoque FindById. El marco de trabajo de MOQ usa una API de instalación y expresiones
lambda para programar estas expectativas.
[TestMethod]
public void MockSample() {
Mock<IRepository<Employee>> mock =
new Mock<IRepository<Employee>>();
mock.Setup(m => m.FindById(5))
.Returns(new Employee {Id = 5});
IRepository<Employee> repository = mock.Object;
var employee = repository.FindById(5);
Assert.IsTrue(employee.Id == 5);
}
En este ejemplo, se pide a MOQ que cree de forma dinámica un repositorio y, a continuación, programemos el
repositorio con una expectativa. La expectativa indica al objeto ficticio que devuelva un nuevo objeto de empleado
con un valor de identificador de 5 cuando alguien invoque el método FindById pasando un valor de 5. Esta prueba
se supera y no es necesario crear una implementación completa en la<falsas de IRepository>.
Vamos a revisar las pruebas que hemos escrito anteriormente y a trabajar con ellas para usar simulacros en lugar
de simulaciones. Al igual que antes, usaremos una clase base para configurar los componentes comunes de la
infraestructura que necesitamos para todas las pruebas del controlador.
public class EmployeeControllerTestBase {

public EmployeeControllerTestBase() {
_employeeData = EmployeeObjectMother.CreateEmployees()
.AsQueryable();
_repository = new Mock<IRepository<Employee>>();
_unitOfWork = new Mock<IUnitOfWork>();
_unitOfWork.Setup(u => u.Employees)
.Returns(_repository.Object);
_controller = new EmployeeController(_unitOfWork.Object);
}
protected IQueryable<Employee> _employeeData;

protected Mock<IUnitOfWork> _unitOfWork;
protected EmployeeController _controller;
protected Mock<IRepository<Employee>> _repository;
}
El código de instalación se mantiene principalmente igual. En lugar de usar falsificaciones, usaremos MOQ para
construir objetos ficticios. La clase base organiza la unidad de trabajo simulada para devolver un repositorio ficticio
cuando el código invoca la propiedad Employees. El resto de la configuración del simulacro tendrá lugar dentro de
los extras de prueba dedicados a cada escenario específico. Por ejemplo, el accesorio de prueba para la acción de
índice configurará el repositorio ficticio para devolver una lista de empleados cuando la acción invoca el método
FindAll del repositorio ficticio.
[TestClass]
public class EmployeeControllerIndexActionTests
public EmployeeControllerIndexActionTests() {
_repository.Setup(r => r.FindAll())
.Returns(_employeeData);
}
// .. tests
[TestMethod]
public void ShouldBuildModelWithAllEmployees() {
Assert.IsTrue(model.Count() == _employeeData.Count());
}
// .. and more tests
}
A excepción de las expectativas, nuestras pruebas son similares a las pruebas que teníamos antes. Sin embargo, con
la capacidad de grabación de un marco ficticio, podemos enfocar las pruebas desde un ángulo diferente. Veremos
esta nueva perspectiva en la sección siguiente.
Pruebas de estado frente a interacción
Hay distintas técnicas que puede usar para probar el software con objetos ficticios. Un enfoque consiste en usar
pruebas basadas en el estado, que es lo que hemos hecho en este documento hasta ahora. Las pruebas basadas en
el estado realizan aserciones sobre el estado del software. En la última prueba, se ha invocado un método de acción
en el controlador y se ha realizado una aserción sobre el modelo que debe compilar. Estos son algunos ejemplos de
estado de prueba:
Compruebe que el repositorio contiene el nuevo objeto de empleado después de que se ejecute Create.
Compruebe que el modelo contiene una lista de todos los empleados después de que se ejecute el índice.
Compruebe que el repositorio no contiene un empleado determinado después de que se ejecute la eliminación.
Otro enfoque que verá con objetos ficticios es comprobar las interacciones. Mientras que las pruebas basadas en el
estado realizan aserciones sobre el estado de los objetos, las pruebas basadas en la interacción realizan aserciones
sobre cómo interactúan los objetos. Por ejemplo:
Compruebe que el controlador invoca el método Add del repositorio cuando se ejecuta Create.
Compruebe que el controlador invoca el método FindAll del repositorio cuando se ejecuta el índice.
Compruebe que el controlador invoca el método commit de la unidad del trabajo para guardar los cambios
cuando se ejecuta la edición.
A menudo, las pruebas de interacción requieren menos datos de prueba, porque no se Poking dentro de las
colecciones y se comprueban los recuentos. Por ejemplo, si sabemos que la acción de detalles invoca el método
FindById de un repositorio con el valor correcto, es probable que la acción se comporte correctamente. Podemos
comprobar este comportamiento sin configurar ningún dato de prueba para que se devuelva desde FindById.
[TestClass]
public class EmployeeControllerDetailsActionTests
// ...
[TestMethod]
public void ShouldInvokeRepositoryToFindEmployee() {
var result = _controller.Details(_detailsId);
_repository.Verify(r => r.FindById(_detailsId));
}
int _detailsId = 1;
}
La única configuración necesaria en el accesorio de prueba anterior es la que proporciona la clase base. Cuando se
invoca la acción del controlador, MOQ registrará las interacciones con el repositorio ficticio. Mediante la
comprobación de la API de MOQ, podemos preguntar a MOQ si el controlador invocó FindById con el valor de ID.
adecuado. Si el controlador no invocó el método o invocó el método con un valor de parámetro inesperado, el
método verify producirá una excepción y se producirá un error en la prueba.
Este es otro ejemplo para comprobar que la acción de creación invoca la confirmación en la unidad de trabajo
actual.
[TestMethod]
public void ShouldCommitUnitOfWork() {
_unitOfWork.Verify(u => u.Commit());
}
Un peligro con las pruebas de interacción es la tendencia de especificar las interacciones. La capacidad del objeto
ficticio de registrar y comprobar cada interacción con el objeto ficticio no significa que la prueba debe intentar
comprobar cada interacción. Algunas interacciones son detalles de la implementación y solo se deben comprobar
las interacciones necesarias para satisfacer la prueba actual.
La elección entre simulacros o falsificaciones depende en gran medida del sistema que se está probando y de sus
preferencias personales (o de equipo). Los objetos ficticios pueden reducir drásticamente la cantidad de código que
necesita para implementar los dobles de pruebas, pero no todos se sienten cómodos con la programación de las
expectativas y la comprobación de las interacciones.
Conclusiones
En este documento hemos mostrado varios enfoques para crear código comprobable al usar el Entity Framework
ADO.NET para la persistencia de datos. Podemos aprovechar las abstracciones integradas, como IObjectSet<T>, o
crear nuestras propias abstracciones como IRepository<T>. En ambos casos, la compatibilidad POCO en la Entity
Framework 4,0 de ADO.NET permite a los consumidores de estas abstracciones seguir siendo ignorables y muy
comprobables. Características adicionales de EF4 como la carga diferida implícita permite que el código del servicio
de aplicaciones y del negocio funcione sin preocuparse por los detalles de un almacén de datos relacional. Por
último, las abstracciones que creamos son fáciles de simular o falsificar dentro de las pruebas unitarias, y podemos
usar estos dobles de pruebas para lograr pruebas de ejecución rápida, muy aisladas y confiables.
Robert C. Martin, " el principio de responsabilidad única"
Martin Fowler, Catálogo de patrones de patrones de arquitectura de aplicaciones empresariales
Griffin Caprio, " inyección de dependencia"
Blog de programación de datos, " Tutorial: desarrollo controlado por pruebas con el Entity Framework 4,0".
Blog de programación de datos, " uso de patrones de repositorio y unidad de trabajo con Entity Framework 4,0"
Aaron Jensen, " Introduccióna las especificaciones de la máquina"
Eric Lee, " BDD con MSTest"
Eric Evans, " diseño controlado por dominios"
Martin Fowler, "los simulacros no son stubs"
Martin Fowler, " Test Double"
MOQ
Biografía
Scott Allen es miembro del personal técnico de Pluralsight y el fundador de OdeToCode.com. En 15 años de
desarrollo de software comercial, Scott ha trabajado en soluciones para todo, desde dispositivos incrustados de 8
bits hasta aplicaciones Web ASP.NET altamente escalables. Puede ponerse en contacto con Scott en su blog en
OdeToCode o en Twitter en https://twitter.com/OdeToCode.
Un modelo de EF almacena los detalles sobre cómo se asignan las propiedades y las clases de la aplicación a las
columnas y las tablas de la base de datos. Hay dos formas principales de crear un modelo de EF:
Uso de Code First : el desarrollador escribe código para especificar el modelo. EF genera los modelos y las
asignaciones en tiempo de ejecución según las clases de entidad y la configuración de modelo adicional
proporcionados por el desarrollador.
Uso de EF Designer : el desarrollador dibuja cuadros y líneas para especificar el modelo con EF Designer.
El modelo resultante se almacena como XML en un archivo con la extensión EDMX. Los objetos de dominio
de la aplicación normalmente se generan de forma automática desde el modelo conceptual.
Flujos de trabajo de EF
Estos dos enfoques pueden usarse para establecer como destino una base de datos existente o para crear una
nueva base de datos, lo que da lugar a cuatro flujos de trabajo diferentes. Descubra cuál es el más adecuado en su
caso:
SO LO Q UIERO ESC RIB IR C Ó DIGO. . . Q UIERO USA R UN DISEÑ A DO R. . .
Voy a crear una nueva base de Use Code First para definir el modelo Use Model First para definir el modelo
datos en el código y luego generar una base mediante cuadros y líneas y luego
de datos. generar una base de datos.
Necesito acceder a una base de Use Code First para crear un modelo Use Database First para crear un
datos existente basado en código que se asigne a una modelo de cuadros y líneas que se
base de datos existente. asigne a una base de datos existente.
Vea el vídeo: What EF workflow should I use? (Qué flujo de trabajo de EF debo usar)
En este breve vídeo se explican las diferencias y cómo encontrar el adecuado para usted.
Presentado por : Rowan Miller
(Consejos para elegir un flujo de trabajo) WMV | MP4 | WMV (ZIP)

Si después de ver el vídeo todavía no se siente cómodo para decidir si quiere usar EF Designer o Code First,
obtenga información sobre ambos.
Aspectos técnicos
Independientemente de si usa Code First o EF Designer, un modelo de EF siempre tiene varios componentes:
Los objetos de dominio de la aplicación o los propios tipos de entidad. Esto se suele denominar la capa de
objeto
Un modelo conceptual que consta de tipos de entidad específicos de dominio y relaciones, que se describen
mediante Entity Data Model. Se suele hacer referencia a esta capa con la letra "C", por conceptual.
Un modelo de almacenamiento que representa las tablas, las columnas y las relaciones según se definen en
la base de datos. Se suele hacer referencia a esta capa con la letra "S", por storage (almacenamiento en
inglés).
Una asignación entre el modelo conceptual y el esquema de base de datos. Esta asignación se suele
conocer como asignación "C-S".
El motor de asignación de EF aprovecha la asignación "C-S" para transformar las operaciones en entidades (por
ejemplo, crear, leer, actualizar y eliminar) en operaciones equivalentes en las tablas de la base de datos.
La asignación entre el modelo conceptual y los objetos de la aplicación se suele conocer como asignación "O-C".
En comparación con la asignación "C-S", la asignación "O-C" es implícita y de uno a uno: las entidades,
propiedades y relaciones definidas en el modelo conceptual tienen que coincidir con las formas y los tipos de los
objetos .NET. A partir de EF4 y versiones posteriores, la capa de objetos puede componerse de objetos simples con
propiedades sin dependencias en EF. Estos se conocen normalmente como objetos CLR estándar (POCO) y la
asignación de tipos y propiedades se realiza según las convenciones de coincidencia de nombres. Anteriormente,
en EF 3.5, había restricciones específicas para la capa de objeto, por ejemplo, las entidades tenían que derivar de la
clase EntityObject e incluir atributos de EF para implementar la asignación "O-C".
Code First a una nueva base de datos
Este vídeo y el tutorial paso a paso proporcionan una introducción al desarrollo de Code First que tiene como
destino una nueva base de datos. Este escenario incluye establecer como destino una base de datos que no existe
y Code First creará, o una base de datos vacía a la que Code First agregará nuevas tablas. Code First permite
definir el modelo mediante clases de C# o VB.Net. Opcionalmente, se puede realizar una configuración adicional
mediante atributos en las clases y propiedades o mediante una API fluida.
Visualización del vídeo

Este vídeo proporciona una introducción al desarrollo de Code First orientado a una nueva base de datos. Este
escenario incluye establecer como destino una base de datos que no existe y Code First creará, o una base de
datos vacía a la que Code First agregará nuevas tablas. Code First permite definir el modelo mediante C# las
clases o VB.net. Opcionalmente, se puede realizar una configuración adicional mediante atributos en las clases y
propiedades o mediante una API fluida.
Vídeo : wmv | MP4 | WMV (zip)
Requisitos previos
Debe tener instalado al menos Visual Studio 2010 o Visual Studio 2012 para completar este tutorial.
Si usa Visual Studio 2010, también debe tener instalado NuGet .
1. crear la aplicación
Para simplificar las cosas, vamos a crear una aplicación de consola básica que use Code First para realizar el
acceso a los datos.
Abra Visual Studio.
Seleccionar ventanas en el menú izquierdo y en la aplicación de consola
Escriba CodeFirstNewDatabaseSample como nombre
2. crear el modelo
Vamos a definir un modelo muy sencillo mediante clases. Simplemente los definimos en el archivo Program.cs,
pero en una aplicación real dividiría las clases en archivos independientes y potencialmente un proyecto
independiente.
Debajo de la definición de clase de programa en Program.cs, agregue las dos clases siguientes.
public class Blog
{

}
public class Post

{

}
Observará que vamos a hacer que las dos propiedades de navegación (blog. posts y post. blog) sean virtuales.
Esto habilita la característica de carga diferida de Entity Framework. La carga diferida significa que el contenido
de estas propiedades se cargará automáticamente desde la base de datos cuando intente obtener acceso a ellas.
3. crear un contexto
Ahora es el momento de definir un contexto derivado, que representa una sesión con la base de datos, lo que nos
permite consultar y guardar datos. Definimos un contexto que se deriva de System. Data. Entity. DbContext y
expone un DbSet con tipo de> de la<de la carpa para cada clase de nuestro modelo.
Ahora estamos empezando a usar los tipos del Entity Framework por lo que necesitamos agregar el paquete
NuGet EntityFramework.
Proyecto:> administrar paquetes NuGet... Nota: Si no tiene la Administración de paquetes de
NuGet.. . opción debe instalar la versión más reciente de NuGet
Seleccione la pestaña en línea
Seleccione el paquete EntityFramework
Agregue una instrucción using para System. Data. Entity en la parte superior de Program.cs.
Debajo de la clase post de Program.cs, agregue el siguiente contexto derivado.

{
}
Esta es una lista completa de lo que Program.cs debería contener ahora.

using System;
using System.Linq;
using System.Text;
namespace CodeFirstNewDatabaseSample
{
class Program
{
{
}
}
public class Blog

{

}
public class Post

{

}

{
}
}
Eso es todo el código que necesitamos para empezar a almacenar y recuperar los datos. Obviamente, hay un
poco más en segundo plano y echaremos un vistazo a eso en un momento, pero primero lo veremos en acción.
4. leer & escribir datos

Implemente el método Main en Program.cs como se muestra a continuación. Este código crea una nueva
instancia de nuestro contexto y, a continuación, la usa para insertar un nuevo blog. A continuación, usa una
consulta LINQ para recuperar todos los blogs de la base de datos ordenados alfabéticamente por título.
class Program
{
{
{
// Create and save a new Blog
Console.Write("Enter a name for a new Blog: ");
var name = Console.ReadLine();
var blog = new Blog { Name = name };

db.Blogs.Add(blog);
db.SaveChanges();
// Display all Blogs from the database

var query = from b in db.Blogs
orderby b.Name
select b;
Console.WriteLine("All blogs in the database:");

foreach (var item in query)
{
Console.WriteLine(item.Name);
}

Console.ReadKey();
}
}
}
Ahora puede ejecutar la aplicación y probarla.
Enter a name for a new Blog: ADO.NET Blog

All blogs in the database:
ADO.NET Blog
¿Dónde están mis datos?

Por Convención DbContext ha creado una base de datos automáticamente.
Si una instancia local de SQL Express está disponible (se instala de forma predeterminada con Visual Studio
2010), Code First ha creado la base de datos en esa instancia.
Si SQL Express no está disponible, Code First probará y usará LocalDB (instalado de forma predeterminada
con Visual Studio 2012).
La base de datos se denomina después del nombre completo del contexto derivado, en nuestro caso,
CodeFirstNewDatabaseSample. BloggingContext
Estas son solo las convenciones predeterminadas y hay varias maneras de cambiar la base de datos que usa
Code First. hay más información disponible en la sección cómo el DbContext detecta el modelo y la
conexión a la base de datos . Puede conectarse a esta base de datos mediante Explorador de servidores en
Visual Studio
Haga clic con el botón derecho en conexiones de datos y seleccione Agregar conexión.. .
Ahora podemos inspeccionar el esquema que Code First creado.
DbContext ha trabajado en las clases que se van a incluir en el modelo examinando las propiedades de DbSet que
hemos definido. A continuación, usa el conjunto predeterminado de convenciones de Code First para determinar
los nombres de tabla y columna, determinar los tipos de datos, buscar claves principales, etc. Más adelante en
este tutorial veremos cómo puede invalidar estas convenciones.
5. tratar con cambios en el modelo

Ahora es el momento de realizar algunos cambios en nuestro modelo, cuando realizamos estos cambios también
necesitamos actualizar el esquema de la base de datos. Para ello, vamos a usar una característica denominada
Migraciones de Code First o migraciones para abreviar.
Las migraciones nos permiten tener un conjunto ordenado de pasos que describen cómo actualizar (y degradar)
el esquema de la base de datos. Cada uno de estos pasos, conocido como migración, contiene código que
describe los cambios que se van a aplicar.
El primer paso es habilitar Migraciones de Code First para nuestro BloggingContext.
Herramientas-administrador de paquetes de la biblioteca de>-> consola del administrador
de paquetes
Ejecute el comando Enable-Migrations en la consola del Administrador de paquetes
Se ha agregado una nueva carpeta Migrations al proyecto que contiene dos elementos:
Configuration.CS : este archivo contiene la configuración que las migraciones usarán para migrar
BloggingContext. No es necesario cambiar nada para este tutorial, pero aquí es donde se pueden
especificar los datos de inicialización, registrar proveedores para otras bases de datos, cambiar el
espacio de nombres que se generan en las migraciones, etc.
<timestamp>_InitialCreate.CS : esta es la primera migración, que representa los cambios que ya se
han aplicado a la base de datos para que no sea una base de datos vacía a la que se incluyan las tablas
blogs y posts. Aunque se permite a Code First crear automáticamente estas tablas, ahora que hemos
optado por las migraciones que se han convertido en una migración. Code First también se ha
registrado en la base de datos local que ya se ha aplicado esta migración. La marca de tiempo en el
nombre de archivo se usa para la ordenación.
Ahora vamos a hacer un cambio en nuestro modelo, agregaremos una propiedad de dirección URL a la
clase de blog:
public class Blog

{

}
Ejecute el comando Add-Migration AddUrl en la consola del administrador de paquetes. El comando Add-
Migration comprueba los cambios desde la última migración y scaffolding una nueva migración con los
cambios que se hayan encontrado. Podemos dar un nombre a las migraciones. en este caso, se llama a la
migración ' AddUrl '. El código con scaffolding está diciendo que necesitamos agregar una columna de
dirección URL, que puede contener datos de cadena, a DBO. Tabla de blogs. Si es necesario, podríamos editar
el código con scaffolding, pero esto no es necesario en este caso.
namespace CodeFirstNewDatabaseSample.Migrations
{
using System;
using System.Data.Entity.Migrations;
public partial class AddUrl : DbMigration

{
public override void Up()
{
AddColumn("dbo.Blogs", "Url", c => c.String());
}
public override void Down()

{
DropColumn("dbo.Blogs", "Url");
}
}
}
Ejecute el comando Update-Database en la consola del administrador de paquetes. Este comando aplicará
las migraciones pendientes a la base de datos. La migración de InitialCreate ya se ha aplicado, por lo que las
migraciones solo aplicarán la nueva migración de AddUrl. Sugerencia: puede usar el modificador – verbose
al llamar a Update-Database para ver el SQL que se ejecuta en la base de datos.
La nueva columna URL se agrega ahora a la tabla blogs en la base de datos:
6. anotaciones de datos
Hasta ahora, simplemente se permite a EF detectar el modelo con sus convenciones predeterminadas, pero habrá
ocasiones en las que nuestras clases no sigan las convenciones y necesitamos poder realizar una configuración
adicional. Hay dos opciones para ello: veremos las anotaciones de datos de esta sección y, a continuación, la API
fluida en la sección siguiente.
Vamos a agregar una clase de usuario a nuestro modelo
public class User

{
public string DisplayName { get; set; }
}
También necesitamos agregar un conjunto a nuestro contexto derivado.

{
public DbSet<User> Users { get; set; }
}
Si intentamos agregar una migración, se obtendría un error que indica que "elusuario de EntityType" no tiene
ninguna clave definida. Defina la clave para este EntityType ". como EF no tiene forma de saber que el nombre
de usuario debe ser la clave principal del usuario.
Ahora vamos a usar anotaciones de datos, por lo que necesitamos agregar una instrucción using en la parte
superior de Program.cs
Ahora, anote la propiedad username para identificar que es la clave principal.
public class User

{
[Key]
}
Usar el comando Add-Migration adduser para aplicar scaffolding a una migración para aplicar estos
cambios a la base de datos
Ejecutar el comando Update-Database para aplicar la nueva migración a la base de datos
La nueva tabla se agrega ahora a la base de datos:
La lista completa de anotaciones admitidas por EF es:

KeyAttribute
StringLengthAttribute
MaxLengthAttribute
ConcurrencyCheckAttribute
RequiredAttribute
TimestampAttribute
ComplexTypeAttribute
ColumnAttribute
TableAttribute
InversePropertyAttribute
ForeignKeyAttribute
DatabaseGeneratedAttribute
NotMappedAttribute
7. API fluida
En la sección anterior, analizamos el uso de anotaciones de datos para complementar o invalidar lo que detectó la
Convención. La otra forma de configurar el modelo es a través de la API fluida de Code First.
La mayoría de la configuración del modelo se puede realizar con anotaciones de datos simples. La API fluida es
una forma más avanzada de especificar la configuración del modelo que abarca todo lo que pueden hacer las
anotaciones de datos además de algunas configuraciones más avanzadas que no son posibles con las
anotaciones de datos. Las anotaciones de datos y la API fluida se pueden usar juntas.
Para acceder a la API fluida, invalide el método OnModelCreating en DbContext. Supongamos que deseamos
cambiar el nombre de la columna en la que se almacena User. DisplayName para mostrar_nombre.
Invalide el método OnModelCreating en BloggingContext con el siguiente código
{
public DbSet<User> Users { get; set; }
protected override void OnModelCreating(DbModelBuilder modelBuilder)

{
modelBuilder.Entity<User>()
.Property(u => u.DisplayName)
.HasColumnName("display_name");
}
}
Use el comando Add-Migration ChangeDisplayName para aplicar scaffolding a una migración para
aplicar estos cambios a la base de datos.
Ejecute el comando Update-Database para aplicar la nueva migración a la base de datos.
Ahora se ha cambiado el nombre de la columna DisplayName para mostrar_nombre:
Resumen
En este tutorial, hemos examinado Code First desarrollo con una nueva base de datos. Definimos un modelo
mediante clases y luego usaba ese modelo para crear una base de datos y almacenar y recuperar datos. Una vez
creada la base de datos, usamos Migraciones de Code First para cambiar el esquema a medida que nuestro
modelo evolucionó. También vimos cómo configurar un modelo con anotaciones de datos y la API fluida.
Code First a una base de datos existente
Este vídeo y el tutorial paso a paso proporcionan una introducción al desarrollo de Code First que tiene como
destino una base de datos existente. Code First permite definir el modelo mediante clases de C# o VB.Net.
Opcionalmente, se puede realizar una configuración adicional mediante atributos en las clases y propiedades o
mediante una API fluida.

Este vídeo ahora está disponible en Channel 9.
Requisitos previos
Para completar este tutorial, necesitará tener Visual Studio 2012 o Visual Studio 2013 instalado.
También necesitará la versión 6,1 (o posterior) de la Entity Framework Tools para Visual Studio instalado.
Consulte obtener Entity Framework para obtener información sobre la instalación de la versión más reciente del
Entity Framework Tools.
1. crear una base de datos existente

Abra Visual Studio.
Si no se ha conectado a una base de datos desde Explorador de ser vidores antes de que tenga que
seleccionar Microsoft SQL Ser ver como origen de datos
Conéctese a la instancia de LocalDB y escriba blog como nombre de la base de datos.

La nueva base de datos aparecerá ahora en Explorador de servidores, haga clic con el botón derecho en
ella y seleccione nueva consulta .
);

CONSTRAINT [FK_dbo.Posts_dbo.Blogs_BlogId] FOREIGN KEY ([BlogId]) REFERENCES [dbo].[Blogs] ([BlogId]) ON
DELETE CASCADE
);
INSERT INTO [dbo].[Blogs] ([Name],[Url])

VALUES ('The Visual Studio Blog', 'http://blogs.msdn.com/visualstudio/')
INSERT INTO [dbo].[Blogs] ([Name],[Url])

VALUES ('.NET Framework Blog', 'http://blogs.msdn.com/dotnet/')
Para simplificar las cosas, crearemos una aplicación de consola básica que use Code First para realizar el acceso a
los datos:
Abra Visual Studio.
Escriba CodeFirstExistingDatabaseSample como nombre
3. modelo de ingeniería inversa

Usaremos el Entity Framework Tools para Visual Studio, que nos ayudará a generar código inicial para asignarlo
a la base de datos. Estas herramientas solo generan código que también podría escribir manualmente si lo
prefiere.
Escriba BloggingContext como nombre y haga clic en Aceptar .
Seleccione code First desde la base de datos y haga clic en siguiente .
Seleccione la conexión a la base de datos creada en la primera sección y haga clic en siguiente .
Haga clic en la casilla situada junto a tablas para importar todas las tablas y haga clic en Finalizar .
Una vez que se complete el proceso de ingeniería inversa, se agregará al proyecto un número de elementos,
echemos un vistazo a lo que se ha agregado.
Archivo de configuración
Se ha agregado un archivo app. config al proyecto, este archivo contiene la cadena de conexión a la base de
datos existente.
<connectionStrings>
<add
name="BloggingContext"
connectionString="data source=(localdb)\mssqllocaldb;initial catalog=Blogging;integrated
security=True;MultipleActiveResultSets=True;App=EntityFramework"
providerName="System.Data.SqlClient" />
Observará también algunas otras opciones del archivo de configuración, que son valores de EF predeterminados
que indican Code First dónde crear las bases de datos. Dado que estamos asignando a una base de datos
existente, esta configuración se omitirá en nuestra aplicación.
Contexto derivado
Se ha agregado una clase BloggingContext al proyecto. El contexto representa una sesión con la base de datos,
lo que nos permite consultar y guardar datos. El contexto expone un >de<de DbSet para cada tipo de nuestro
modelo. También observará que el constructor predeterminado llama a un constructor base mediante la sintaxis
Name = . Esto indica Code First que la cadena de conexión que se va a utilizar para este contexto se debe cargar
desde el archivo de configuración.
public partial class BloggingContext : DbContext
{
: base("name=BloggingContext")
{
}
public virtual DbSet<Blog> Blogs { get; set; }

public virtual DbSet<Post> Posts { get; set; }

{
}
}
Siempre debe usar la sintaxis Name = cuando se usa una cadena de conexión en el archivo de configuración.
Esto garantiza que, si la cadena de conexión no está presente, se producirá Entity Framework en lugar de crear
una nueva base de datos por Convención.
Clases de modelo
Por último, también se han agregado al proyecto una clase de blog y publicación . Estas son las clases de
dominio que componen nuestro modelo. Verá que las anotaciones de datos se aplican a las clases para
especificar la configuración en la que las convenciones de Code First no se alinearán con la estructura de la base
de datos existente. Por ejemplo, verá la anotación StringLength en blog.Name y blog. URL , ya que tienen una
longitud máxima de 200 en la base de datos (la Code First predeterminada es usar la longitud máximo que
admite el proveedor de base de datos- nvarchar (Max) en SQL Server).
public partial class Blog

{
public Blog()
{
Posts = new HashSet<Post>();
}
[StringLength(200)]
[StringLength(200)]

}

Ahora que tenemos un modelo, es el momento de usarlo para tener acceso a algunos datos. Implemente el
método Main en Program.CS como se muestra a continuación. Este código crea una nueva instancia de nuestro
contexto y, a continuación, la usa para insertar un nuevo blog . A continuación, usa una consulta LINQ para
recuperar todos los blogs de la base de datos ordenados alfabéticamente por título .
class Program
{
{
{

db.Blogs.Add(blog);
db.SaveChanges();

orderby b.Name
select b;

{
}

Console.ReadKey();
}
}
}

.NET Framework Blog
ADO.NET Blog
The Visual Studio Blog
¿Qué ocurre si mi base de datos cambia?

El Asistente para Code First a base de datos está diseñado para generar un conjunto de puntos de partida de
clases que se pueden retocar y modificar. Si cambia el esquema de la base de datos, puede editar manualmente
las clases o realizar otro ingeniero inverso para sobrescribir las clases.
Usar Migraciones de Code First en una base de datos existente

Si desea usar Migraciones de Code First con una base de datos existente, vea migraciones de Code First a una
base de datos existente.
Resumen
En este tutorial, hemos examinado Code First desarrollo con una base de datos existente. Usamos el Entity
Framework Tools de Visual Studio para aplicar ingeniería inversa a un conjunto de clases que se asignan a la base
de datos y que podrían usarse para almacenar y recuperar datos.
Code First de las anotaciones de datos
NOTE
Framework 4,1. Si usa una versión anterior, no se aplicará parte o toda esta información.
El contenido de esta página se adapta a un artículo escrito originalmente por Julia Lerman
(<http://thedatafarm.com>).
Entity Framework Code First le permite usar sus propias clases de dominio para representar el modelo en el que
se basa EF para realizar consultas, seguimiento de cambios y funciones de actualización. Code First aprovecha un
patrón de programación denominado "Convención sobre configuración". Code First asumirá que las clases
siguen las convenciones de Entity Framework y, en ese caso, se descargará automáticamente de cómo realizar su
trabajo. Sin embargo, si las clases no siguen esas convenciones, tiene la posibilidad de agregar configuraciones a
las clases para proporcionar a EF la información necesaria.
Code First ofrece dos maneras de agregar estas configuraciones a las clases. Uno es el uso de atributos simples
denominado DataAnnotations y el segundo es el uso de la API fluida de Code First, que proporciona una manera
de describir las configuraciones de forma imperativa, en el código.
En este artículo se centrará en el uso de DataAnnotations (en el espacio de nombres System. ComponentModel.
DataAnnotations) para configurar las clases, resaltando las configuraciones más necesarias. Las anotaciones
también se entienden en una serie de aplicaciones .NET, como ASP.NET MVC, que permite a estas aplicaciones
aprovechar las mismas anotaciones para las validaciones del lado cliente.
El modelo
Mostraré Code First DataAnnotations con un par sencillo de clases: blog y publicación.
public class Blog

{
public string BloggerName { get; set;}
}
public class Post

{
public DateTime DateCreated { get; set; }
public ICollection<Comment> Comments { get; set; }
}
Como están, las clases blog y post siguen la Convención Code First de manera cómoda y no requieren ajustes
para habilitar la compatibilidad con EF. Sin embargo, también puede usar las anotaciones para proporcionar más
información a EF sobre las clases y la base de datos a las que se asignan.
Clave
Entity Framework se basa en cada entidad que tiene un valor de clave que se usa para el seguimiento de
entidades. Una Convención de Code First son las propiedades de clave IMPLÍCITAS; Code First buscará una
propiedad denominada "ID" o una combinación de nombre de clase e "ID", como "BlogId". Esta propiedad se
asignará a una columna de clave principal en la base de datos.
Las clases blog y post siguen esta Convención. ¿Qué ocurre si no? ¿Qué ocurre si el blog usa el nombre
PrimaryTrackingKey en su lugar, o incluso foo? Si Code First no encuentra una propiedad que coincida con esta
Convención, producirá una excepción debido al requisito de Entity Framework que debe tener una propiedad de
clave. Puede usar la anotación de clave para especificar qué propiedad se va a usar como EntityKey.
public class Blog

{
[Key]
public int PrimaryTrackingKey { get; set; }
public string BloggerName { get; set;}
}
Si usa la característica de generación de bases de datos de Code First, la tabla de blog tendrá una columna de
clave principal denominada PrimaryTrackingKey, que también se define como Identity de forma predeterminada.
Claves compuestas
Entity Framework admite claves compuestas: las claves principales que se componen de más de una propiedad.
Por ejemplo, podría tener una clase de Passport cuya clave principal sea una combinación de PassportNumber y
IssuingCountry.
public class Passport

{
[Key]
public int PassportNumber { get; set; }
[Key]
public string IssuingCountry { get; set; }
public DateTime Issued { get; set; }
public DateTime Expires { get; set; }
}
Si se intenta usar la clase anterior en el modelo EF, se produciría una InvalidOperationException :

No se puede determinar el orden de claves principales compuesto para el tipo ' Passport '. Use el método
ColumnAttribute o Haskey (para especificar un orden para las claves principales compuestas.
Para usar las claves compuestas, Entity Framework requiere definir un orden para las propiedades de clave.
Puede hacerlo mediante la anotación de columna para especificar un orden.
NOTE
El valor del orden es relativo (en lugar de basado en índice), por lo que se pueden usar los valores. Por ejemplo, 100 y 200
serían aceptables en lugar de 1 y 2.
public class Passport

{
[Key]
[Column(Order=1)]
[Key]
[Column(Order = 2)]
public DateTime Issued { get; set; }
public DateTime Expires { get; set; }
}
Si tiene entidades con claves externas compuestas, debe especificar la misma ordenación de columnas que usó
para las propiedades de clave principal correspondientes.
Solo el orden relativo dentro de las propiedades de clave externa debe ser el mismo, no es necesario que
coincidan los valores exactos asignados al pedido . Por ejemplo, en la clase siguiente, se podría usar 3 y 4 en
lugar de 1 y 2.
public class PassportStamp

{
[Key]
public int StampId { get; set; }
public DateTime Stamped { get; set; }
public string StampingCountry { get; set; }
[ForeignKey("Passport")]
[Column(Order = 1)]
[ForeignKey("Passport")]
[Column(Order = 2)]
public Passport Passport { get; set; }

}
Obligatorio
La anotación required indica a EF que se requiere una propiedad determinada.
Agregar obligatorio a la propiedad title forzará a EF (y MVC) a asegurarse de que la propiedad contiene datos.
[Required]
Sin ningún cambio de código o marcado adicional en la aplicación, una aplicación MVC realizará la validación del
lado cliente, incluso generando dinámicamente un mensaje usando los nombres de la propiedad y de las
anotaciones.
El atributo required también afectará a la base de datos generada haciendo que la propiedad asignada no acepte
valores NULL. Observe que el campo title ha cambiado a "not null".
NOTE
En algunos casos, es posible que no sea posible que la columna de la base de datos no acepte valores NULL, aunque se
requiera la propiedad. Por ejemplo, cuando se usa un dato de estrategia de herencia de TPH para varios tipos, se almacena
en una sola tabla. Si un tipo derivado incluye una propiedad necesaria, no se puede hacer que la columna no acepte
valores NULL, ya que no todos los tipos de la jerarquía tendrán esta propiedad.
MaxLength y MinLength
Los atributos MaxLength y MinLength permiten especificar validaciones de propiedades adicionales, tal y como
hizo con required.
Este es el BloggerName con los requisitos de longitud. En el ejemplo también se muestra cómo combinar
atributos.
[MaxLength(10),MinLength(5)]
public string BloggerName { get; set; }
La anotación MaxLength afectará a la base de datos estableciendo la longitud de la propiedad en 10.
La anotación del lado cliente de MVC y la anotación del lado servidor EF 4,1 respetarán esta validación y, de
nuevo, se generará dinámicamente un mensaje de error: "el campo BloggerName debe ser una cadena o un tipo
de matriz con una longitud máxima de ' 10 '". Ese mensaje es un poco largo. Muchas anotaciones permiten
especificar un mensaje de error con el atributo ErrorMessage.
[MaxLength(10, ErrorMessage="BloggerName must be 10 characters or less"),MinLength(5)]
También puede especificar ErrorMessage en la anotación requerida.
NotMapped
La Convención Code First dicta que cada propiedad que es de un tipo de datos admitido se representa en la base
de datos. Pero esto no siempre es el caso en las aplicaciones. Por ejemplo, podría tener una propiedad en la clase
de blog que crea un código basado en los campos título y BloggerName. Esa propiedad se puede crear
dinámicamente y no es necesario almacenarla. Puede marcar las propiedades que no se asignan a la base de
datos con la anotación NotMapped como esta propiedad BlogCode.
[NotMapped]
public string BlogCode
{
get
{
return Title.Substring(0, 1) + ":" + BloggerName.Substring(0, 1);
}
}
ComplexType
No es raro describir las entidades de dominio en un conjunto de clases y, a continuación, crear capas de esas
clases para describir una entidad completa. Por ejemplo, puede Agregar una clase denominada BlogDetails al
modelo.
public class BlogDetails

{
public DateTime? DateCreated { get; set; }
[MaxLength(250)]
public string Description { get; set; }
}
Observe que BlogDetails no tiene ningún tipo de propiedad de clave. En el diseño controlado por dominios,
BlogDetails se conoce como un objeto de valor. Entity Framework hace referencia a los objetos de valor como
tipos complejos. No se puede realizar un seguimiento de los tipos complejos por su cuenta.
Sin embargo, como una propiedad de la clase de blog, BlogDetails se realizará un seguimiento como parte de un
objeto de blog. Para que Code First lo reconozca, debe marcar la clase BlogDetails como ComplexType.
[ComplexType]
public class BlogDetails
{
public DateTime? DateCreated { get; set; }
[MaxLength(250)]
public string Description { get; set; }
}
Ahora puede Agregar una propiedad en la clase de blog para representar el BlogDetails de ese blog.
public BlogDetails BlogDetail { get; set; }
En la base de datos, la tabla de blog contendrá todas las propiedades del blog, incluidas las propiedades
contenidas en su propiedad BlogDetail. De forma predeterminada, cada uno está precedido por el nombre del
tipo complejo, BlogDetail.
ConcurrencyCheck
La anotación ConcurrencyCheck permite marcar una o varias propiedades que se usarán para la comprobación
de simultaneidad en la base de datos cuando un usuario modifica o elimina una entidad. Si ha trabajado con el
diseñador de EF, esto se alinea con el establecimiento de la propiedad ConcurrencyMode en Fixed.
Vamos a ver cómo funciona ConcurrencyCheck agregándolo a la propiedad BloggerName.
[ConcurrencyCheck, MaxLength(10, ErrorMessage="BloggerName must be 10 characters or less"),MinLength(5)]

Cuando se llama a SaveChanges, debido a la anotación ConcurrencyCheck en el campo BloggerName, se usará

el valor original de dicha propiedad en la actualización. El comando intentará buscar la fila correcta filtrando no
solo en el valor de clave, sino también en el valor original de BloggerName. Estas son las partes fundamentales
del comando UPDATE que se envía a la base de datos, donde puede ver que el comando actualizará la fila que
tiene un PrimaryTrackingKey es 1 y un BloggerName de "Julia", que era el valor original cuando el blog se
recuperó de la base de datos.
where (([PrimaryTrackingKey] = @4) and ([BloggerName] = @5))

@4=1,@5=N'Julie'
Si un usuario ha cambiado el nombre de blogger para ese blog mientras tanto, se producirá un error en esta
actualización y obtendrá un DbUpdateConcurrencyException que deberá controlar.
TimeStamp
Es más común usar los campos rowversion o TIMESTAMP para la comprobación de simultaneidad. Pero en lugar
de utilizar la anotación ConcurrencyCheck, puede utilizar la anotación de marca de tiempo más específica
siempre que el tipo de la propiedad sea una matriz de bytes. Code First tratará las propiedades timestamp igual
que las propiedades ConcurrencyCheck, pero también se asegurará de que el campo de base de datos generado
por Code First no admita valores NULL. Solo puede tener una propiedad timestamp en una clase determinada.
Agregando la siguiente propiedad a la clase de blog:
[Timestamp]
public Byte[] TimeStamp { get; set; }
en primer lugar, el código crea una columna de marca de tiempo que no acepta valores NULL en la tabla de base
de datos.
Tabla y columna
Si va a permitir que Code First cree la base de datos, puede que desee cambiar el nombre de las tablas y
columnas que está creando. También puede usar Code First con una base de datos existente. Pero no siempre es
el caso de que los nombres de las clases y propiedades de su dominio coincidan con los nombres de las tablas y
columnas de la base de datos.
Mi clase se denomina blog y por Convención, Code First presupone que se asignará a una tabla denominada
blogs. Si no es así, puede especificar el nombre de la tabla con el atributo de tabla. Aquí, por ejemplo, la
anotación está especificando que el nombre de la tabla es InternalBlogs.
[Table("InternalBlogs")]
public class Blog
La anotación de columna es un complemento más bien para especificar los atributos de una columna asignada.
Puede estipular un nombre, un tipo de datos o incluso el orden en el que aparece una columna en la tabla. Este
es un ejemplo del atributo de columna.
[Column("BlogDescription", TypeName="ntext")]
public String Description {get;set;}
No confunda el atributo TypeName de la columna con la DataAnnotations DataType. DataType es una anotación
que se usa para la interfaz de usuario y Code First omitirá.
Esta es la tabla una vez regenerada. El nombre de la tabla ha cambiado a InternalBlogs y la columna Descripción
del tipo complejo ahora es BlogDescription. Dado que el nombre se especificó en la anotación, Code First no
usará la Convención de inicio del nombre de columna con el nombre del tipo complejo.
DatabaseGenerated
Una característica importante de las bases de datos es la capacidad de tener propiedades calculadas. Si va a
asignar las clases de Code First a tablas que contienen columnas calculadas, no desea que Entity Framework
intente actualizar esas columnas. Pero quiere que EF devuelva los valores de la base de datos después de insertar
o actualizar los datos. Puede usar la anotación DatabaseGenerated para marcar esas propiedades en la clase
junto con la enumeración calculada. Otras enumeraciones son none e Identity.
[DatabaseGenerated(DatabaseGeneratedOption.Computed)]
Puede usar la base de datos generada en columnas de tipo byte o TIMESTAMP cuando Code First está generando
la base de datos; de lo contrario, solo debería usar esta al apuntar a bases de datos existentes porque Code First
no podrá determinar la fórmula de la columna calculada.
Antes de que lea de forma predeterminada, una propiedad clave que es un entero se convertirá en una clave de
identidad en la base de datos. Es lo mismo que establecer DatabaseGenerated en DatabaseGeneratedOption.
Identity. Si no desea que sea una clave de identidad, puede establecer el valor en DatabaseGeneratedOption.
None.
Índice
NOTE
EF 6.1 en adelante solo : el atributo de índice se presentó en Entity Framework 6,1. Si usa una versión anterior, no se
aplica la información de esta sección.
Puede crear un índice en una o más columnas mediante IndexAttribute . Si se agrega el atributo a una o varias
propiedades, EF creará el índice correspondiente en la base de datos al crear la base de datos, o scaffolding, las
llamadas CreateIndex correspondientes si usa migraciones de Code First.
Por ejemplo, el código siguiente generará un índice que se creará en la columna rating de la tabla posts en la
base de datos.
public class Post

{
[Index]
}
De forma predeterminada, el índice se denominará IX_<nombre de propiedad> (IX_clasificación en el
ejemplo anterior). No obstante, también puede especificar un nombre para el índice. En el ejemplo siguiente se
especifica que el índice se debe denominar PostRatingIndex .
[Index("PostRatingIndex")]
De forma predeterminada, los índices no son únicos, pero puede usar el parámetro con nombre de IsUnique
para especificar que un índice debe ser único. En el ejemplo siguiente se presenta un índice único en el nombre
de inicio de sesión de un usuario .
public class User

{
public int UserId { get; set; }
[Index(IsUnique = true)]
[StringLength(200)]

}
Índices de varias columnas

Los índices que abarcan varias columnas se especifican utilizando el mismo nombre en varias anotaciones de
índice para una tabla determinada. Al crear índices de varias columnas, debe especificar un orden para las
columnas en el índice. Por ejemplo, el código siguiente crea un índice de varias columnas en rating y BlogId
denominado IX_BlogIdAndRating . BlogId es la primera columna del índice y la clasificación es la segunda.
public class Post

{
[Index("IX_BlogIdAndRating", 2)]
[Index("IX_BlogIdAndRating", 1)]
}
Atributos de relación: InverseProperty y ForeignKey

NOTE
En esta página se proporciona información sobre cómo configurar las relaciones en el modelo de Code First con
anotaciones de datos. Para obtener información general sobre las relaciones en EF y cómo obtener acceso a los datos y
manipularlos mediante relaciones, vea relaciones & propiedades de navegación. *
La Convención Code First se encargará de las relaciones más comunes del modelo, pero hay algunos casos en
los que necesita ayuda.
Cambiar el nombre de la propiedad de clave en la clase de blog creó un problema con su relación para publicar.
Al generar la base de datos, Code First ve la propiedad BlogId en la clase post y la reconoce, por la Convención
de que coincide con un nombre de clase más "ID", como una clave externa a la clase de blog. Pero no hay
ninguna propiedad BlogId en la clase de blog. La solución para esto es crear una propiedad de navegación en la
publicación y utilizar la anotación de la información externa para que el código de ayuda entienda primero cómo
crear la relación entre las dos clases (mediante la propiedad post. BlogId), así como la forma de especificar
restricciones en el base.
public class Post

{
[ForeignKey("BlogId")]
}
La restricción en la base de datos muestra una relación entre InternalBlogs. PrimaryTrackingKey y posts. BlogId.
El InverseProperty se usa cuando se tienen varias relaciones entre las clases.

En la clase post, puede que desee realizar un seguimiento de quién escribió una entrada de blog y quién la editó.
A continuación se muestran dos nuevas propiedades de navegación para la clase post.
public Person CreatedBy { get; set; }

public Person UpdatedBy { get; set; }
También necesitará agregar en la clase Person a la que hacen referencia estas propiedades. La clase Person tiene
propiedades de navegación de vuelta a la publicación, una para todas las publicaciones escritas por la persona y
otra para todas las entradas actualizadas por esa persona.
public class Person

{
public List<Post> PostsWritten { get; set; }
public List<Post> PostsUpdated { get; set; }
}
Code First no puede hacer coincidir las propiedades de las dos clases por sí mismas. La tabla de base de datos
para las publicaciones debe tener una clave externa para la persona de CreatedBy y otra para la persona
UpdatedBy, pero Code First creará cuatro propiedades de clave externa: person_ID, Person_Id1, CreatedBy_ID y
UpdatedBy_ID.
Para corregir estos problemas, puede usar la anotación InverseProperty para especificar la alineación de las
propiedades.
[InverseProperty("CreatedBy")]
public List<Post> PostsWritten { get; set; }
[InverseProperty("UpdatedBy")]
public List<Post> PostsUpdated { get; set; }
Dado que la propiedad PostsWritten de Person sabe que esto hace referencia al tipo de envío, generará la
relación con post. CreatedBy. Del mismo modo, PostsUpdated se conectará a post. UpdatedBy. Y Code First no
crearán las claves externas adicionales.
Resumen
Las DataAnnotations no solo permiten describir la validación del lado cliente y del servidor en las clases Code
First, sino que también permiten mejorar e incluso corregir las suposiciones que Code First realizará sobre las
clases en función de sus convenciones. Con DataAnnotations no solo puede controlar la generación de esquemas
de base de datos, sino que también puede asignar las clases Code First a una base de datos existente
previamente.
Aunque son muy flexibles, tenga en cuenta que las anotaciones solo proporcionan los cambios de configuración
más necesarios que se pueden realizar en las clases Code First. Para configurar las clases para algunos de los
casos extremos, debe buscar el mecanismo de configuración alternativo, la API fluida de Code First.
Definir DbSets
Al desarrollar con el flujo de trabajo de Code First se define un DbContext derivado que representa la sesión con la
base de datos y expone un DbSet para cada tipo del modelo. En este tema se tratan las distintas formas en que se
pueden definir las propiedades de DbSet.
DbContext con propiedades DbSet

El caso común que se muestra en Code First ejemplos es tener un DbContext con propiedades DbSet automáticas
públicas para los tipos de entidad del modelo. Por ejemplo:

{
}
Cuando se usa en modo de Code First, se configurarán los blogs y los envíos como tipos de entidad, así como la
configuración de otros tipos accesibles desde ellos. Además, DbContext llamará automáticamente al establecedor
para cada una de estas propiedades con el fin de establecer una instancia del DbSet adecuado.
DbContext con propiedades IDbSet

Existen situaciones, como cuando se crean simulacros o simulaciones, donde resulta más útil declarar las
propiedades set mediante una interfaz. En tales casos, se puede usar la interfaz IDbSet en lugar de DbSet. Por
ejemplo:

{
public IDbSet<Blog> Blogs { get; set; }
public IDbSet<Post> Posts { get; set; }
}
Este contexto funciona exactamente de la misma manera que el contexto que usa la clase DbSet para sus
propiedades set.
DbContext con propiedades set de solo lectura

Si no desea exponer establecedores públicos para las propiedades DbSet o IDbSet, puede crear propiedades de
solo lectura y crear las instancias de conjunto. Por ejemplo:
{
public DbSet<Blog> Blogs
{
get { return Set<Blog>(); }
}
public DbSet<Post> Posts

{
get { return Set<Post>(); }
}
}
Tenga en cuenta que DbContext almacena en caché la instancia de DbSet devuelta por el método Set para que cada
una de estas propiedades devuelva la misma instancia cada vez que se llame a.
La detección de tipos de entidad para Code First funciona de la misma manera que en las propiedades con
captadores y establecedores públicos.
Compatibilidad con enum-Code First
NOTE
EF5 y versiones posteriores: las características, las API, etc. que se describen en esta página se introdujeron en Entity
Framework 5. Si usa una versión anterior, no se aplica parte o la totalidad de la información.
Este tutorial de vídeo y paso a paso muestra cómo utilizar tipos de enumeración con Entity Framework Code First.
También se muestra cómo usar las enumeraciones en una consulta LINQ.
En este tutorial se utilizará Code First para crear una nueva base de datos, pero también puede usar code First para
asignarla a una base de datos existente.
La compatibilidad con la enumeración se presentó en Entity Framework 5. Para usar las nuevas características,
como las enumeraciones, los tipos de datos espaciales y las funciones con valores de tabla, debe tener como
destino .NET Framework 4,5. Visual Studio 2012 tiene como destino .NET 4,5 de forma predeterminada.
En Entity Framework, una enumeración puede tener los siguientes tipos subyacentes: byte , Int16 , Int32 , Int64 o
SByte .

En este vídeo se muestra cómo utilizar tipos de enumeración con Code First de Entity Framework. También se
muestra cómo usar las enumeraciones en una consulta LINQ.
Presentada por : Julia Kornich
Requisitos previos
Deberá tener instalado Visual Studio 2012, Ultimate, Premium, Professional o Web Express Edition para completar
este tutorial.
Configurar el proyecto
1. Abra Visual Studio 2012
2. En el menú archivo , seleccione nuevo y, a continuación, haga clic en proyecto .
3. En el panel izquierdo, haga clic en Visual C# y, a continuación, seleccione la plantilla de consola .
4. Escriba EnumCodeFirst como nombre del proyecto y haga clic en Aceptar .
Definir un nuevo modelo mediante Code First

conceptual (de dominio). El código siguiente define la clase Department.
El código también define la enumeración DepartmentNames. De forma predeterminada, la enumeración es de tipo
int . La propiedad Name de la clase Department es del tipo DepartmentNames.
Abra el archivo Program.cs y pegue las siguientes definiciones de clase.
public enum DepartmentNames

{
English,
Math,
Economics
}
public partial class Department

{
public DepartmentNames Name { get; set; }
}
Definir el tipo derivado de DbContext

DbSet<de la carpa>. Las propiedades de DbSet<la> de la carpa permiten que el contexto sepa qué tipos desea
incluir en el modelo.
Los tipos DbContext y DbSet se definen en el ensamblado EntityFramework. Se agregará una referencia a este
archivo DLL mediante el paquete NuGet EntityFramework.
1. En Explorador de soluciones, haga clic con el botón derecho en el nombre del proyecto.
2. Seleccione administrar paquetes NuGet.. .
3. En el cuadro de diálogo administrar paquetes NuGet, seleccione la pestaña en línea y elija el paquete
EntityFramework .
4. Haga clic en Instalar .
Tenga en cuenta que, además del ensamblado EntityFramework, también se agregan las referencias a los
ensamblados System. ComponentModel. DataAnnotations y System. Data. Entity.
En la parte superior del archivo Program.cs, agregue la siguiente instrucción using:
En Program.cs, agregue la definición de contexto.
public partial class EnumTestContext : DbContext

{
public DbSet<Department> Departments { get; set; }
}
Conservar y recuperar datos

Abra el archivo Program.cs en el que se define el método Main. Agregue el código siguiente a la función main. El
código agrega un nuevo objeto Department al contexto. Después guarda los datos. El código también ejecuta una
consulta LINQ que devuelve un departamento en el que el nombre es DepartmentNames. English.
using (var context = new EnumTestContext())

{
context.Departments.Add(new Department { Name = DepartmentNames.English });
var department = (from d in context.Departments

where d.Name == DepartmentNames.English
select d).FirstOrDefault();
Console.WriteLine(
"DepartmentID: {0} Name: {1}",
department.DepartmentID,
department.Name);
}
Compile y ejecute la aplicación. El programa produce el siguiente resultado:
DepartmentID: 1 Name: English
Ver la base de datos generada

Al ejecutar la aplicación por primera vez, el Entity Framework crea una base de datos automáticamente. Dado que
tenemos instalado Visual Studio 2012, la base de datos se creará en la instancia de LocalDB. De forma
predeterminada, el Entity Framework nombra la base de datos después del nombre completo del contexto
derivado (para este ejemplo, que es EnumCodeFirst. EnumTestContext ). Las veces posteriores en las que se
utilizará la base de datos existente.
Tenga en cuenta que si realiza cambios en el modelo una vez creada la base de datos, debe utilizar Migraciones de
Code First para actualizar el esquema de la base de datos. Vea code First en una nueva base de datos para obtener
un ejemplo del uso de las migraciones.
Para ver la base de datos y los datos, haga lo siguiente:
1. En el menú principal de Visual Studio 2012, seleccione ver -> Explorador de objetos de SQL Ser ver .
2. Si LocalDB no está en la lista de servidores, haga clic con el botón secundario del mouse en SQL Ser ver y
seleccione Agregar SQL Ser ver usar la autenticación de Windows predeterminada para conectarse a la
instancia de LocalDB.
3. Expandir el nodo LocalDB
4. Desabra la carpeta bases de datos para ver la nueva base de datos y vaya a la tabla Depar tment . tenga en
cuenta que Code First no crea una tabla que se asigne al tipo de enumeración
5. Para ver los datos, haga clic con el botón derecho en la tabla y seleccione ver datos .
Resumen
En este tutorial, hemos visto cómo usar los tipos de enumeración con Entity Framework Code First.
Code First espacial
NOTE
En el tutorial de vídeo y paso a paso se muestra cómo asignar tipos espaciales con Entity Framework Code First.
También se muestra cómo usar una consulta LINQ para buscar una distancia entre dos ubicaciones.
En este tutorial se utilizará Code First para crear una nueva base de datos, pero también puede usar code First a
una base de datos existente.
La compatibilidad con tipos espaciales se presentó en Entity Framework 5. Tenga en cuenta que para usar las
nuevas características, como el tipo espacial, las enumeraciones y las funciones con valores de tabla, debe tener
como destino .NET Framework 4,5. Visual Studio 2012 tiene como destino .NET 4,5 de forma predeterminada.
Para usar los tipos de datos espaciales, también debe usar un proveedor de Entity Framework que tenga
compatibilidad espacial. Consulte compatibilidad con proveedores para tipos espaciales para obtener más
información.
Hay dos tipos de datos espaciales principales: Geography y Geometry. El tipo de datos Geography almacena los
datos de datos elipsoidales (por ejemplo, las coordenadas de latitud y longitud de GPS). El tipo de datos Geometry
representa el sistema de coordenadas euclidiana (plano).

Este vídeo muestra cómo asignar tipos espaciales con Entity Framework Code First. También se muestra cómo
usar una consulta LINQ para buscar una distancia entre dos ubicaciones.
Requisitos previos
este tutorial.
4. Escriba SpatialCodeFirst como nombre del proyecto y haga clic en Aceptar .
Definir un nuevo modelo mediante Code First

conceptual (de dominio). El código siguiente define la clase University.
La Universidad tiene la propiedad Location del tipo DbGeography. Para usar el tipo DbGeography, debe agregar
una referencia al ensamblado System. Data. Entity y también agregar la instrucción using System. Data. Spatial.
Abra el archivo Program.cs y pegue las siguientes instrucciones Using en la parte superior del archivo:
using System.Data.Spatial;
Agregue la siguiente definición de clase University al archivo Program.cs.
public class University

{
public int UniversityID { get; set; }
public DbGeography Location { get; set; }
}
Definir el tipo derivado de DbContext

DbSet<de la carpa>. Las propiedades de DbSet<la> de la carpa permiten que el contexto sepa qué tipos desea
incluir en el modelo.
Los tipos DbContext y DbSet se definen en el ensamblado EntityFramework. Se agregará una referencia a este
archivo DLL mediante el paquete NuGet EntityFramework.
1. En Explorador de soluciones, haga clic con el botón derecho en el nombre del proyecto.
2. Seleccione administrar paquetes NuGet.. .
3. En el cuadro de diálogo administrar paquetes NuGet, seleccione la pestaña en línea y elija el paquete
EntityFramework .
4. Haga clic en Instalar .
Tenga en cuenta que, además del ensamblado EntityFramework, también se agrega una referencia al ensamblado
System. ComponentModel. DataAnnotations.
En la parte superior del archivo Program.cs, agregue la siguiente instrucción using:
En Program.cs, agregue la definición de contexto.
public partial class UniversityContext : DbContext

{
public DbSet<University> Universities { get; set; }
}

Abra el archivo Program.cs en el que se define el método Main. Agregue el código siguiente a la función main.
El código agrega dos nuevos objetos universitarios al contexto. Las propiedades espaciales se inicializan mediante
el método DbGeography. FromText. El punto de geografía representado como WellKnownText se pasa al método.
Después, el código guarda los datos. A continuación, se crea y se ejecuta la consulta LINQ que devuelve un objeto
University donde su ubicación es más cercana a la ubicación especificada.
using (var context = new UniversityContext ())

{
context.Universities.Add(new University()
{
Name = "Graphic Design Institute",
Location = DbGeography.FromText("POINT(-122.336106 47.605049)"),
});
context. Universities.Add(new University()

{
Name = "School of Fine Art",
});
var myLocation = DbGeography.FromText("POINT(-122.296623 47.640405)");
var university = (from u in context.Universities

orderby u.Location.Distance(myLocation)
select u).FirstOrDefault();
Console.WriteLine(
"The closest University to you is: {0}.",
university.Name);
}
The closest University to you is: School of Fine Art.
Ver la base de datos generada

Al ejecutar la aplicación por primera vez, el Entity Framework crea una base de datos automáticamente. Dado que
tenemos instalado Visual Studio 2012, la base de datos se creará en la instancia de LocalDB. De forma
predeterminada, el Entity Framework nombra la base de datos después del nombre completo del contexto
derivado (en este ejemplo, que es SpatialCodeFirst. UniversityContext ). Las veces posteriores en las que se
utilizará la base de datos existente.
Tenga en cuenta que si realiza cambios en el modelo una vez creada la base de datos, debe utilizar Migraciones de
Code First para actualizar el esquema de la base de datos. Vea code First en una nueva base de datos para obtener
un ejemplo del uso de las migraciones.
Para ver la base de datos y los datos, haga lo siguiente:
1. En el menú principal de Visual Studio 2012, seleccione ver -> Explorador de objetos de SQL Ser ver .
2. Si LocalDB no está en la lista de servidores, haga clic con el botón secundario del mouse en SQL Ser ver y
seleccione Agregar SQL Ser ver usar la autenticación de Windows predeterminada para conectarse a la
instancia de LocalDB.
3. Expandir el nodo LocalDB
4. Desdoblar la carpeta bases de datos para ver la nueva base de datos y examinar la tabla universidades
5. Para ver los datos, haga clic con el botón derecho en la tabla y seleccione ver datos .
Resumen
En este tutorial, hemos visto cómo usar los tipos espaciales con Entity Framework Code First.
Convenciones de Code First
Code First le permite describir un modelo mediante C# o Visual Basic clases .net. La forma básica del modelo se
detecta mediante el uso de convenciones. Las convenciones son conjuntos de reglas que se utilizan para
configurar automáticamente un modelo conceptual basado en definiciones de clase al trabajar con Code First. Las
convenciones se definen en el espacio de nombres System. Data. Entity. ModelConfiguration. Conventions.
Puede seguir configurando el modelo con anotaciones de datos o la API fluida. Se da prioridad a la configuración a
través de la API fluida, seguida de las anotaciones de datos y, a continuación, las convenciones. Para obtener más
información, vea anotaciones de datos, API fluidas, relaciones, tipos de API fluidas & propiedades y API fluida con
VB.net.
Puede encontrar una lista detallada de las convenciones de Code First en la documentación de la API. En este tema
se proporciona información general sobre las convenciones utilizadas por Code First.
Detección de tipos
conceptual (de dominio). Además de definir las clases, también debe dejar que DbContext sepa qué tipos quiere
incluir en el modelo. Para ello, defina una clase de contexto que derive de DbContext y exponga propiedades
DbSet para los tipos que desea que formen parte del modelo. Code First incluirá estos tipos y también extraerá
todos los tipos a los que se hace referencia, aunque los tipos a los que se hace referencia se hayan definido en un
ensamblado diferente.
Si los tipos participan en una jerarquía de herencia, basta con definir una propiedad DbSet para la clase base y los
tipos derivados se incluirán automáticamente, si están en el mismo ensamblado que la clase base.
En el ejemplo siguiente, solo hay una propiedad DbSet definida en la clase SchoolEntities (depar tments ). Code
First usa esta propiedad para detectar y extraer todos los tipos a los que se hace referencia.
public class SchoolEntities : DbContext
{
}

{
// Primary key
// Navigation property
}
public class Course

{
// Primary key

// Foreign key
// Navigation properties
}
public partial class OnlineCourse : Course

{
public string URL { get; set; }
}
public partial class OnsiteCourse : Course

{
public string Location { get; set; }
public string Days { get; set; }
public System.DateTime Time { get; set; }
}
Si desea excluir un tipo del modelo, use el atributo NotMapped o la API fluida DbModelBuilder. ignore .
modelBuilder.Ignore<Department>();
Convención de clave principal

Code First infiere que una propiedad es una clave principal si una propiedad de una clase se denomina "ID" (no
distingue mayúsculas de minúsculas) o el nombre de clase seguido de "ID". Si el tipo de la propiedad de clave
principal es numérico o GUID, se configurará como una columna de identidad.

{
// Primary key
. . .
}
Convención de relación
En Entity Framework, las propiedades de navegación proporcionan una manera de navegar por una relación entre
dos tipos de entidad. Cada objeto puede tener una propiedad de navegación para cada relación en la que
participa. Las propiedades de navegación permiten navegar y administrar las relaciones en ambas direcciones,
devolviendo un objeto de referencia (si la multiplicidad es uno o cero o uno) o una colección (si la multiplicidad es
muchas). Code First deduce las relaciones basadas en las propiedades de navegación definidas en los tipos.
Además de las propiedades de navegación, se recomienda incluir las propiedades de clave externa en los tipos que
representan los objetos dependientes. Cualquier propiedad con el mismo tipo de datos que la propiedad de clave
principal principal y con un nombre que sigue a uno de los siguientes formatos representa una clave externa para
la relación: '<nombre de propiedad de navegación><nombre de propiedad de clave principal de la entidad de
seguridad>', '<nombre de la clase principal><el nombre de la propiedad de clave principal ', o '><> Si se
encuentran varias coincidencias, se da prioridad en el orden indicado anteriormente. La detección de clave externa
no distingue entre mayúsculas y minúsculas. Cuando se detecta una propiedad de clave externa, Code First deduce
la multiplicidad de la relación en función de la nulabilidad de la clave externa. Si la propiedad admite valores
NULL, la relación se registra como opcional; de lo contrario, la relación se registra según sea necesario.
Si una clave externa de la entidad dependiente no admite valores NULL, Code First establece Cascade delete en la
relación. Si una clave externa de la entidad dependiente admite valores NULL, Code First no establece Cascade
delete en la relación y, cuando se elimina la entidad de seguridad, la clave externa se establecerá en NULL. El
comportamiento de la multiplicidad y la eliminación en cascada detectados por la Convención se pueden invalidar
mediante la API fluida.
En el ejemplo siguiente se usan las propiedades de navegación y una clave externa para definir la relación entre
las clases Department y Course.

{
// Primary key
}
public class Course

{
// Primary key

// Foreign key
}
NOTE
Si tiene varias relaciones entre los mismos tipos (por ejemplo, supongamos que define las clases Person y book , donde la
clase Person contiene las propiedades de navegación ReviewedBooks y AuthoredBooks y la clase book contiene las
propiedades de navegación autor y Revisor ), debe configurar manualmente las relaciones mediante anotaciones de datos
o la API fluida. Para obtener más información, vea anotaciones de datos: relaciones y API fluida.
Convención de tipos complejos
Cuando Code First detecta una definición de clase en la que no se puede inferir una clave principal y no se registra
ninguna clave principal a través de anotaciones de datos o la API fluida, el tipo se registra automáticamente como
un tipo complejo. La detección de tipos complejos también requiere que el tipo no tenga propiedades que hagan
referencia a los tipos de entidad y no se haga referencia a ellos desde una propiedad de colección en otro tipo.
Dadas las siguientes definiciones de clase Code First deduciría que los detalles son un tipo complejo porque no
tiene ninguna clave principal.

{
public OnsiteCourse()
{
Details = new Details();
}
public Details Details { get; set; }

}
public class Details

{
}
Convención de cadena de conexión

Para obtener información sobre las convenciones que usa DbContext para detectar la conexión que se va a usar ,
consulte conexiones y modelos.
Quitar convenciones
Puede quitar cualquiera de las convenciones definidas en el espacio de nombres System. Data. Entity.
ModelConfiguration. Conventions. En el ejemplo siguiente se quita PluralizingTableNameConvention .

{
. . .

{
// Configure Code First to ignore PluralizingTableName convention
// If you keep this convention, the generated tables
// will have pluralized names.
modelBuilder.Conventions.Remove<PluralizingTableNameConvention>();
}
}
Convenciones personalizadas
Las convenciones personalizadas se admiten en EF6 en adelante. Para obtener más información, vea convenciones
de Code First personalizadas.
Convenciones de Code First personalizadas
NOTE
Solo EF6 y versiones posteriores : las características, las API, etc. que se tratan en esta página se han incluido a partir
de Entity Framework 6. Si usa una versión anterior, no se aplica parte o la totalidad de la información.
Al utilizar Code First el modelo se calcula a partir de las clases mediante un conjunto de convenciones. Las
convenciones de Code First predeterminadas determinan aspectos como la propiedad que se convierte en la
clave principal de una entidad, el nombre de la tabla a la que se asigna una entidad y la precisión y escala que una
columna decimal tiene de forma predeterminada.
A veces, estas convenciones predeterminadas no son ideales para el modelo y debe solucionarse configurando
muchas entidades individuales mediante anotaciones de datos o la API fluida. Las convenciones de Code First
personalizadas le permiten definir sus propias convenciones que proporcionan valores predeterminados de
configuración para el modelo. En este tutorial, exploraremos los distintos tipos de convenciones personalizadas y
cómo crear cada una de ellas.
Convenciones basadas en modelos

En esta página se tratan las convenciones personalizadas de la API de DbModelBuilder. Esta API debe ser
suficiente para la creación de la mayoría de las convenciones personalizadas. Sin embargo, también existe la
posibilidad de crear convenciones basadas en modelos: convenciones que manipulan el modelo final una vez que
se crea: para controlar escenarios avanzados. Para obtener más información, vea convenciones basadas en
modelos.
Nuestro modelo
Comencemos por definir un modelo simple que podamos usar con nuestras convenciones. Agregue las clases
siguientes al proyecto.
using System;
using System.Linq;

{
static ProductContext()
{
Database.SetInitializer(new DropCreateDatabaseIfModelChanges<ProductContext>());
}

}

{
public int Key { get; set; }
public decimal? Price { get; set; }
public DateTime? ReleaseDate { get; set; }
public ProductCategory Category { get; set; }
}
public class ProductCategory

{
public int Key { get; set; }
public List<Product> Products { get; set; }
}
Introducción a las convenciones personalizadas

Vamos a escribir una Convención que configura cualquier propiedad denominada clave para que sea la clave
principal de su tipo de entidad.
Las convenciones se habilitan en el generador de modelos, al que se puede tener acceso invalidando
OnModelCreating en el contexto. Actualice la clase ProductContext como se indica a continuación:

{
static ProductContext()
{
Database.SetInitializer(new DropCreateDatabaseIfModelChanges<ProductContext>());
}

{
modelBuilder.Properties()
.Where(p => p.Name == "Key")
.Configure(p => p.IsKey());
}
}
Ahora, cualquier propiedad de nuestro modelo denominado Key se configurará como la clave principal de la
entidad de la que forma parte.
También podríamos hacer que nuestras convenciones sean más específicas filtrando por el tipo de propiedad que
vamos a configurar:
modelBuilder.Properties<int>()
.Where(p => p.Name == "Key")
Esto configurará todas las propiedades que se llaman clave como la clave principal de su entidad, pero solo si son
un entero.
Una característica interesante del método IsKey es que es aditiva. Lo que significa que si llama a IsKey en varias
propiedades y se convertirán en parte de una clave compuesta. La única ADVERTENCIA es que, cuando se
especifican varias propiedades para una clave, también se debe especificar un orden para esas propiedades. Para
ello, puede llamar al método HasColumnOrder como se indica a continuación:
.Where(x => x.Name == "Key")
.Configure(x => x.IsKey().HasColumnOrder(1));
.Where(x => x.Name == "Name")
.Configure(x => x.IsKey().HasColumnOrder(2));
Este código configurará los tipos de nuestro modelo para tener una clave compuesta que consta de la columna
de clave int y la columna de nombre de cadena. Si vemos el modelo en el diseñador, tendría el siguiente aspecto:
Otro ejemplo de convenciones de propiedad consiste en configurar todas las propiedades de fecha y hora de mi
modelo para que se asignen al tipo datetime2 en SQL Server en lugar de DateTime. Puede conseguirlo con lo
siguiente:
modelBuilder.Properties<DateTime>()
.Configure(c => c.HasColumnType("datetime2"));
Clases de Convención
Otra forma de definir convenciones es usar una clase de Convención para encapsular la Convención. Cuando se
usa una clase de Convención, se crea un tipo que hereda de la clase de Convención en el espacio de nombres
System. Data. Entity. ModelConfiguration. Conventions.
Se puede crear una clase de Convención con la Convención datetime2 que se mostró anteriormente haciendo lo
siguiente:
public class DateTime2Convention : Convention
{
public DateTime2Convention()
{
this.Properties<DateTime>()
.Configure(c => c.HasColumnType("datetime2"));
}
}
Para indicar a EF que use esta Convención, agréguelo a la colección de convenciones en OnModelCreating, que si
ha estado siguiendo con el tutorial tendrá el siguiente aspecto:

{
.Where(p => p.Name.EndsWith("Key"))
modelBuilder.Conventions.Add(new DateTime2Convention());
}
Como puede ver, agregamos una instancia de nuestra Convención a la colección de convenciones. Heredar de la
Convención proporciona una manera cómoda de agrupar y compartir convenciones entre equipos o proyectos.
Por ejemplo, podría tener una biblioteca de clases con un conjunto común de convenciones que usan todos los
proyectos de la organización.
Atributos personalizados
Otro gran uso de convenciones es habilitar nuevos atributos que se van a usar al configurar un modelo. Para
ilustrar esto, vamos a crear un atributo que se puede usar para marcar las propiedades de cadena como no
Unicode.
[AttributeUsage(AttributeTargets.Property, AllowMultiple = false)]

public class NonUnicode : Attribute
{
}
Ahora, vamos a crear una Convención para aplicar este atributo a nuestro modelo:
.Where(x => x.GetCustomAttributes(false).OfType<NonUnicode>().Any())
.Configure(c => c.IsUnicode(false));
Con esta Convención, podemos agregar el atributo NonUnicode a cualquiera de nuestras propiedades de cadena,
lo que significa que la columna de la base de datos se almacenará como varchar en lugar de nvarchar.
Una cuestión que hay que tener en cuenta sobre esta Convención es que si coloca el atributo NonUnicode en un
valor distinto de una propiedad de cadena, se producirá una excepción. Esto se debe a que no se puede
configurar IsUnicode en ningún tipo que no sea una cadena. Si esto ocurre, puede hacer que la Convención sea
más específica, de modo que filtre cualquier cosa que no sea una cadena.
Aunque la Convención anterior funciona para definir atributos personalizados, hay otra API que puede ser mucho
más fácil de usar, especialmente cuando se desea usar propiedades de la clase de atributo.
En este ejemplo, vamos a actualizar el atributo y cambiarlo a un atributo IsUnicode, de modo que tenga este
aspecto:
[AttributeUsage(AttributeTargets.Property, AllowMultiple = false)]

internal class IsUnicode : Attribute
{
public bool Unicode { get; set; }
public IsUnicode(bool isUnicode)

{
Unicode = isUnicode;
}
}
Una vez hecho esto, podemos establecer un valor bool en nuestro atributo para indicar a la Convención si una
propiedad debe ser Unicode o no. Podríamos hacer esto en la Convención que ya hemos tenido acceso a la
ClrProperty de la clase de configuración de la siguiente manera:
.Where(x => x.GetCustomAttributes(false).OfType<IsUnicode>().Any())
.Configure(c => c.IsUnicode(c.ClrPropertyInfo.GetCustomAttribute<IsUnicode>().Unicode));
Esto es bastante sencillo, pero hay una manera más concisa de lograrlo mediante el uso del método Having de la
API de convenciones. El método having tiene un parámetro de tipo FUNC<PropertyInfo, T> que acepta el
PropertyInfo igual que el método Where, pero se espera que devuelva un objeto. Si el objeto devuelto es null, la
propiedad no se configurará, lo que significa que puede filtrar las propiedades con ella como Where, pero es
diferente en que también capturará el objeto devuelto y lo pasará al método configure. Esto funciona de la
siguiente manera:
.Having(x =>x.GetCustomAttributes(false).OfType<IsUnicode>().FirstOrDefault())
.Configure((config, att) => config.IsUnicode(att.Unicode));
Los atributos personalizados no son la única razón para usar el método Having, es útil en cualquier lugar en el
que sea necesario saber sobre algo que está filtrando al configurar los tipos o las propiedades.
Configuración de tipos
Hasta ahora, todas nuestras convenciones se han realizado para propiedades, pero hay otra área de la API de
convenciones para configurar los tipos en el modelo. La experiencia es similar a las convenciones que hemos
encontrado hasta ahora, pero las opciones incluidas en configurar estarán en la entidad en lugar de en el nivel de
propiedad.
Una de las cosas que las convenciones de nivel de tipo pueden ser realmente útiles para es cambiar la
Convención de nomenclatura de tablas, ya sea para asignar a un esquema existente que difiere del valor
predeterminado de EF o para crear una nueva base de datos con una Convención de nomenclatura diferente. Para
ello, primero necesitamos un método que pueda aceptar TypeInfo para un tipo en nuestro modelo y que devuelva
el nombre de tabla de ese tipo:
private string GetTableName(Type type)
{
var result = Regex.Replace(type.Name, ".[A-Z]", m => m.Value[0] + "_" + m.Value[1]);
return result.ToLower();
}
Este método toma un tipo y devuelve una cadena que usa minúsculas con carácter de subrayado en lugar de
CamelCase. En nuestro modelo, esto significa que la clase ProductCategory se asignará a una tabla denominada
Product_categoría en lugar de a ProductCategories.
Una vez que tenemos ese método, podemos llamarlo en una Convención similar a la siguiente:
modelBuilder.Types()
.Configure(c => c.ToTable(GetTableName(c.ClrType)));
Esta Convención configura todos los tipos de nuestro modelo para que se asignen al nombre de tabla que se
devuelve desde nuestro método GetTableName. Esta Convención es equivalente a llamar al método ToTable para
cada entidad del modelo mediante la API fluida.
Un aspecto que se debe tener en cuenta es que, cuando se llama a ToTable EF, toma la cadena que se proporciona
como el nombre exacto de la tabla, sin la pluralización que normalmente haría al determinar los nombres de
tabla. Esta es la razón por la que el nombre de la tabla de nuestra Convención es_categoría del producto en lugar
de las categorías Product_. Podemos resolver esto en nuestra Convención realizando una llamada al servicio de
pluralización por nuestra parte.
En el código siguiente, usaremos la característica de resolución de dependencias agregada en EF6 para recuperar
el servicio de pluralización que EF habría usado y pluralando el nombre de la tabla.
private string GetTableName(Type type)

{
var pluralizationService = DbConfiguration.DependencyResolver.GetService<IPluralizationService>();
var result = pluralizationService.Pluralize(type.Name);
result = Regex.Replace(result, ".[A-Z]", m => m.Value[0] + "_" + m.Value[1]);
return result.ToLower();
}
NOTE
La versión genérica de GetService es un método de extensión en el espacio de nombres System. Data. Entity. Infrastructure.
DependencyResolution; tendrá que agregar una instrucción using al contexto para poder usarlo.
ToTable y herencia
Otro aspecto importante de ToTable es que si asigna explícitamente un tipo a una tabla determinada, puede
modificar la estrategia de asignación que utilizará EF. Si llama a ToTable para cada tipo de una jerarquía de
herencia, pasando el nombre de tipo como el nombre de la tabla como hicimos anteriormente, cambiará la
estrategia de asignación predeterminada de tabla por jerarquía (TPH) a tabla por tipo (TPT). La mejor manera de
describir esto es whith un ejemplo concreto:
public class Employee
{
}
public class Manager : Employee

{
public string SectionManaged { get; set; }
}
De forma predeterminada, tanto el empleado como el administrador están asignados a la misma tabla
(empleados) en la base de datos. La tabla contendrá empleados y directivos con una columna de discriminador
que le indicará qué tipo de instancia se almacena en cada fila. Esta es la asignación TPH, ya que hay una sola tabla
para la jerarquía. Sin embargo, si llama a ToTable en ambos Classe, cada tipo se asignará a su propia tabla,
también conocida como TPT, ya que cada tipo tiene su propia tabla.
modelBuilder.Types()
.Configure(c=>c.ToTable(c.ClrType.Name));
El código anterior se asignará a una estructura de tabla similar a la siguiente:
Puede evitar esto y mantener la asignación de TPH predeterminada de dos maneras:

1. Llame a ToTable con el mismo nombre de tabla para cada tipo de la jerarquía.
2. Llame a ToTable solo en la clase base de la jerarquía, en el ejemplo que sería Employee.
Orden de ejecución
Las convenciones funcionan en la última manera de WINS, igual que la API fluida. Esto significa que, si escribe
dos convenciones que configuran la misma opción de la misma propiedad, la última que se ejecuta gana. Por
ejemplo, en el código que aparece debajo de la longitud máxima de todas las cadenas se establece en 500, pero
después se configuran todas las propiedades denominadas nombre del modelo para que tengan una longitud
máxima de 250.
modelBuilder.Properties<string>()
.Configure(c => c.HasMaxLength(500));
modelBuilder.Properties<string>()
.Where(x => x.Name == "Name")
.Configure(c => c.HasMaxLength(250));
Dado que la Convención para establecer la longitud máxima en 250 es después de la que establece todas las
cadenas en 500, todas las propiedades denominadas Name en nuestro modelo tendrán una MaxLength de 250
mientras que cualquier otra cadena, como descripciones, sería 500. El uso de convenciones de esta manera
significa que puede proporcionar una Convención General para tipos o propiedades en el modelo y, a
continuación, reemplazarlos para subconjuntos que son diferentes.
La API fluida y las anotaciones de datos también se pueden usar para invalidar una Convención en casos
concretos. En el ejemplo anterior, si hubiéramos usado la API fluida para establecer la longitud máxima de una
propiedad, podríamos haber colocado antes o después de la Convención, ya que la API fluida más específica
ganará más allá de la Convención de configuración más general.
Dado que las convenciones personalizadas podrían verse afectadas por las convenciones de Code First
predeterminadas, puede ser útil agregar convenciones para que se ejecuten antes o después de otra convención.
Para ello, puede usar los métodos AddBefore y AddAfter de la colección Conventions en su DbContext derivado.
El código siguiente agregaría la clase de Convención que hemos creado anteriormente para que se ejecute antes
de la Convención de detección de claves integrada.
modelBuilder.Conventions.AddBefore<IdKeyDiscoveryConvention>(new DateTime2Convention());
Este será el más utilizado al agregar convenciones que deban ejecutarse antes o después de las convenciones
integradas. puede encontrar una lista de las convenciones integradas aquí: System. Data. Entity.
ModelConfiguration. Conventions (espacio de nombres).
También puede quitar las convenciones que no desea que se apliquen al modelo. Para quitar una Convención, use
el método Remove. Este es un ejemplo de cómo quitar el PluralizingTableNameConvention.

{
}
Convenciones basadas en modelos
NOTE
Las convenciones basadas en modelos son un método avanzado de configuración del modelo basado en
convenciones. En la mayoría de los casos, se debe usar la API de la Convención de Code First personalizada en
DbModelBuilder . Antes de usar las convenciones basadas en modelos, se recomienda comprender la API de
DbModelBuilder para las convenciones.
Las convenciones basadas en modelos permiten la creación de convenciones que afectan a las propiedades y
tablas que no se pueden configurar a través de convenciones estándar. Algunos ejemplos son las columnas de
discriminador en los modelos de tabla por jerarquía y las columnas de asociación independientes.
Crear una Convención

El primer paso para crear una Convención basada en el modelo es elegir cuándo debe aplicarse la Convención en
el modelo. Hay dos tipos de convenciones del modelo: conceptual (espacio C) y almacén (espacio de S). Se aplica
una Convención de espacio C al modelo que se compila en la aplicación, mientras que una Convención de espacio
S se aplica a la versión del modelo que representa la base de datos y controla aspectos como el nombre de las
columnas generadas automáticamente.
Una Convención de modelo es una clase que se extiende desde IConceptualModelConvention o
IStoreModelConvention. Estas interfaces aceptan un tipo genérico que puede ser de tipo MetadataItem, que se usa
para filtrar el tipo de datos al que se aplica la Convención.
Agregar una Convención

Las convenciones de modelo se agregan de la misma manera que las clases de convenciones normales. En el
método OnModelCreating , agregue la Convención a la lista de convenciones de un modelo.
using System.Data.Entity.Core.Metadata.Edm;
using System.Data.Entity.ModelConfiguration.Conventions;
public class BlogContext : DbContext

{
public DbSet<Comment> Comments { get; set; }

{
modelBuilder.Conventions.Add<MyModelBasedConvention>();
}
}
También se puede Agregar una Convención en relación con otra Convención mediante los métodos Conventions.
AddBefore<> o Conventions. AddAfter<>. Para obtener más información acerca de las convenciones que se
aplican Entity Framework consulte la sección Notas.

{
modelBuilder.Conventions.AddAfter<IdKeyDiscoveryConvention>(new MyModelBasedConvention());
}
Ejemplo: Convención del modelo de discriminador

Cambiar el nombre de las columnas generadas por EF es un ejemplo de algo que no se puede hacer con las otras
API de convenciones. Se trata de una situación en la que el uso de convenciones de modelos es la única opción.
Un ejemplo de cómo usar una Convención basada en modelo para configurar las columnas generadas es
personalizar la forma en que se denominan las columnas de discriminador. A continuación se muestra un ejemplo
de una Convención basada en un modelo simple que cambia el nombre de todas las columnas del modelo
denominado "Discriminator" a "EntityType". Esto incluye las columnas que el programador simplemente denomina
"Discriminator". Dado que la columna "discriminadora" es una columna generada, esto debe ejecutarse en el
espacio de S.
class DiscriminatorRenamingConvention : IStoreModelConvention<EdmProperty>

{
public void Apply(EdmProperty property, DbModel model)
{
if (property.Name == "Discriminator")
{
property.Name = "EntityType";
}
}
}
Ejemplo: Convención de cambio de nombre general de IA

Otro ejemplo más complicado de convenciones basadas en modelos en acción consiste en configurar el modo en
que se asignan nombres a las asociaciones independientes (IAs). Se trata de una situación en la que se pueden
aplicar las convenciones de modelo, ya que las generadas por EF y no están presentes en el modelo al que puede
tener acceso la API de DbModelBuilder.
Cuando EF genera un IA, crea una columna denominada EntityType_KeyName. Por ejemplo, para una asociación
denominada Customer con una columna de clave denominada CustomerId, se generaría una columna
denominada Customer_CustomerId. La Convención siguiente quita el carácter '_' del nombre de columna que se
genera para el IA.
// Provides a convention for fixing the independent association (IA) foreign key column names.
public class ForeignKeyNamingConvention : IStoreModelConvention<AssociationType>
{
public void Apply(AssociationType association, DbModel model)

{
// Identify ForeignKey properties (including IAs)
if (association.IsForeignKey)
{
// rename FK columns
var constraint = association.Constraint;
if (DoPropertiesHaveDefaultNames(constraint.FromProperties, constraint.ToRole.Name,
constraint.ToProperties))
{
NormalizeForeignKeyProperties(constraint.FromProperties);
}
if (DoPropertiesHaveDefaultNames(constraint.ToProperties, constraint.FromRole.Name,
constraint.FromProperties))
{
NormalizeForeignKeyProperties(constraint.ToProperties);
}
}
}
private bool DoPropertiesHaveDefaultNames(ReadOnlyMetadataCollection<EdmProperty> properties, string

roleName, ReadOnlyMetadataCollection<EdmProperty> otherEndProperties)
{
if (properties.Count != otherEndProperties.Count)
{
return false;
}
for (int i = 0; i < properties.Count; ++i)

{
if (!properties[i].Name.EndsWith("_" + otherEndProperties[i].Name))
{
return false;
}
}
return true;
}
private void NormalizeForeignKeyProperties(ReadOnlyMetadataCollection<EdmProperty> properties)

{
for (int i = 0; i < properties.Count; ++i)
{
int underscoreIndex = properties[i].Name.IndexOf('_');
if (underscoreIndex > 0)
{
properties[i].Name = properties[i].Name.Remove(underscoreIndex, 1);
}
}
}
}
Extender las convenciones existentes

Si tiene que escribir una Convención similar a una de las convenciones que Entity Framework ya se aplican a su
modelo, siempre puede ampliar esa Convención para evitar tener que volver a escribirla desde el principio. Un
ejemplo de esto es reemplazar la Convención de coincidencia de ID. existente por una personalizada. Una ventaja
adicional para reemplazar la Convención de claves es que solo se llamará al método invalidado si no hay ninguna
clave ya detectada o configurada explícitamente. Aquí encontrará una lista de las convenciones utilizadas por Entity
Framework: http://msdn.microsoft.com/library/system.data.entity.modelconfiguration.conventions.aspx.
using System.Linq;
// Convention to detect primary key properties.

// Recognized naming patterns in order of precedence are:
// 1. 'Key'
// 2. [type name]Key
// Primary key detection is case insensitive.
public class CustomKeyDiscoveryConvention : KeyDiscoveryConvention
{
private const string Id = "Key";
protected override IEnumerable<EdmProperty> MatchKeyProperty(

EntityType entityType, IEnumerable<EdmProperty> primitiveProperties)
{
Debug.Assert(entityType != null);
Debug.Assert(primitiveProperties != null);
var matches = primitiveProperties

.Where(p => Id.Equals(p.Name, StringComparison.OrdinalIgnoreCase));
if (!matches.Any())
{
matches = primitiveProperties
.Where(p => (entityType.Name + Id).Equals(p.Name, StringComparison.OrdinalIgnoreCase));
}
// If the number of matches is more than one, then multiple properties matched differing only by
// case--for example, "Key" and "key".
if (matches.Count() > 1)
{
throw new InvalidOperationException("Multiple properties match the key convention");
}
return matches;
}
}
A continuación, necesitamos agregar la nueva Convención antes de la Convención de claves existente. Después de
agregar el CustomKeyDiscoveryConvention, podemos quitar el IdKeyDiscoveryConvention. Si no quitamos el
IdKeyDiscoveryConvention existente, esta Convención tendría prioridad sobre la Convención de detección de
identificadores, ya que se ejecuta en primer lugar, pero en caso de que no se encuentre ninguna propiedad "clave",
se ejecutará la Convención "ID". Vemos este comportamiento porque cada Convención Ve el modelo tal y como lo
ha actualizado la Convención anterior (en lugar de trabajar en él de forma independiente y todo combinado) para
que, por ejemplo, una Convención anterior actualizara un nombre de columna para que coincida con algo de le
interesa su convención personalizada (cuando antes de que el nombre no sea de interés) se aplique a esa columna.
{

{
modelBuilder.Conventions.AddBefore<IdKeyDiscoveryConvention>(new CustomKeyDiscoveryConvention());
modelBuilder.Conventions.Remove<IdKeyDiscoveryConvention>();
}
}
Notas
Una lista de las convenciones aplicadas actualmente por Entity Framework está disponible en la documentación de
MSDN aquí: http://msdn.microsoft.com/library/system.data.entity.modelconfiguration.conventions.aspx. Esta lista
se extrae directamente del código fuente. El código fuente de Entity Framework 6 está disponible en GitHub y
muchas de las convenciones utilizadas por Entity Framework son buenos puntos de partida para las convenciones
basadas en modelos personalizados.
API fluidas: relaciones
NOTE
En esta página se proporciona información sobre cómo configurar las relaciones en el modelo de Code First mediante la API
fluida. Para obtener información general sobre las relaciones en EF y cómo obtener acceso a los datos y manipularlos
mediante relaciones, vea relaciones & propiedades de navegación.
Cuando se trabaja con Code First, se define el modelo definiendo las clases CLR del dominio. De forma
predeterminada, Entity Framework utiliza las convenciones de Code First para asignar las clases al esquema de la
base de datos. Si utiliza las convenciones de nomenclatura de Code First, en la mayoría de los casos puede confiar
en Code First para configurar las relaciones entre las tablas en función de las claves externas y las propiedades de
navegación que defina en las clases. Si no sigue las convenciones al definir las clases, o si desea cambiar la forma
en que funcionan las convenciones, puede usar la API fluida o las anotaciones de datos para configurar las clases
de modo que Code First pueda asignar las relaciones entre las tablas.
Introducción
Al configurar una relación con la API fluida, empiece con la instancia de EntityTypeConfiguration y, a continuación,
use el método HasRequired, HasOptional o HasMany para especificar el tipo de relación en la que participa esta
entidad. Los métodos HasRequired y HasOptional toman una expresión lambda que representa una propiedad de
navegación de referencia. El método HasMany toma una expresión lambda que representa una propiedad de
navegación de colección. Después, puede configurar una propiedad de navegación inversa mediante los métodos
WithRequired, WithOptional y WithMany. Estos métodos tienen sobrecargas que no toman argumentos y se
pueden usar para especificar la cardinalidad con navegaciones unidireccionales.
Después, puede configurar las propiedades de clave externa mediante el método HasForeignKey. Este método
toma una expresión lambda que representa la propiedad que se va a usar como clave externa.
Configuración de una relación requerida-to-Optional (uno a cero o

uno)
En el ejemplo siguiente se configura una relación de uno a cero o uno. OfficeAssignment tiene la propiedad
InstructorID que es una clave principal y una clave externa, ya que el nombre de la propiedad no sigue la
Convención que el método Haskey (utiliza para configurar la clave principal.
// Configure the primary key for the OfficeAssignment

modelBuilder.Entity<OfficeAssignment>()
.HasKey(t => t.InstructorID);
// Map one-to-zero or one relationship

.HasRequired(t => t.Instructor)
.WithOptional(t => t.OfficeAssignment);
Configurar una relación en la que se requieren ambos extremos (uno a

uno)
En la mayoría de los casos Entity Framework puede deducir qué tipo es el dependiente y cuál es la entidad de
seguridad de una relación. Sin embargo, cuando se requieren ambos extremos de la relación o ambos lados son
opcionales Entity Framework no puede identificar el dependiente y el principal. Cuando se requieran ambos
extremos de la relación, use WithRequiredPrincipal o WithRequiredDependent después del método HasRequired.
Cuando ambos extremos de la relación sean opcionales, use WithOptionalPrincipal o WithOptionalDependent
después del método HasOptional.
// Configure the primary key for the OfficeAssignment

modelBuilder.Entity<Instructor>()
.HasRequired(t => t.OfficeAssignment)
.WithRequiredPrincipal(t => t.Instructor);
Configuración de una relación de varios a varios

El siguiente código configura una relación de varios a varios entre los tipos Course y instructor. En el ejemplo
siguiente, se usan las convenciones de Code First predeterminadas para crear una tabla de combinación. Como
resultado, la tabla CourseInstructor se crea con Course_CourseID y Instructor_InstructorID columnas.
modelBuilder.Entity<Course>()
.HasMany(t => t.Instructors)
.WithMany(t => t.Courses)
Si desea especificar el nombre de la tabla de combinación y los nombres de las columnas de la tabla, debe
realizar una configuración adicional mediante el método map. El código siguiente genera la tabla
CourseInstructor con las columnas CourseID y InstructorID.
.HasMany(t => t.Instructors)
.Map(m =>
{
m.ToTable("CourseInstructor");
m.MapLeftKey("CourseID");
m.MapRightKey("InstructorID");
});
Configurar una relación con una propiedad de navegación

Una relación unidireccional (también denominada unidireccional) es cuando se define una propiedad de
navegación solo en uno de los extremos de la relación y no en ambos. Por Convención, Code First siempre
interpreta una relación unidireccional como uno a varios. Por ejemplo, si desea una relación de uno a uno entre
instructor y OfficeAssignment, donde tiene una propiedad de navegación solo en el tipo de instructor, debe usar
la API fluida para configurar esta relación.
// Configure the primary Key for the OfficeAssignment

.WithRequiredPrincipal();
Habilitar la eliminación en cascada
Puede configurar la eliminación en cascada en una relación mediante el método WillCascadeOnDelete. Si una
clave externa de la entidad dependiente no admite valores NULL, Code First establece Cascade delete en la
relación. Si una clave externa de la entidad dependiente admite valores NULL, Code First no establece Cascade
delete en la relación y, cuando se elimina la entidad de seguridad, la clave externa se establecerá en NULL.
Puede quitar estas convenciones de eliminación en cascada mediante:
modelBuilder. Conventions. Remove<OneToManyCascadeDeleteConvention>()
modelBuilder. Conventions. Remove<ManyToManyCascadeDeleteConvention>()
El código siguiente configura la relación para que sea necesaria y, a continuación, deshabilita la eliminación en
cascada.
.HasRequired(t => t.Department)
.HasForeignKey(d => d.DepartmentID)
.WillCascadeOnDelete(false);
Configurar una clave externa compuesta

Si la clave principal del tipo de departamento consta de las propiedades DepartmentID y Name, debe configurar
la clave principal para el Departamento y la clave externa en los tipos de curso como se indica a continuación:
// Composite primary key

modelBuilder.Entity<Department>()
.HasKey(d => new { d.DepartmentID, d.Name });
// Composite foreign key

.HasRequired(c => c.Department)
.WithMany(d => d.Courses)
.HasForeignKey(d => new { d.DepartmentID, d.DepartmentName });
Cambiar el nombre de una clave externa que no está definida en el

modelo
Si decide no definir una clave externa en el tipo CLR, pero desea especificar el nombre que debe tener en la base
de datos, haga lo siguiente:
.Map(m => m.MapKey("ChangedDepartmentID"));
Configuración de un nombre de clave externa que no sigue la

Convención de Code First
Si la propiedad de clave externa de la clase Course se llama SomeDepartmentID en lugar de DepartmentID,
deberá hacer lo siguiente para especificar que SomeDepartmentID será la clave externa:
.WithMany(d => d.Courses)
.HasForeignKey(c => c.SomeDepartmentID);
Modelo usado en los ejemplos

El siguiente modelo de Code First se usa para los ejemplos de esta página.
// add a reference to System.ComponentModel.DataAnnotations DLL
using System;

{
public DbSet<Course> Courses { get; set; }
public DbSet<Instructor> Instructors { get; set; }
public DbSet<OfficeAssignment> OfficeAssignments { get; set; }

{
// If you keep this convention then the generated tables will have pluralized names.
}
}

{
public Department()
{
}
// Primary key
public System.DateTime StartDate { get; set; }
public int? Administrator { get; set; }
public virtual ICollection<Course> Courses { get; private set; }
}
public class Course

{
public Course()
{
this.Instructors = new HashSet<Instructor>();
}
// Primary key

// Foreign key
public virtual ICollection<Instructor> Instructors { get; private set; }
}

{
}

{
{
}

}

{
}
public class Instructor

{
public Instructor()
{
this.Courses = new List<Course>();
}
// Primary key
public int InstructorID { get; set; }
public System.DateTime HireDate { get; set; }
}
public class OfficeAssignment

{
// Specifying InstructorID as a primary
[Key()]
public Int32 InstructorID { get; set; }
// When Entity Framework sees Timestamp attribute

// it configures ConcurrencyCheck and DatabaseGeneratedPattern=Computed.
[Timestamp]
public Byte[] Timestamp { get; set; }
public virtual Instructor Instructor { get; set; }
}
API fluida: configuración y asignación de
propiedades y tipos
Al trabajar con Entity Framework Code First el comportamiento predeterminado es asignar las clases POCO a las
tablas mediante un conjunto de convenciones incorporadas en EF. Sin embargo, a veces no puede o no desea
seguir estas convenciones y debe asignar entidades a un valor distinto del que dictan las convenciones.
Hay dos formas principales de configurar EF para que use un elemento que no sea convenciones, como
anotaciones o API fluida de EFS. Las anotaciones solo cubren un subconjunto de la funcionalidad de la API fluida,
por lo que hay escenarios de asignación que no se pueden lograr mediante anotaciones. Este artículo está
diseñado para demostrar cómo usar la API fluida para configurar las propiedades.
Normalmente, se tiene acceso a la API fluida de Code First mediante la invalidación del método OnModelCreating
en DbContextderivado. Los ejemplos siguientes están diseñados para mostrar cómo realizar varias tareas con la
API fluida y permiten copiar el código y personalizarlo para que se adapte a su modelo; si desea ver el modelo con
el que se pueden usar tal cual, se proporciona al final de este artículo.
Configuración para todo el modelo

Esquema predeterminado (EF6 en adelante )
A partir de EF6, puede usar el método HasDefaultSchema en DbModelBuilder para especificar el esquema de base
de datos que se va a usar para todas las tablas, procedimientos almacenados, etc. Esta configuración
predeterminada se invalidará para todos los objetos para los que se configure explícitamente un esquema
diferente.
modelBuilder.HasDefaultSchema("sales");
Convenciones personalizadas (EF6 en adelante )

A partir de EF6, puede crear sus propias convenciones para complementar las incluidas en Code First. Para
obtener más información, vea convenciones de Code First personalizadas.
Asignación de propiedades
El método Property se utiliza para configurar los atributos de cada propiedad que pertenece a una entidad o un
tipo complejo. El método de propiedad se utiliza para obtener un objeto de configuración para una propiedad
determinada. Las opciones del objeto de configuración son específicas del tipo que se está configurando;
IsUnicode solo está disponible en las propiedades de cadena, por ejemplo.
Configuración de una clave principal
La Convención de Entity Framework para las claves principales es:
1. La clase define una propiedad cuyo nombre es "ID" o "ID"
2. o un nombre de clase seguido de "ID" o "ID"
Para establecer explícitamente una propiedad como clave principal, puede usar el método Haskey (. En el ejemplo
siguiente, se usa el método Haskey (para configurar la clave principal InstructorID en el tipo OfficeAssignment.
modelBuilder.Entity<OfficeAssignment>().HasKey(t => t.InstructorID);
Configuración de una clave principal compuesta

En el ejemplo siguiente se configuran las propiedades DepartmentID y Name para que sean la clave principal
compuesta del tipo Department.
modelBuilder.Entity<Department>().HasKey(t => new { t.DepartmentID, t.Name });
Desactivar la identidad de las claves principales numéricas

En el ejemplo siguiente se establece la propiedad DepartmentID en System. ComponentModel. DataAnnotations.
DatabaseGeneratedOption. None para indicar que la base de datos no generará el valor.
modelBuilder.Entity<Department>().Property(t => t.DepartmentID)

.HasDatabaseGeneratedOption(DatabaseGeneratedOption.None);
Especificar la longitud máxima de una propiedad

En el ejemplo siguiente, la propiedad Name no debe tener más de 50 caracteres. Si hace que el valor supere los 50
caracteres, recibirá una excepción DbEntityValidationException . Si Code First crea una base de datos a partir de
este modelo, también establecerá la longitud máxima de la columna de nombre en 50 caracteres.
modelBuilder.Entity<Department>().Property(t => t.Name).HasMaxLength(50);
Configuración de la propiedad para que sea necesaria

En el ejemplo siguiente, se requiere la propiedad Name. Si no especifica el nombre, obtendrá una excepción
DbEntityValidationException. Si Code First crea una base de datos a partir de este modelo, la columna utilizada
para almacenar esta propiedad no suele ser que acepte valores NULL.
NOTE
En algunos casos, es posible que no sea posible que la columna de la base de datos no acepte valores NULL, aunque se
requiera la propiedad. Por ejemplo, cuando se usa un dato de estrategia de herencia de TPH para varios tipos, se almacena
en una sola tabla. Si un tipo derivado incluye una propiedad necesaria, no se puede hacer que la columna no acepte valores
NULL, ya que no todos los tipos de la jerarquía tendrán esta propiedad.
modelBuilder.Entity<Department>().Property(t => t.Name).IsRequired();
Configuración de un índice en una o más propiedades
NOTE
EF 6.1 en adelante solo : el atributo de índice se presentó en Entity Framework 6,1. Si usa una versión anterior, no se
aplica la información de esta sección.
La creación de índices no es compatible de forma nativa con la API fluida, pero puede usar la compatibilidad con
IndexAttribute a través de la API fluida. Los atributos de índice se procesan mediante la inclusión de una
anotación de modelo en el modelo que luego se convierte en un índice de la base de datos más adelante en la
canalización. Puede Agregar manualmente estas mismas anotaciones mediante la API fluida.
La forma más fácil de hacerlo es crear una instancia de IndexAttribute que contenga todos los valores para el
nuevo índice. Después, puede crear una instancia de IndexAnnotation , que es un tipo específico de EF que
convertirá la configuración de IndexAttribute en una anotación de modelo que se puede almacenar en el
modelo de EF. A continuación, se pueden pasar al método HasColumnAnnotation en la API fluida, especificando
el Índice de nombre de la anotación.
modelBuilder
.Entity<Department>()
.Property(t => t.Name)
.HasColumnAnnotation("Index", new IndexAnnotation(new IndexAttribute()));
Para obtener una lista completa de los valores disponibles en IndexAttribute , consulte la sección Índice de code
First anotaciones de datos. Esto incluye la personalización del nombre del índice, la creación de índices únicos y la
creación de índices de varias columnas.
Puede especificar varias anotaciones de índice en una sola propiedad pasando una matriz de IndexAttribute al
constructor de IndexAnnotation .
modelBuilder
.Entity<Department>()
.HasColumnAnnotation(
"Index",
new IndexAnnotation(new[]
{
new IndexAttribute("Index1"),
new IndexAttribute("Index2") { IsUnique = true }
})));
Especificar no asignar una propiedad CLR a una columna en la base de datos

En el ejemplo siguiente se muestra cómo especificar que una propiedad de un tipo CLR no está asignada a una
columna de la base de datos.
modelBuilder.Entity<Department>().Ignore(t => t.Budget);
Asignar una propiedad CLR a una columna específica en la base de datos

En el ejemplo siguiente se asigna el nombre de la propiedad CLR a la columna de base de datos
DepartmentName.
.HasColumnName("DepartmentName");
Cambiar el nombre de una clave externa que no está definida en el modelo

Si decide no definir una clave externa en un tipo CLR, pero desea especificar el nombre que debe tener en la base
de datos, haga lo siguiente:
.Map(m => m.MapKey("ChangedDepartmentID"));
Configurar si una propiedad de cadena admite contenido Unicode

De forma predeterminada, las cadenas son Unicode (nvarchar en SQL Server). Puede usar el método IsUnicode
para especificar que una cadena debe ser de tipo VARCHAR.
.IsUnicode(false);
Configurar el tipo de datos de una columna de base de datos

El método HasColumnType permite la asignación a distintas representaciones del mismo tipo básico. El uso de
este método no permite realizar ninguna conversión de los datos en tiempo de ejecución. Tenga en cuenta que
IsUnicode es la forma preferida de establecer columnas en VARCHAR, ya que es independiente de la base de
datos.
.Property(p => p.Name)
.HasColumnType("varchar");
Configurar propiedades en un tipo complejo

Hay dos maneras de configurar las propiedades escalares en un tipo complejo.
Puede llamar a la propiedad en ComplexTypeConfiguration.
modelBuilder.ComplexType<Details>()
.Property(t => t.Location)
.HasMaxLength(20);
También puede usar la notación de puntos para tener acceso a una propiedad de un tipo complejo.
modelBuilder.Entity<OnsiteCourse>()
.Property(t => t.Details.Location)
.HasMaxLength(20);
Configuración de una propiedad que se va a usar como un token de simultaneidad optimista

Para especificar que una propiedad de una entidad representa un token de simultaneidad, puede usar el atributo
ConcurrencyCheck o el método IsConcurrencyToken.
.Property(t => t.Timestamp)
.IsConcurrencyToken();
También puede usar el método IsRowVersion para configurar la propiedad de modo que sea una versión de fila en
la base de datos. Al establecer la propiedad como una versión de fila, se configura automáticamente para que sea
un token de simultaneidad optimista.
.Property(t => t.Timestamp)
.IsRowVersion();
Asignación de tipos
Especificar que una clase es un tipo complejo
Por Convención, un tipo que no tiene ninguna clave principal especificada se trata como un tipo complejo. Hay
algunos escenarios en los que Code First no detectarán un tipo complejo (por ejemplo, si tiene una propiedad
denominada ID, pero no significa que sea una clave principal). En tales casos, usaría la API fluida para especificar
explícitamente que un tipo es un tipo complejo.
modelBuilder.ComplexType<Details>();
Especificar no asignar un tipo de entidad CLR a una tabla de la base de datos

En el ejemplo siguiente se muestra cómo excluir un tipo CLR para que no se asigne a una tabla de la base de
datos.
modelBuilder.Ignore<OnlineCourse>();
Asignar un tipo de entidad a una tabla específica de la base de datos

Todas las propiedades de Department se asignarán a las columnas de una tabla denominada t_ Department.
.ToTable("t_Department");
También puede especificar el nombre del esquema de la siguiente manera:
.ToTable("t_Department", "school");
Asignar la herencia de tabla por jerarquía (TPH )

En el escenario de asignación TPH, todos los tipos de una jerarquía de herencia se asignan a una sola tabla. Una
columna de discriminador se utiliza para identificar el tipo de cada fila. Al crear el modelo con Code First, TPH es la
estrategia predeterminada para los tipos que participan en la jerarquía de herencia. De forma predeterminada, la
columna discriminadora se agrega a la tabla con el nombre "Discriminator" y el nombre de tipo de CLR de cada
tipo de la jerarquía se usa para los valores de discriminador. Puede modificar el comportamiento predeterminado
mediante la API fluida.
.Map<Course>(m => m.Requires("Type").HasValue("Course"))
.Map<OnsiteCourse>(m => m.Requires("Type").HasValue("OnsiteCourse"));
Asignación de la herencia de tabla por tipo (TPT )

En el escenario de asignación de TPT, todos los tipos se asignan a tablas individuales. Las propiedades que
pertenecen solamente a un tipo base o a un tipo derivado se almacenan en una tabla que se asigna a ese tipo. Las
tablas que se asignan a tipos derivados también almacenan una clave externa que une la tabla derivada con la
tabla base.
modelBuilder.Entity<Course>().ToTable("Course");
modelBuilder.Entity<OnsiteCourse>().ToTable("OnsiteCourse");
Asignación de la herencia de la tabla por clase concreta (TPC )

En el escenario de asignación de TPC, todos los tipos no abstractos de la jerarquía se asignan a tablas individuales.
Las tablas que se asignan a las clases derivadas no tienen ninguna relación con la tabla que se asigna a la clase
base en la base de datos. Todas las propiedades de una clase, incluidas las propiedades heredadas, se asignan a las
columnas de la tabla correspondiente.
Llame al método MapInheritedProperties para configurar cada tipo derivado. MapInheritedProperties reasigna
todas las propiedades heredadas de la clase base a nuevas columnas de la tabla para la clase derivada.
NOTE
Tenga en cuenta que, dado que las tablas que participan en la jerarquía de herencia de TPC no comparten una clave
principal, habrá claves de entidad duplicadas al insertar en las tablas que se asignan a las subclases si tiene valores
generados por la base de datos con el mismo valor de inicialización de identidad. Para solucionar este problema, puede
especificar un valor de inicialización inicial diferente para cada tabla o desactivar la identidad en la propiedad de clave
principal. Identity es el valor predeterminado para las propiedades de clave de entero cuando se trabaja con Code First.
.Property(c => c.CourseID)
.HasDatabaseGeneratedOption(DatabaseGeneratedOption.None);
modelBuilder.Entity<OnsiteCourse>().Map(m =>
{
m.MapInheritedProperties();
m.ToTable("OnsiteCourse");
});
modelBuilder.Entity<OnlineCourse>().Map(m =>
{
m.MapInheritedProperties();
m.ToTable("OnlineCourse");
});
Asignar propiedades de un tipo de entidad a varias tablas en la base de datos (División de entidades)
La división de entidades permite que las propiedades de un tipo de entidad se repartan entre varias tablas. En el
ejemplo siguiente, la entidad Department se divide en dos tablas: Department y DepartmentDetails. La división de
entidades utiliza varias llamadas al método Map para asignar un subconjunto de propiedades a una tabla
específica.
.Map(m =>
{
m.Properties(t => new { t.DepartmentID, t.Name });
m.ToTable("Department");
})
.Map(m =>
{
m.Properties(t => new { t.DepartmentID, t.Administrator, t.StartDate, t.Budget });
m.ToTable("DepartmentDetails");
});
Asignar varios tipos de entidad a una tabla de la base de datos (División de tablas)
En el ejemplo siguiente se asignan dos tipos de entidad que comparten una clave principal a una tabla.
.WithRequiredPrincipal(t => t.Instructor);
modelBuilder.Entity<Instructor>().ToTable("Instructor");
modelBuilder.Entity<OfficeAssignment>().ToTable("Instructor");
Asignar un tipo de entidad para insertar/actualizar/eliminar procedimientos almacenados (EF6 en adelante )

A partir de EF6, puede asignar una entidad para usar procedimientos almacenados para INSERT UPDATE y
DELETE. Para obtener más información, vea code First INSERT/UPDATE/DELETE Stored Procedures.
Modelo usado en los ejemplos

El siguiente modelo de Code First se usa para los ejemplos de esta página.
// add a reference to System.ComponentModel.DataAnnotations DLL
using System;

{
public DbSet<Course> Courses { get; set; }
public DbSet<Instructor> Instructors { get; set; }
public DbSet<OfficeAssignment> OfficeAssignments { get; set; }

{
// If you keep this convention then the generated tables will have pluralized names.
}
}

{
public Department()
{
}
// Primary key
public System.DateTime StartDate { get; set; }
public int? Administrator { get; set; }
}
public class Course

{
public Course()
{
this.Instructors = new HashSet<Instructor>();
}
// Primary key

// Foreign key
public virtual ICollection<Instructor> Instructors { get; private set; }
}

{
}

{
{
}

}

{
}
public class Instructor

{
public Instructor()
{
this.Courses = new List<Course>();
}
// Primary key
public int InstructorID { get; set; }
public System.DateTime HireDate { get; set; }
}
public class OfficeAssignment

{
// Specifying InstructorID as a primary
[Key()]
public Int32 InstructorID { get; set; }
// When Entity Framework sees Timestamp attribute

// it configures ConcurrencyCheck and DatabaseGeneratedPattern=Computed.
[Timestamp]
public Byte[] Timestamp { get; set; }
public virtual Instructor Instructor { get; set; }
}
}
API fluida con VB.NET
Code First permite definir el modelo mediante clases de C# o VB.NET. Opcionalmente, se puede realizar una
configuración adicional mediante atributos en las clases y propiedades o mediante una API fluida. En este tutorial
se muestra cómo realizar una configuración de API fluida mediante VB.NET.
En esta página se supone que tiene un conocimiento básico de Code First. Consulte los siguientes tutoriales para
obtener más información sobre Code First:
Code First en una nueva base de datos
Code First a una base de datos existente
Requisitos previos
Para simplificar las cosas, vamos a crear una aplicación de consola básica que use Code First para realizar el
acceso a los datos.
Abra Visual Studio.
Escriba CodeFirstVBSample como nombre
Definir el modelo
En este paso definirá tipos de entidad de VB.NET POCO que representan el modelo conceptual. No es necesario
que las clases se deriven de ninguna clase base ni se implementen interfaces.
Agregue una nueva clase al proyecto, escriba SchoolModel como nombre de clase.
Reemplace el contenido de la nueva clase por el código siguiente.
Public Class Department

Public Sub New()
Me.Courses = New List(Of Course)()
End Sub
' Primary key

Public Property DepartmentID() As Integer
Public Property Name() As String
Public Property Budget() As Decimal
Public Property StartDate() As Date
Public Property Administrator() As Integer?
Public Overridable Property Courses() As ICollection(Of Course)
End Class
Public Class Course

Public Sub New()
Me.Instructors = New HashSet(Of Instructor)()
Me.Instructors = New HashSet(Of Instructor)()
End Sub
' Primary key

Public Property CourseID() As Integer
Public Property Title() As String
Public Property Credits() As Integer
' Foreign key that does not follow the Code First convention.
' The fluent API will be used to configure DepartmentID_FK to be the foreign key for this entity.
Public Property DepartmentID_FK() As Integer
' Navigation properties

Public Overridable Property Department() As Department
Public Overridable Property Instructors() As ICollection(Of Instructor)
End Class
Public Class OnlineCourse

Inherits Course
Public Property URL() As String

End Class
Partial Public Class OnsiteCourse

Inherits Course
Public Sub New()

Details = New OnsiteCourseDetails()
End Sub
Public Property Details() As OnsiteCourseDetails

End Class
' Complex type

Public Class OnsiteCourseDetails
Public Property Time() As Date
Public Property Location() As String
Public Property Days() As String
End Class
Public Class Person

' Primary key
Public Property PersonID() As Integer
Public Property LastName() As String
Public Property FirstName() As String
End Class
Public Class Instructor

Inherits Person
Public Sub New()

Me.Courses = New List(Of Course)()
End Sub
Public Property HireDate() As Date
' Navigation properties

Private privateCourses As ICollection(Of Course)
Public Overridable Property Courses() As ICollection(Of Course)
Public Overridable Property OfficeAssignment() As OfficeAssignment
End Class
Public Class OfficeAssignment

' Primary key that does not follow the Code First convention.
' The HasKey method is used later to configure the primary key for the entity.
Public Property InstructorID() As Integer
Public Property Location() As String

Public Property Timestamp() As Byte()
' Navigation property
Public Overridable Property Instructor() As Instructor
End Class
Definir un contexto derivado

Estamos a punto de empezar a usar tipos del Entity Framework por lo que necesitamos agregar el paquete NuGet
EntityFramework.
* * Proyecto:> administrar paquetes NuGet...
NOTE
Si no tiene la Administración de paquetes de NuGet.. . opción debe instalar la versión más reciente de NuGet

Ahora es el momento de definir un contexto derivado, que representa una sesión con la base de datos, lo que nos
permite consultar y guardar datos. Definimos un contexto que se deriva de System. Data. Entity. DbContext y
expone un DbSet con tipo de> de la<de la carpa para cada clase de nuestro modelo.
Agregue una nueva clase al proyecto, escriba SchoolContext para el nombre de clase.
Reemplace el contenido de la nueva clase por el código siguiente.
Imports System.ComponentModel.DataAnnotations
Imports System.ComponentModel.DataAnnotations.Schema
Imports System.Data.Entity
Imports System.Data.Entity.Infrastructure
Imports System.Data.Entity.ModelConfiguration.Conventions
Public Class SchoolContext

Inherits DbContext
Public Property OfficeAssignments() As DbSet(Of OfficeAssignment)

Public Property Instructors() As DbSet(Of Instructor)
Public Property Courses() As DbSet(Of Course)
Public Property Departments() As DbSet(Of Department)
Protected Overrides Sub OnModelCreating(ByVal modelBuilder As DbModelBuilder)

End Sub
End Class
Configuración con la API fluida

En esta sección se muestra cómo usar las API fluidas para configurar los tipos para la asignación de tablas, las
propiedades para la asignación de columnas y las relaciones entre las tablas\tipo en el modelo. La API fluida se
expone a través del tipo DbModelBuilder y se suele acceder a ella mediante la invalidación del método
OnModelCreating en DbContext .
Copie el código siguiente y agréguelo al método OnModelCreating definido en la clase SchoolContext . los
comentarios explican lo que hace cada asignación
' Configure Code First to ignore PluralizingTableName convention

' If you keep this convention then the generated tables
' will have pluralized names.
modelBuilder.Conventions.Remove(Of PluralizingTableNameConvention)()
' Specifying that a Class is a Complex Type
' The model defined in this topic defines a type OnsiteCourseDetails.

' By convention, a type that has no primary key specified
' is treated as a complex type.
' There are some scenarios where Code First will not
' detect a complex type (for example, if you do have a property
' called ID, but you do not mean for it to be a primary key).
' In such cases, you would use the fluent API to
' explicitly specify that a type is a complex type.
modelBuilder.ComplexType(Of OnsiteCourseDetails)()
' Mapping a CLR Entity Type to a Specific Table in the Database.
' All properties of OfficeAssignment will be mapped

' to columns in a table called t_OfficeAssignment.
modelBuilder.Entity(Of OfficeAssignment)().ToTable("t_OfficeAssignment")
' Mapping the Table-Per-Hierarchy (TPH) Inheritance
' In the TPH mapping scenario, all types in an inheritance hierarchy

' are mapped to a single table.
' A discriminator column is used to identify the type of each row.
' When creating your model with Code First,
' TPH is the default strategy for the types that
' participate in the inheritance hierarchy.
' By default, the discriminator column is added
' to the table with the name “Discriminator”
' and the CLR type name of each type in the hierarchy
' is used for the discriminator values.
' You can modify the default behavior by using the fluent API.
modelBuilder.Entity(Of Person)().
Map(Of Person)(Function(t) t.Requires("Type").
HasValue("Person")).
Map(Of Instructor)(Function(t) t.Requires("Type").
HasValue("Instructor"))
' Mapping the Table-Per-Type (TPT) Inheritance
' In the TPT mapping scenario, all types are mapped to individual tables.
' Properties that belong solely to a base type or derived type are stored
' in a table that maps to that type. Tables that map to derived types
' also store a foreign key that joins the derived table with the base table.
modelBuilder.Entity(Of Course)().ToTable("Course")
modelBuilder.Entity(Of OnsiteCourse)().ToTable("OnsiteCourse")
modelBuilder.Entity(Of OnlineCourse)().ToTable("OnlineCourse")
' Configuring a Primary Key
' If your class defines a property whose name is “ID” or “Id”,

' or a class name followed by “ID” or “Id”,
' the Entity Framework treats this property as a primary key by convention.
' If your property name does not follow this pattern, use the HasKey method
' to configure the primary key for the entity.
modelBuilder.Entity(Of OfficeAssignment)().
HasKey(Function(t) t.InstructorID)
' Specifying the Maximum Length on a Property
' In the following example, the Name property

' In the following example, the Name property
' should be no longer than 50 characters.
' If you make the value longer than 50 characters,
' you will get a DbEntityValidationException exception.
modelBuilder.Entity(Of Department)().Property(Function(t) t.Name).
HasMaxLength(60)
' Configuring the Property to be Required
' In the following example, the Name property is required.

' If you do not specify the Name,
' you will get a DbEntityValidationException exception.
' The database column used to store this property will be non-nullable.
IsRequired()
' Switching off Identity for Numeric Primary Keys
' The following example sets the DepartmentID property to

' System.ComponentModel.DataAnnotations.DatabaseGeneratedOption.None to indicate that
' the value will not be generated by the database.
modelBuilder.Entity(Of Course)().Property(Function(t) t.CourseID).
HasDatabaseGeneratedOption(DatabaseGeneratedOption.None)
'Specifying NOT to Map a CLR Property to a Column in the Database

modelBuilder.Entity(Of Department)().
Ignore(Function(t) t.Administrator)
'Mapping a CLR Property to a Specific Column in the Database

modelBuilder.Entity(Of Department)().Property(Function(t) t.Budget).
HasColumnName("DepartmentBudget")
'Configuring the Data Type of a Database Column

HasColumnType("varchar")
'Configuring Properties on a Complex Type

modelBuilder.Entity(Of OnsiteCourse)().Property(Function(t) t.Details.Days).
HasColumnName("Days")
modelBuilder.Entity(Of OnsiteCourse)().Property(Function(t) t.Details.Location).
HasColumnName("Location")
modelBuilder.Entity(Of OnsiteCourse)().Property(Function(t) t.Details.Time).
HasColumnName("Time")
' Map one-to-zero or one relationship
' The OfficeAssignment has the InstructorID

' property that is a primary key and a foreign key.
modelBuilder.Entity(Of OfficeAssignment)().
HasRequired(Function(t) t.Instructor).
WithOptional(Function(t) t.OfficeAssignment)
' Configuring a Many-to-Many Relationship
' The following code configures a many-to-many relationship

' between the Course and Instructor types.
' In the following example, the default Code First conventions
' are used to create a join table.
' As a result the CourseInstructor table is created with
' Course_CourseID and Instructor_InstructorID columns.
modelBuilder.Entity(Of Course)().
HasMany(Function(t) t.Instructors).
WithMany(Function(t) t.Courses)
' Configuring a Many-to-Many Relationship and specifying the names

' Configuring a Many-to-Many Relationship and specifying the names
' of the columns in the join table
' If you want to specify the join table name

' and the names of the columns in the table
' you need to do additional configuration by using the Map method.
' The following code generates the CourseInstructor
' table with CourseID and InstructorID columns.
HasMany(Function(t) t.Instructors).
WithMany(Function(t) t.Courses).
Map(Sub(m)
m.ToTable("CourseInstructor")
m.MapLeftKey("CourseID")
m.MapRightKey("InstructorID")
End Sub)
' Configuring a foreign key name that does not follow the Code First convention
' The foreign key property on the Course class is called DepartmentID_FK
' since that does not follow Code First conventions you need to explicitly specify
' that you want DepartmentID_FK to be the foreign key.
HasRequired(Function(t) t.Department).
HasForeignKey(Function(t) t.DepartmentID_FK)
' Enabling Cascade Delete
' By default, if a foreign key on the dependent entity is not nullable,

' then Code First sets cascade delete on the relationship.
' If a foreign key on the dependent entity is nullable,
' Code First does not set cascade delete on the relationship,
' and when the principal is deleted the foreign key will be set to null.
' The following code configures cascade delete on the relationship.
' You can also remove the cascade delete conventions by using:
' modelBuilder.Conventions.Remove<OneToManyCascadeDeleteConvention>()
' and modelBuilder.Conventions.Remove<ManyToManyCascadeDeleteConvention>().
HasRequired(Function(t) t.Department).
HasForeignKey(Function(d) d.DepartmentID_FK).
WillCascadeOnDelete(False)
Uso del modelo

Vamos a realizar algunos accesos a datos con SchoolContext para ver el modelo en acción.
Abra el archivo Module1. VB en el que se define la función main.
Copie y pegue la siguiente definición de Module1
Imports System.Data.Entity
Module Module1
Sub Main()
Using context As New SchoolContext()
' Create and save a new Department.

Console.Write("Enter a name for a new Department: ")
Dim name = Console.ReadLine()
Dim department = New Department With { .Name = name, .StartDate = DateTime.Now }

context.Departments.Add(department)
context.SaveChanges()
' Display all Departments from the database ordered by name

Dim departments =
From d In context.Departments
Order By d.Name
Select d
Console.WriteLine("All Departments in the database:")

For Each department In departments
Console.WriteLine(department.Name)
Next
End Using
Console.WriteLine("Press any key to exit...")

Console.ReadKey()
End Sub
End Module
Enter a name for a new Department: Computing

All Departments in the database:
Computing
Code First procedimientos almacenados de inserción,
actualización y eliminación
NOTE
De forma predeterminada, Code First configurará todas las entidades para que realicen los comandos de
inserción, actualización y eliminación mediante el acceso directo a tablas. A partir de EF6, puede configurar el
modelo de Code First para que use procedimientos almacenados para algunas o todas las entidades del modelo.
Asignación de entidad básica

Puede optar por usar procedimientos almacenados para INSERT, Update y DELETE mediante la API fluida.
modelBuilder
.Entity<Blog>()
.MapToStoredProcedures();
Esto hará que Code First utilice algunas convenciones para generar la forma esperada de los procedimientos
almacenados en la base de datos.
Tres procedimientos almacenados denominados <type_name>_Inser t , < type_name>_Update y <
type_name>_Delete (por ejemplo, Blog_Insert, Blog_Update y Blog_Delete).
Los nombres de parámetro se corresponden con los nombres de propiedad.
NOTE
Si usa HasColumnName () o el atributo de columna para cambiar el nombre de la columna de una propiedad
determinada, este nombre se utiliza para los parámetros en lugar del nombre de la propiedad.
El procedimiento almacenado Inser t tendrá un parámetro para cada propiedad, a excepción de los
marcados como almacenamiento generado (identidad o calculado). El procedimiento almacenado debe
devolver un conjunto de resultados con una columna para cada propiedad generada por el almacén.
El procedimiento almacenado de actualización tendrá un parámetro para cada propiedad, excepto
aquellos marcados con un modelo generado por un almacén de ' Calculated '. Algunos tokens de
simultaneidad requieren un parámetro para el valor original; vea la sección tokens de simultaneidad a
continuación para obtener más información. El procedimiento almacenado debe devolver un conjunto de
resultados con una columna para cada propiedad calculada.
El procedimiento almacenado Delete debe tener un parámetro para el valor de clave de la entidad (o
varios parámetros si la entidad tiene una clave compuesta). Además, el procedimiento de eliminación también
debe tener parámetros para cualquier clave externa de asociación independiente en la tabla de destino
(relaciones que no tienen las propiedades de clave externa correspondientes declaradas en la entidad). Algunos
tokens de simultaneidad requieren un parámetro para el valor original; vea la sección tokens de simultaneidad
a continuación para obtener más información.
Use la siguiente clase como ejemplo:
public class Blog

{
}
Los procedimientos almacenados predeterminados serían:
CREATE PROCEDURE [dbo].[Blog_Insert]

@Name nvarchar(max),
@Url nvarchar(max)
AS
BEGIN
INSERT INTO [dbo].[Blogs] ([Name], [Url])
VALUES (@Name, @Url)
SELECT SCOPE_IDENTITY() AS BlogId

END
CREATE PROCEDURE [dbo].[Blog_Update]
@BlogId int,
@Url nvarchar(max)
AS
UPDATE [dbo].[Blogs]
SET [Name] = @Name, [Url] = @Url
WHERE BlogId = @BlogId;
CREATE PROCEDURE [dbo].[Blog_Delete]
@BlogId int
AS
DELETE FROM [dbo].[Blogs]
WHERE BlogId = @BlogId
Reemplazar los valores predeterminados

Puede invalidar parte o todo lo que se configuró de forma predeterminada.
Puede cambiar el nombre de uno o más procedimientos almacenados. En este ejemplo se cambia el nombre del
procedimiento almacenado de actualización únicamente.
modelBuilder
.Entity<Blog>()
.MapToStoredProcedures(s =>
s.Update(u => u.HasName("modify_blog")));
En este ejemplo se cambia el nombre de los tres procedimientos almacenados.
modelBuilder
.Entity<Blog>()
s.Update(u => u.HasName("modify_blog"))
.Delete(d => d.HasName("delete_blog"))
.Insert(i => i.HasName("insert_blog")));
En estos ejemplos, las llamadas se encadenan entre sí, pero también puede usar la sintaxis de bloque lambda.
modelBuilder
.Entity<Blog>()
{
s.Update(u => u.HasName("modify_blog"));
s.Delete(d => d.HasName("delete_blog"));
s.Insert(i => i.HasName("insert_blog"));
});
En este ejemplo se cambia el nombre del parámetro de la propiedad BlogId en el procedimiento almacenado de
actualización.
modelBuilder
.Entity<Blog>()
s.Update(u => u.Parameter(b => b.BlogId, "blog_id")));
Estas llamadas son todas encadenables y que admiten composición. Este es un ejemplo en el que se cambia el
nombre de los tres procedimientos almacenados y sus parámetros.
modelBuilder
.Entity<Blog>()
s.Update(u => u.HasName("modify_blog")
.Parameter(b => b.BlogId, "blog_id")
.Parameter(b => b.Name, "blog_name")
.Parameter(b => b.Url, "blog_url"))
.Delete(d => d.HasName("delete_blog")
.Parameter(b => b.BlogId, "blog_id"))
.Insert(i => i.HasName("insert_blog")
.Parameter(b => b.Name, "blog_name")
.Parameter(b => b.Url, "blog_url")));
También puede cambiar el nombre de las columnas del conjunto de resultados que contiene los valores generados
por la base de datos.
modelBuilder
.Entity<Blog>()
s.Insert(i => i.Result(b => b.BlogId, "generated_blog_identity")));
CREATE PROCEDURE [dbo].[Blog_Insert]

@Url nvarchar(max)
AS
BEGIN
INSERT INTO [dbo].[Blogs] ([Name], [Url])
VALUES (@Name, @Url)
SELECT SCOPE_IDENTITY() AS generated_blog_id

END
Relaciones sin una clave externa en la clase (asociaciones

independientes)
Cuando se incluye una propiedad de clave externa en la definición de clase, se puede cambiar el nombre del
parámetro correspondiente de la misma manera que cualquier otra propiedad. Cuando existe una relación sin una
propiedad de clave externa en la clase, el nombre del parámetro predeterminado es
<navigation_proper ty_name>_<primar y_key_name >.
Por ejemplo, las siguientes definiciones de clase darían lugar a la espera de un parámetro Blog_BlogId en los
procedimientos almacenados para insertar y actualizar las entradas.
public class Blog

{

}
public class Post

{

}

Puede cambiar los parámetros de las claves externas que no están incluidas en la clase proporcionando la ruta de
acceso a la propiedad de clave principal al método de parámetro.
modelBuilder
.Entity<Post>()
s.Insert(i => i.Parameter(p => p.Blog.BlogId, "blog_id")));
Si no tiene una propiedad de navegación en la entidad dependiente (es decir, no se puede usar el método
Association para identificar el otro extremo de la relación y, después, configurar los parámetros correspondientes
a cada una de las propiedades de clave.
modelBuilder
.Entity<Post>()
s.Insert(i => i.Navigation<Blog>(
b => b.Posts,
c => c.Parameter(b => b.BlogId, "blog_id"))));
Los procedimientos almacenados de actualización y eliminación también pueden necesitar tratar la simultaneidad:
Si la entidad contiene tokens de simultaneidad, el procedimiento almacenado puede tener opcionalmente un
parámetro de salida que devuelve el número de filas actualizadas o eliminadas (filas afectadas). Este tipo de
parámetro se debe configurar mediante el método RowsAffectedParameter.
De forma predeterminada, EF usa el valor devuelto por ExecuteNonQuery para determinar el número de filas
afectadas. La especificación de un parámetro de salida de filas afectado es útil si se realiza cualquier lógica en el
procedimiento almacenado, lo que daría lugar a que el valor devuelto de ExecuteNonQuery fuera incorrecto
(desde la perspectiva del EF) al final de la ejecución.
Para cada token de simultaneidad habrá un parámetro denominado <proper ty_name>_Original (por
ejemplo, Timestamp_Original). Se pasará el valor original de esta propiedad, que es el valor cuando se consulta
desde la base de datos.
Los tokens de simultaneidad calculados por la base de datos, como las marcas de tiempo, solo tendrán
un parámetro de valor original.
Las propiedades no calculadas que se establecen como tokens de simultaneidad también tendrán un
parámetro para el nuevo valor en el procedimiento de actualización. Utiliza las convenciones de
nomenclatura ya descritas para los nuevos valores. Un ejemplo de este tipo de token sería usar la
dirección URL de un blog como un token de simultaneidad, el nuevo valor es necesario porque puede
actualizarse a un nuevo valor por el código (a diferencia de un token de marca de tiempo que solo se
actualiza en la base de datos).
Esta es una clase de ejemplo y un procedimiento almacenado de actualización con un token de simultaneidad de
marca de tiempo.
public class Blog

{
[Timestamp]
public byte[] Timestamp { get; set; }
}

@BlogId int,
@Url nvarchar(max),
@Timestamp_Original rowversion
AS
WHERE BlogId = @BlogId AND [Timestamp] = @Timestamp_Original
A continuación se muestra una clase de ejemplo y un procedimiento almacenado de actualización con un token de
simultaneidad no calculado.
public class Blog

{
[ConcurrencyCheck]
}

@BlogId int,
@Url nvarchar(max),
@Url_Original nvarchar(max),
AS
WHERE BlogId = @BlogId AND [Url] = @Url_Original

Opcionalmente, puede introducir un parámetro de filas afectadas.
modelBuilder
.Entity<Blog>()
s.Update(u => u.RowsAffectedParameter("rows_affected")));
En el caso de tokens de simultaneidad calculados de base de datos, donde solo se pasa el valor original, solo
puede usar el mecanismo de cambio de nombre de parámetros estándar para cambiar el nombre del parámetro
para el valor original.
modelBuilder
.Entity<Blog>()
s.Update(u => u.Parameter(b => b.Timestamp, "blog_timestamp")));
En el caso de los tokens de simultaneidad no calculados, donde se pasan tanto el valor original como el nuevo,
puede utilizar una sobrecarga de parámetro que le permita proporcionar un nombre para cada parámetro.
modelBuilder
.Entity<Blog>()
.MapToStoredProcedures(s => s.Update(u => u.Parameter(b => b.Url, "blog_url", "blog_original_url")));
Relaciones de varios a varios

Usaremos las clases siguientes como ejemplo en esta sección.
public class Post

{
public List<Tag> Tags { get; set; }

}
public class Tag

{
public int TagId { get; set; }
public string TagName { get; set; }

}
Las relaciones de varios a varios se pueden asignar a procedimientos almacenados con la siguiente sintaxis.
modelBuilder
.Entity<Post>()
.HasMany(p => p.Tags)
.WithMany(t => t.Posts)
.MapToStoredProcedures();
Si no se proporciona ninguna otra configuración, se utiliza de forma predeterminada la siguiente forma de

procedimiento almacenado.
Dos procedimientos almacenados denominados <type_one><type_two>_Inser t y < type_one>
<type_two>_Delete (por ejemplo, PostTag_Insert y PostTag_Delete).
Los parámetros serán los valores de clave de cada tipo. Nombre de cada parámetro que se va
<type_name>_<proper ty_name >(por ejemplo, Post_PostId y Tag_TagId).
Estos son los procedimientos almacenados de inserción y actualización de ejemplo.
CREATE PROCEDURE [dbo].[PostTag_Insert]

@Post_PostId int,
@Tag_TagId int
AS
INSERT INTO [dbo].[Post_Tags] (Post_PostId, Tag_TagId)
VALUES (@Post_PostId, @Tag_TagId)
CREATE PROCEDURE [dbo].[PostTag_Delete]
@Post_PostId int,
@Tag_TagId int
AS
DELETE FROM [dbo].[Post_Tags]
WHERE Post_PostId = @Post_PostId AND Tag_TagId = @Tag_TagId

Los nombres de parámetros y procedimientos se pueden configurar de forma similar a los procedimientos
almacenados de entidad.
modelBuilder
.Entity<Post>()
.HasMany(p => p.Tags)
.WithMany(t => t.Posts)
s.Insert(i => i.HasName("add_post_tag")
.LeftKeyParameter(p => p.PostId, "post_id")
.RightKeyParameter(t => t.TagId, "tag_id"))
.Delete(d => d.HasName("remove_post_tag")
.LeftKeyParameter(p => p.PostId, "post_id")
.RightKeyParameter(t => t.TagId, "tag_id")));
Migraciones de Code First es la manera recomendada de desarrollar el esquema de base de datos de la

aplicación si usa el flujo de trabajo de Code First. Migraciones proporciona un conjunto de herramientas que
permiten:
1. Crear una base de datos inicial que funciona con el modelo de EF
2. Generar migraciones para realizar un seguimiento de los cambios realizados en el modelo de EF
3. Mantener actualizada la base de datos con esos cambios
En el tutorial siguiente se proporciona información general sobre Migraciones de Code First en Entity
Framework. Puede realizar el tutorial completo o ir al tema que le interesa. Se tratan los siguientes temas:
Creación de un modelo inicial y una base de datos

Antes de empezar a usar Migraciones, se necesitan un proyecto y un modelo de Code First con los que trabajar.
En este tutorial se va a usar el modelo canónico Blog y Post .
Cree una nueva aplicación de consola MigrationsDemo
Agregue la versión más reciente del paquete NuGet de EntityFramework al proyecto
Herramientas –> Administrador de paquetes de biblioteca–> Consola del Administrador
de paquetes
Ejecute el comando Install-Package EntityFramework
Agregue un archivo Model.cs con el código que se muestra a continuación. Este código define una sola clase
Blog que conforma el modelo de dominio y una clase BlogContext que es el contexto de EF Code First
namespace MigrationsDemo
{
{
}
public class Blog

{
}
}
Ahora que tenemos un modelo, es hora de usarlo para el acceso a los datos. Actualice el archivo Program.cs
con el código que se muestra a continuación.
using System;
using System.Linq;
using System.Text;
{
class Program
{
{
using (var db = new BlogContext())
{
db.Blogs.Add(new Blog { Name = "Another Blog " });
db.SaveChanges();
foreach (var blog in db.Blogs)

{
}
}

Console.ReadKey();
}
}
}
Ejecute la aplicación y verá que se ha creado automáticamente una base de datos

MigrationsCodeDemo.BlogContext .
Habilitación de migraciones
Es hora de realizar más cambios en el modelo.
Vamos a introducir una propiedad Url en la clase Blog.
Si volviera a ejecutar la aplicación de nuevo, aparecería una excepción InvalidOperationException con el texto El
modelo que respalda el contexto 'BlogContext' ha cambiado desde que se creó la base de datos. Considere la
posibilidad de usar Migraciones de Code First para actualizar la base de datos ( http://go.microsoft.com/fwlink/?
LinkId=238269 ).
Como sugiere la excepción, es hora de empezar a usar Migraciones de Code First. El primer paso es habilitar las
migraciones para el contexto.
Ejecute el comando Enable-Migrations en la consola del Administrador de paquetes
Este comando ha agregado una carpeta Migraciones al proyecto. Esta nueva carpeta contiene dos
archivos:
La clase Configuration. Esta clase permite configurar el comportamiento de Migraciones en el
contexto. En este tutorial se usa la configuración predeterminada. Puesto que hay un solo contexto de
Code First en el proyecto, Enable-Migrations ha rellenado automáticamente el tipo de contexto al que se
aplica esta configuración.
Una migración InitialCreate . Esta migración se ha generado porque Code First ya había creado
automáticamente una base de datos antes de que se habilitaran las migraciones. El código de esta
migración con scaffolding representa los objetos que ya se han creado en la base de datos. En nuestro
caso, es la tabla Blog con las columnas BlogId y Name . El nombre de archivo incluye una marca de
tiempo para ayudar con el orden. Si la base de datos aún no se hubiera creado, esta migración
InitialCreate no se hubiera agregado al proyecto. Por el contrario, la primera vez que se llamara a Add-
Migration, al código para crear estas tablas se le aplicaría scaffolding para una nueva migración.
Varios modelos con la misma base de datos como destino
Al usar versiones anteriores a EF6, solo se puede usar un modelo de Code First para generar o administrar el
esquema de una base de datos. Este es el resultado de una sola tabla __MigrationsHistor y por base de datos
sin forma de identificar qué entradas pertenecen a qué modelo.
A partir de EF6, la clase Configuration incluye una propiedad ContextKey . Esta actúa como identificador único
para cada modelo de Code First. Una columna correspondiente de la tabla __MigrationsHistor y permite que
entradas de varios modelos compartan la tabla. De forma predeterminada, esta propiedad se establece en el
nombre completo del contexto.
Generación y ejecución de migraciones

Migraciones de Code First tiene dos comandos principales con los que se va a familiarizar.
Add-Migration aplica la técnica scaffolding a la siguiente migración en función de los cambios realizados en
el modelo desde la creación de la última migración
Update-Database aplica las migraciones pendientes a la base de datos
Es necesario aplicar scaffolding a una migración para encargarse de la nueva propiedad Url que se ha agregado.
El comando Add-Migration permite poner un nombre a estas migraciones; a la nuestra la llamaremos
AddBlogUrl .
Ejecute el comando Add-Migration AddBlogUrl en la consola del Administrador de paquetes
En la carpeta Migraciones ahora tenemos una nueva migración AddBlogUrl . El nombre de archivo de la
migración lleva una marca de tiempo para ayudar con el orden
namespace MigrationsDemo.Migrations
{
using System;
public partial class AddBlogUrl : DbMigration

{
{
AddColumn("dbo.Blogs", "Url", c => c.String());
}

{
DropColumn("dbo.Blogs", "Url");
}
}
}
Ahora se podría editar esta migración o agregarle elementos, pero todo tiene bastante buen aspecto. Vamos a
usar Update-Database para aplicar esta migración a la base de datos.
Ejecute el comando Update-Database en la consola del Administrador de paquetes
Migraciones de Code First compara las migraciones de la carpeta Migraciones con las que se han aplicado a
la base de datos. Verá que es necesario aplicar la migración AddBlogUrl y ejecutarla.
La base de datos MigrationsDemo.BlogContext se ha actualizado para incluir la columna Url en la tabla
Blogs .
Personalización de migraciones
Hasta ahora hemos generado y ejecutado una migración sin realizar ningún cambio. Ahora vamos a editar el
código que se genera de forma predeterminada.
Es hora de realizar algunos cambios más en el modelo: vamos a agregar una nueva propiedad Rating a la
clase Blog
También vamos a agregar una nueva clase Post
public class Post

{
[MaxLength(200)]

}
Además agregaremos una colección Posts a la clase Blog para formar el otro extremo de la relación entre
Blog y Post

Vamos a usar el comando Add-Migration para permitir que Migraciones de Code First aplique scaffolding de
su mejor estimación en la migración. Vamos a llamar a esta migración AddPostClass .
Ejecute el comando Add-Migration AddPostClass en la consola del Administrador de paquetes.
Migraciones de Code First hizo un muy buen trabajo de scaffolding de estos cambios, pero hay algunas cosas
que es posible que queramos cambiar:
1. En primer lugar, vamos a agregar un índice único a la columna Posts.Title (adición en la línea 22 y 29 del
código siguiente).
2. También vamos a agregar una columna Blogs.Rating que no admite valores null. Si hay datos existentes en
la tabla, se les asigna el valor predeterminado CLR del tipo de datos para la nueva columna (Rating es entero,
por lo que sería 0 ). Pero queremos especificar un valor predeterminado de 3 , para que las filas existentes en
la tabla Blogs comiencen con una clasificación decente. (Puede ver el valor predeterminado especificado en
la línea 24 del código siguiente)
{
using System;
public partial class AddPostClass : DbMigration

{
{
CreateTable(
"dbo.Posts",
c => new
{
PostId = c.Int(nullable: false, identity: true),
Title = c.String(maxLength: 200),
Content = c.String(),
BlogId = c.Int(nullable: false),
})
.PrimaryKey(t => t.PostId)
.ForeignKey("dbo.Blogs", t => t.BlogId, cascadeDelete: true)
.Index(t => t.BlogId)
.Index(p => p.Title, unique: true);
AddColumn("dbo.Blogs", "Rating", c => c.Int(nullable: false, defaultValue: 3));

}

{
DropIndex("dbo.Posts", new[] { "Title" });
DropIndex("dbo.Posts", new[] { "BlogId" });
DropForeignKey("dbo.Posts", "BlogId", "dbo.Blogs");
DropColumn("dbo.Blogs", "Rating");
DropTable("dbo.Posts");
}
}
}
La migración editada ya está lista, así que vamos a usar Update-Database para actualizar la base de datos. Esta
vez vamos a especificar la marca -Verbose para que pueda ver el SQL que ejecuta Migraciones de Code First.
Ejecute el comando Update-Database –Verbose en la consola del Administrador de paquetes.
Movimiento de datos o SQL personalizado

Hasta ahora hemos examinado las operaciones de migración que no cambian ni mueven datos, y ahora vamos a
ver algo que necesita mover algunos datos. Todavía no hay compatibilidad nativa con el movimiento de datos,
pero podemos ejecutar algunos comandos SQL arbitrarios en cualquier punto del script.
Vamos a agregar una propiedad Post.Abstract al modelo. Luego, vamos a rellenar previamente el elemento
Abstract de publicaciones existentes con algún texto del inicio de la columna Content .
public string Abstract { get; set; }
Vamos a usar el comando Add-Migration para permitir que Migraciones de Code First aplique scaffolding de
su mejor estimación en la migración.
Ejecute el comando Add-Migration AddPostAbstract en la consola del Administrador de paquetes.
La migración generada se encarga de los cambios de esquema, pero además queremos rellenar previamente
la columna Abstract con los 100 primeros caracteres del contenido de cada publicación. Lo podemos hacer
si recurrimos a SQL y ejecutamos una instrucción UPDATE después de agregar la columna. (Adición en la
línea 12 del código siguiente)
{
using System;
public partial class AddPostAbstract : DbMigration

{
{
AddColumn("dbo.Posts", "Abstract", c => c.String());
Sql("UPDATE dbo.Posts SET Abstract = LEFT(Content, 100) WHERE Abstract IS NULL");

}

{
DropColumn("dbo.Posts", "Abstract");
}
}
}
La migración editada tiene buen aspecto, así que vamos a usar Update-Database para actualizar la base de
datos. Especificamos la marca –Verbose para poder ver el SQL que se ejecuta en la base de datos.
Migrar a una versión determinada (incluido un cambio a una versión

anterior)
Hasta ahora siempre hemos actualizado a la migración más reciente, pero puede haber ocasiones en que quiera
cambiar a una migración anterior o posterior.
Supongamos que queremos migrar la base de datos al estado en que estaba después de ejecutar la migración
AddBlogUrl . Podemos usar el modificador –TargetMigration para cambiar a esta migración anterior.
Ejecute el comando Update-Database –TargetMigration: AddBlogUrl en la consola del Administrador de
paquetes.
Este comando ejecuta el script Down de las migraciones AddBlogAbstract y AddPostClass .
Si quiere revertir a una base de datos vacía, puede usar el comando Update-Database –TargetMigration:
$InitialDatabase .
Obtención de un script SQL
Si otro desarrollador quiere estos cambios en su equipo, puede sincronizar una vez que se protejan los cambios
en el control de código fuente. Cuando tenga las nuevas migraciones, puede ejecutar el comando Update-
Database para que los cambios se apliquen localmente. Pero si queremos enviar estos cambios a un servidor de
prueba y, finalmente, a producción, probablemente querremos un script SQL que podamos pasar al DBA.
Ejecute el comando Update-Database , pero esta vez especifique la marca –Script para que los cambios se
escriban en un script en lugar de aplicarse. También se especifican una migración de origen y de destino para
las que generar el script. Queremos un script que abarque desde una base de datos vacía (
$InitialDatabase ) a la versión más reciente (migración AddPostAbstract ). Si no se especifica una
migración de destino, Migraciones usa la última migración como destino. Si no se especifica una migración
de origen, Migraciones usa el estado actual de la base de datos.
Ejecute el comando Update-Database -Script -SourceMigration: $InitialDatabase -TargetMigration:
AddPostAbstract en la consola del Administrador de paquetes.
Migraciones de Code First ejecuta la canalización de migración, pero en lugar de aplicar los cambios, los escribe
en un archivo .sql. Una vez que se ha generado el script, se abre automáticamente en Visual Studio, listo para
verse o guardarse.
Generación de scripts idempotentes
A partir de EF6, si especifica –SourceMigration $InitialDatabase , el script generado será "idempotente". Los
scripts idempotentes pueden actualizar una base de datos de cualquier versión a la versión más reciente (o la
versión especificada si se usa –TargetMigration ). El script generado incluye lógica para comprobar la tabla
__MigrationsHistor y y aplicar solo los cambios que no se han aplicado anteriormente.
Actualización automática al iniciar la aplicación (inicializador

MigrateDatabaseToLatestVersion)
Si va a implementar la aplicación, es posible que quiera que actualice la base de datos automáticamente (al
aplicar las migraciones pendientes) cuando se inicie. Puede hacerlo si registra el inicializador de base de datos
MigrateDatabaseToLatestVersion . Un inicializador de base de datos simplemente contiene alguna lógica que
se usa para asegurarse de que la base de datos se ha configurado correctamente. Esta lógica se ejecuta la
primera vez que se usa el contexto dentro del proceso de aplicación (AppDomain ).
Se puede actualizar el archivo Program.cs , como se muestra a continuación, para establecer el inicializador
MigrateDatabaseToLatestVersion para BlogContext antes de usar el contexto (línea 14). Tenga en cuenta que
también debe agregar una instrucción using para el espacio de nombres System.Data.Entity (línea 5).
Cuando se crea una instancia de este inicializador, se debe especificar el tipo de contexto (BlogContext ) y la
configuración de las migraciones (Configuration ): la configuración de las migraciones es la clase que se ha
agregado a la carpeta Migraciones al habilitar Migraciones.
using System;
using System.Linq;
using System.Text;
using MigrationsDemo.Migrations;
{
class Program
{
{
Database.SetInitializer(new MigrateDatabaseToLatestVersion<BlogContext, Configuration>());

{
db.SaveChanges();

{
}
}

Console.ReadKey();
}
}
}
Ahora, siempre que se ejecute la aplicación, en primer lugar comprobará si la base de datos de destino está
actualizada y, si no lo está, aplicará las migraciones pendientes.
Migraciones de Code First automática
Las migraciones automáticas permiten usar Migraciones de Code First sin tener un archivo de código en el
proyecto para cada cambio que realice. No todos los cambios se pueden aplicar automáticamente; por ejemplo, el
cambio de nombre de columna requiere el uso de una migración basada en código.
NOTE
En este artículo se supone que sabe cómo usar Migraciones de Code First en escenarios básicos. Si no lo hace, tendrá que
leer migraciones de Code First antes de continuar.
Recomendación para entornos de equipo

Puede intercalar migraciones automáticas y basadas en código, pero esto no se recomienda en escenarios de
desarrollo en equipo. Si forma parte de un equipo de desarrolladores que usan el control de código fuente, debe
usar migraciones automáticas o exclusivamente basadas en código. Dadas las limitaciones de las migraciones
automáticas, se recomienda usar migraciones basadas en código en entornos de equipo.
Creación de un modelo inicial y una base de datos

Antes de empezar a usar Migraciones, se necesitan un proyecto y un modelo de Code First con los que trabajar. En
este tutorial se va a usar el modelo canónico Blog y Post .
Creación de una nueva aplicación de consola de MigrationsAutomaticDemo
Agregue la versión más reciente del paquete NuGet de EntityFramework al proyecto
Herramientas –> Administrador de paquetes de biblioteca–> Consola del Administrador de
paquetes
Ejecute el comando Install-Package EntityFramework
Agregue un archivo Model.cs con el código que se muestra a continuación. Este código define una sola clase
Blog que conforma el modelo de dominio y una clase BlogContext que es el contexto de EF Code First
namespace MigrationsAutomaticDemo
{
{
}
public class Blog

{
}
}
Ahora que tenemos un modelo, es hora de usarlo para el acceso a los datos. Actualice el archivo Program.cs
con el código que se muestra a continuación.
using System;
using System.Linq;
using System.Text;
namespace MigrationsAutomaticDemo
{
class Program
{
{
{
db.SaveChanges();

{
}
}

Console.ReadKey();
}
}
}
Ejecute la aplicación y verá que se crea una base de datos MigrationsAutomaticCodeDemo.

BlogContext .
Habilitación de migraciones
Es hora de realizar más cambios en el modelo.
Vamos a introducir una propiedad Url en la clase Blog.
Si tuviera que ejecutar la aplicación de nuevo, obtendría una excepción InvalidOperationException que indicaba
que el modelo de respaldo del contexto ' BlogContext ' ha cambiado desde que se creó la base de datos. Considere
la posibilidad de usar Migraciones de Code First para actualizar la base de datos ( http://go.microsoft.com/fwlink/?
LinkId=238269 ).
Como sugiere la excepción, es hora de empezar a usar Migraciones de Code First. Dado que queremos usar
migraciones automáticas, vamos a especificar el modificador – EnableAutomaticMigrations .
Ejecute el comando enable-Migrations – EnableAutomaticMigrations en la consola del administrador
de paquetes. este comando ha agregado una carpeta Migrations a nuestro proyecto. Esta nueva carpeta
contiene un archivo:
La clase Configuration. Esta clase permite configurar el comportamiento de Migraciones en el contexto.
En este tutorial se usa la configuración predeterminada. Puesto que hay un solo contexto de Code First en el
proyecto, Enable-Migrations ha rellenado automáticamente el tipo de contexto al que se aplica esta
configuración.
La primera migración automática

Migraciones de Code First tiene dos comandos principales con los que se va a familiarizar.
Add-Migration aplica la técnica scaffolding a la siguiente migración en función de los cambios realizados en
el modelo desde la creación de la última migración
Update-Database aplica las migraciones pendientes a la base de datos
Vamos a evitar el uso de Add-Migration (a menos que realmente sea necesario) y nos centraremos en permitir que
Migraciones de Code First calcule y aplique los cambios automáticamente. Vamos a usar Update-Database para
obtener migraciones de Code First para enviar los cambios a nuestro modelo (la nueva propiedad blog. ur l) a la
base de datos.
Ejecute el comando Update-Database en la consola del administrador de paquetes.
La base de datos MigrationsAutomaticDemo. BlogContext se ha actualizado para incluir la columna URL en la
tabla blogs .
La segunda migración automática

Vamos a realizar otro cambio y dejar que Migraciones de Code First inserten automáticamente los cambios en la
base de datos.
También vamos a agregar una nueva clase Post
public class Post

{
[MaxLength(200)]

}
Además agregaremos una colección Posts a la clase Blog para formar el otro extremo de la relación entre
Blog y Post
Ahora use Update-Database para actualizar la base de datos. Esta vez vamos a especificar la marca -Verbose
para que pueda ver el SQL que ejecuta Migraciones de Code First.
Agregar una migración basada en código

Ahora veamos algo que es posible que quieramos usar una migración basada en código para.
Vamos a agregar una propiedad rating a la clase blog
Podríamos simplemente ejecutar Update-Database para realizar estos cambios en la base de datos. Sin
embargo, vamos a agregar una columna blogs. Rating que no aceptan valores NULL, si hay datos existentes en
la tabla, se asignará el valor predeterminado de CLR del tipo de datos de la nueva columna (la clasificación es
Integer, por lo que sería 0 ). Pero queremos especificar un valor predeterminado de 3 , para que las filas existentes
en la tabla Blogs comiencen con una clasificación decente. Vamos a usar el comando Add-Migration para escribir
este cambio en una migración basada en código para poder editarlo. El comando Add-Migration nos permite dar
un nombre a estas migraciones, simplemente vamos a llamar a nuestra AddBlogRating .
Ejecute el comando Add-Migration AddBlogRating en la consola del administrador de paquetes.
En la carpeta migraciones ahora tenemos una nueva migración de AddBlogRating . El nombre de archivo de
la migración se ha fijado previamente con una marca de tiempo para ayudar con la ordenación. Vamos a editar
el código generado para especificar un valor predeterminado de 3 para blog. Rating (línea 10 en el código
siguiente)
La migración también tiene un archivo de código subyacente que captura algunos metadatos. Estos metadatos
permitirán que Migraciones de Code First repliquen las migraciones automáticas realizadas antes de esta
migración basada en código. Esto es importante si otro desarrollador desea ejecutar nuestras migraciones o
Cuándo es el momento de implementar la aplicación.
namespace MigrationsAutomaticDemo.Migrations
{
using System;
public partial class AddBlogRating : DbMigration

{
{
AddColumn("Blogs", "Rating", c => c.Int(nullable: false, defaultValue: 3));
}

{
DropColumn("Blogs", "Rating");
}
}
}
La migración editada tiene buen aspecto, así que vamos a usar Update-Database para actualizar la base de
datos.
Volver a migraciones automáticas

Ahora podemos volver a pasar a las migraciones automáticas para nuestros cambios más sencillos. Migraciones
de Code First se encargará de realizar las migraciones automáticas y basadas en código en el orden correcto en
función de los metadatos que se almacenan en el archivo de código subyacente para cada migración basada en
código.
Vamos a agregar una propiedad post. Abstract a nuestro modelo
public string Abstract { get; set; }
Ahora podemos usar Update-Database para obtener migraciones de Code First para realizar este cambio en la
base de datos mediante una migración automática.
Resumen
En este tutorial, ha visto cómo usar las migraciones automáticas para realizar cambios en el modelo en la base de
datos. También ha visto cómo aplicar scaffolding y ejecutar migraciones basadas en código entre migraciones
automáticas cuando necesite más control.
Migraciones de Code First con una base de datos
existente
NOTE
EF 4.3 y versiones posteriores: las características, las API, etc. que se describen en esta página se introdujeron en Entity
Framework 4,1. Si usa una versión anterior, no se aplica parte o la totalidad de la información.
En este artículo se describe el uso de Migraciones de Code First con una base de datos existente, una que no se ha
creado con Entity Framework.
NOTE
Presentaciones en pantalla
Si prefiere ver una screencast que lea este artículo, los dos vídeos siguientes cubren el mismo contenido que este
artículo.
Vídeo uno: "migraciones-bajo el capó"
En esta presentación en pantalla se explica cómo realiza la migración y usa información sobre el modelo para
detectar los cambios de modelo.
Vídeo dos: "migraciones: bases de datos existentes"
Basándose en los conceptos del vídeo anterior, esta presentación en pantalla explica cómo habilitar y usar las
migraciones con una base de datos existente.
Paso 1: creación de un modelo

El primer paso será crear un modelo de Code First que tenga como destino la base de datos existente. En el tema
code First a una base de datos existente se proporcionan instrucciones detalladas sobre cómo hacerlo.
NOTE
Es importante seguir el resto de los pasos de este tema antes de realizar cambios en el modelo que requieran cambios en el
esquema de la base de datos. Los pasos siguientes requieren que el modelo esté sincronizado con el esquema de la base de
datos.
Paso 2: habilitar las migraciones

El siguiente paso consiste en habilitar las migraciones. Para ello, ejecute el comando enable-Migrations en la
consola del administrador de paquetes.
Este comando creará una carpeta en la solución denominada migraciones y colocará una sola clase en ella llamada
configuración. La clase de configuración es donde se configuran las migraciones de la aplicación, puede encontrar
más información en el tema migraciones de Code First .
Paso 3: agregar una migración inicial

Una vez que se han creado y aplicado las migraciones en la base de datos local, es posible que también desee
aplicar estos cambios a otras bases de datos. Por ejemplo, la base de datos local puede ser una base de datos de
prueba y, en última instancia, querrá aplicar también los cambios a una base de datos de producción o a otros
desarrolladores de prueba. Hay dos opciones para este paso y la que debe elegir depende de si el esquema de
otras bases de datos está vacío o no coincide actualmente con el esquema de la base de datos local.
Opción uno: usar el esquema existente como punto de par tida. Debe usar este enfoque si las demás
bases de datos que se van a aplicar a las migraciones en el futuro tendrán el mismo esquema que la base de
datos local que tiene actualmente. Por ejemplo, podría utilizarlo si la base de datos de prueba local coincide con
la versión 1 de la base de datos de producción y, posteriormente, aplicará estas migraciones para actualizar la
base de datos de producción a V2.
Opción dos: usar una base de datos vacía como punto de par tida. Debe usar este enfoque cuando las
demás bases de datos que se van a aplicar a las migraciones en el futuro estén vacías (o aún no existan). Por
ejemplo, podría utilizarlo si comenzó a desarrollar la aplicación con una base de datos de prueba pero sin usar
migraciones y posteriormente deseará crear una base de datos de producción desde cero.
Opción uno: usar el esquema existente como punto de partida
Migraciones de Code First usa una instantánea del modelo almacenada en la migración más reciente para detectar
los cambios en el modelo (puede encontrar información detallada sobre esto en migraciones de Code First en
entornos de equipo). Como vamos a suponer que las bases de datos ya tienen el esquema del modelo actual,
generaremos una migración vacía (no operativa) que tenga el modelo actual como una instantánea.
1. Ejecute el comando Add-Migration InitialCreate – IgnoreChanges en la consola del administrador de
paquetes. Esto crea una migración vacía con el modelo actual como una instantánea.
2. Ejecute el comando Update-Database en la consola del administrador de paquetes. Esto aplicará la migración
de InitialCreate a la base de datos. Dado que la migración real no contiene ningún cambio, simplemente
agregará una fila al __tabla MigrationsHistory, que indica que ya se ha aplicado esta migración.
Opción dos: usar una base de datos vacía como punto de partida
En este escenario, se necesitan migraciones para poder crear la base de datos completa desde cero, incluidas las
tablas que ya están presentes en nuestra base de datos local. Vamos a generar una migración de InitialCreate que
incluye la lógica para crear el esquema existente. A continuación, haremos que nuestra base de datos existente
tenga el mismo aspecto que ya se ha aplicado esta migración.
1. Ejecute el comando Add-Migration InitialCreate en la consola del administrador de paquetes. Esto crea una
migración para crear el esquema existente.
2. Comente todo el código del método up de la migración recién creada. Esto nos permitirá "aplicar" la migración
a la base de datos local sin intentar volver a crear todas las tablas, etc., que ya existen.
3. Ejecute el comando Update-Database en la consola del administrador de paquetes. Esto aplicará la migración
de InitialCreate a la base de datos. Dado que la migración real no contiene ningún cambio (porque hemos
comentado temporalmente), simplemente agregará una fila al __tabla MigrationsHistory que indica que ya se
ha aplicado esta migración.
4. Quite la marca de comentario del código en el método up. Esto significa que, cuando esta migración se aplica a
bases de datos futuras, el esquema que ya existía en la base de datos local lo crearán las migraciones.
Aspectos que debe tener en cuenta

Hay algunas cosas que debe tener en cuenta al usar migraciones en una base de datos existente.
Los nombres predeterminados o calculados pueden no coincidir con el esquema existente
Las migraciones especifican explícitamente los nombres de las columnas y las tablas cuando se scaffolding una
migración. Sin embargo, hay otros objetos de base de datos que las migraciones calculan un nombre
predeterminado para cuando se aplican las migraciones. Esto incluye los índices y las restricciones Foreign Key.
Cuando el destino es un esquema existente, es posible que estos nombres calculados no coincidan con lo que
existe realmente en la base de datos.
Estos son algunos ejemplos de Cuándo es necesario tener en cuenta lo siguiente:
Si usó ' opción uno: usar el esquema existente como punto de par tida ' del paso 3:
Si los cambios futuros en el modelo requieren el cambio o la eliminación de uno de los objetos de base de
datos que se denominan de forma diferente, tendrá que modificar la migración con scaffolding para especificar
el nombre correcto. Las API de migraciones tienen un parámetro de nombre opcional que le permite hacerlo.
Por ejemplo, el esquema existente puede tener una tabla post con una columna de clave externa BlogId que
tenga un índice denominado IndexFk_BlogId. Sin embargo, de forma predeterminada, las migraciones
esperaban que este índice se denomine IX_BlogId. Si realiza un cambio en el modelo que tiene como resultado
la eliminación de este índice, tendrá que modificar la llamada a scaffolding DropIndex para especificar el
nombre de BlogId de IndexFk_.
Si ha usado la opción dos: usar una base de datos vacía como punto de par tida en el paso 3:
Puede producirse un error al intentar ejecutar el método Down de la migración inicial (es decir, revertir a una
base de datos vacía) en la base de datos local, ya que las migraciones intentarán quitar índices y restricciones
de clave externa usando los nombres incorrectos. Esto solo afectará a la base de datos local, ya que las demás
bases de datos se crearán desde cero con el método up de la migración inicial. Si desea cambiar la base de
datos local existente a un estado vacío, es más fácil hacerlo manualmente, ya sea quitando la base de datos o
quitando todas las tablas. Después de esta degradación inicial, todos los objetos de base de datos se volverán a
crear con los nombres predeterminados, por lo que este problema no se volverá a presentar.
Si los cambios futuros en el modelo requieren el cambio o la eliminación de uno de los objetos de base de
datos con el nombre diferente, no funcionará en la base de datos local existente, ya que los nombres no
coinciden con los valores predeterminados. Sin embargo, funcionará en las bases de datos que se crearon
desde cero, ya que se usarán los nombres predeterminados elegidos por las migraciones. Puede realizar estos
cambios de forma manual en la base de datos existente o considerar la posibilidad de hacer que las
migraciones vuelvan a crear la base de datos desde cero, como se hará en otras máquinas.
Las bases de datos creadas con el método up de la migración inicial pueden diferir ligeramente de la base de
datos local, ya que se usarán los nombres predeterminados calculados para los índices y las restricciones
Foreign Key. También puede acabar con índices adicionales ya que las migraciones crearán índices en columnas
de clave externa de forma predeterminada; esto puede no haber sido el caso en la base de datos local original.
No todos los objetos de base de datos se representan en el modelo
Los objetos de base de datos que no forman parte de su modelo no serán controlados por las migraciones. Esto
puede incluir vistas, procedimientos almacenados, permisos, tablas que no forman parte del modelo, índices
adicionales, etc.
Estos son algunos ejemplos de Cuándo es necesario tener en cuenta lo siguiente:
Independientemente de la opción elegida en el ' paso 3 ', si los cambios futuros en el modelo requieren el
cambio o la eliminación de estas migraciones de objetos adicionales, no sabrá realizar estos cambios. Por
ejemplo, si quita una columna que tiene un índice adicional en ella, las migraciones no sabrán quitar el índice.
Tendrá que agregarlo manualmente a la migración con scaffolding.
Si ha usado la opción dos: usar una base de datos vacía como punto de partida, estos objetos adicionales no se
crearán con el método up de la migración inicial. Puede modificar los métodos arriba y abajo para que se
ocupen de estos objetos adicionales si lo desea. En el caso de los objetos que no se admiten de forma nativa en
la API de migraciones, como las vistas, puede usar el método SQL para ejecutar SQL sin formato para crearlos y
quitarlos.
Personalización de la tabla de historial de
migraciones
NOTE
NOTE
¿Qué es la tabla de historial de migraciones?

La tabla de historial de migraciones es una tabla que usa Migraciones de Code First para almacenar detalles sobre
las migraciones que se aplican a la base de datos. De forma predeterminada, el nombre de la tabla de la base de
datos se __MigrationHistory y se crea al aplicar la primera migración a la base de datos. En Entity Framework 5,
esta tabla era una tabla del sistema si la aplicación usaba la base de datos de Microsoft SQL Server. No obstante,
esto ha cambiado en Entity Framework 6 y la tabla de historial de migraciones ya no está marcada como una tabla
del sistema.
¿Por qué personalizar la tabla de historial de migraciones?

La tabla de historial de migraciones se supone que se usará únicamente en Migraciones de Code First y cambiarla
manualmente puede interrumpir las migraciones. Sin embargo, a veces la configuración predeterminada no es
adecuada y la tabla debe personalizarse, por ejemplo:
Debe cambiar los nombres y/o las caras de las columnas para habilitar un proveedor de migracionesde terceras
partes.
Desea cambiar el nombre de la tabla

Debe usar un esquema no predeterminado para la __tabla MigrationHistory
Necesita almacenar datos adicionales para una versión determinada del contexto y, por tanto, necesita agregar
una columna adicional a la tabla.
Palabras de precaución
Cambiar la tabla de historial de migración es eficaz, pero debe tener cuidado de no abusar. En la actualidad, el
tiempo de ejecución de EF no comprueba si la tabla de historial de migraciones personalizada es compatible con el
tiempo de ejecución. Si no es así, es posible que la aplicación se interrumpa en tiempo de ejecución o se comporte
de maneras imprevisibles. Esto es aún más importante si usa varios contextos por base de datos, en cuyo caso
varios contextos pueden usar la misma tabla de historial de migración para almacenar información acerca de las
migraciones.
¿Cómo se personaliza la tabla de historial de migraciones?

Antes de empezar, debe saber que solo puede personalizar la tabla de historial de migraciones antes de aplicar la
primera migración. Ahora, en el código.
En primer lugar, tendrá que crear una clase derivada de la clase System. Data. Entity. Migrations. History.
HistoryContext. La clase HistoryContext se deriva de la clase DbContext, por lo que la configuración de la tabla de
historial de migraciones es muy similar a la configuración de modelos EF con la API fluida. Solo tiene que invalidar
el método OnModelCreating y usar la API fluida para configurar la tabla.
NOTE
Normalmente, cuando se configuran modelos EF no es necesario llamar a base. OnModelCreating () del método
OnModelCreating invalidado, ya que DbContext. OnModelCreating () tiene un cuerpo vacío. Este no es el caso cuando se
configura la tabla de historial de migraciones. En este caso, lo primero que hay que hacer en la invalidación de
OnModelCreating () es, en realidad, llamar a base. OnModelCreating (). De esta forma, se configurará la tabla de historial de
migraciones de la manera predeterminada que se va a ajustar en el método de reemplazo.
Supongamos que desea cambiar el nombre de la tabla de historial de migraciones y colocarla en un esquema
personalizado denominado "admin". Además, los DBA le gustaría cambiar el nombre de la columna MigrationId al
identificador de_de migración. Para ello, cree la clase siguiente derivada de HistoryContext:
using System.Data.Entity.Migrations.History;
namespace CustomizableMigrationsHistoryTableSample
{
public class MyHistoryContext : HistoryContext
{
public MyHistoryContext(DbConnection dbConnection, string defaultSchema)
: base(dbConnection, defaultSchema)
{
}

{
base.OnModelCreating(modelBuilder);
modelBuilder.Entity<HistoryRow>().ToTable(tableName: "MigrationHistory", schemaName: "admin");
modelBuilder.Entity<HistoryRow>().Property(p => p.MigrationId).HasColumnName("Migration_ID");
}
}
}
Una vez que el HistoryContext personalizado esté listo, debe hacer que EF lo tenga al registrarlo mediante la
configuración basada en código:
namespace CustomizableMigrationsHistoryTableSample
{
public class ModelConfiguration : DbConfiguration
{
public ModelConfiguration()
{
this.SetHistoryContext("System.Data.SqlClient",
(connection, defaultSchema) => new MyHistoryContext(connection, defaultSchema));
}
}
}
Eso es prácticamente todo. Ahora puede ir a la consola del administrador de paquetes, habilitar-migraciones,
agregar-migrar y, finalmente, actualizar-base de datos. Esto debería hacer que se agregue a la base de datos una
tabla de historial de migraciones configurada según los detalles especificados en la clase derivada HistoryContext.
Uso de Migrate. exe
Migraciones de Code First se puede utilizar para actualizar una base de datos desde Visual Studio, pero también se
puede ejecutar mediante la herramienta de línea de comandos Migrate. exe. Esta página proporcionará
información general rápida sobre cómo usar Migrate. exe para ejecutar migraciones en una base de datos de.
NOTE
Copiar Migrate. exe

Al instalar Entity Framework mediante NuGet Migrate. exe estará dentro de la carpeta Tools del paquete
descargado. En <carpeta del proyecto>\paquetes\EntityFramework.<versión>herramientas \
Una vez que haya migrado. exe, debe copiarlo en la ubicación del ensamblado que contiene las migraciones.
Si su aplicación tiene como destino .NET 4, y no 4,5, tendrá que copiar también el archivo Redirect. config en la
ubicación y cambiar el nombre de Migrate. exe. config . Esto es para que Migrate. exe obtenga las redirecciones
de enlace correctas para poder encontrar el ensamblado de Entity Framework.
. N ET 4. 5 . N ET 4. 0
NOTE
Migrate. exe no admite ensamblados x64.
Una vez que haya trasladado Migrate. exe a la carpeta correcta, debería poder usarlo para ejecutar migraciones en
la base de datos. Todas las utilidades están diseñadas para ejecutar migraciones. No puede generar migraciones ni
crear un script SQL.
Vea opciones
Migrate.exe /?
Lo anterior mostrará la página de ayuda asociada a esta utilidad. tenga en cuenta que deberá tener el archivo
EntityFramework. dll en la misma ubicación en la que está ejecutando Migrate. exe para que funcione.
Migrar a la migración más reciente

Migrate.exe MyMvcApplication.dll /startupConfigurationFile="..\\web.config"
Al ejecutar Migrate. exe, el único parámetro obligatorio es el ensamblado, que es el ensamblado que contiene las
migraciones que está intentando ejecutar, pero utilizará todos los valores basados en convenciones si no especifica
el archivo de configuración.
Migrar a una migración específica

Migrate.exe MyApp.exe /startupConfigurationFile="MyApp.exe.config" /targetMigration="AddTitle"
Si desea ejecutar migraciones hasta una migración específica, puede especificar el nombre de la migración. Se
ejecutarán todas las migraciones anteriores según sea necesario hasta llegar a la migración especificada.
Especificar el directorio de trabajo

Migrate.exe MyApp.exe /startupConfigurationFile="MyApp.exe.config" /startupDirectory="c:\\MyApp"
Si el ensamblado tiene dependencias o lee archivos en relación con el directorio de trabajo, tendrá que establecer
startupDirectory.
Especificar la configuración de migración que se va a usar

Migrate.exe MyAssembly CustomConfig /startupConfigurationFile="..\\web.config"
Si tiene varias clases de configuración de migración, las clases que heredan de DbMigrationConfiguration, debe
especificar qué se va a usar para esta ejecución. Esto se especifica proporcionando el segundo parámetro opcional
sin un modificador como el anterior.
Proporcionar una cadena de conexión

Migrate.exe BlogDemo.dll /connectionString="Data Source=localhost;Initial Catalog=BlogDemo;Integrated
Security=SSPI" /connectionProviderName="System.Data.SqlClient"
Si desea especificar una cadena de conexión en la línea de comandos, también debe proporcionar el nombre del
proveedor. Si no se especifica el nombre del proveedor, se producirá una excepción.
Problemas habituales
M EN SA JE DE ERRO R SO L UC IÓ N
Excepción no controlada: System. IO. FileLoadException: no se Normalmente, esto significa que se ejecuta una aplicación .NET
pudo cargar el archivo o ensamblado ' EntityFramework, 4 sin el archivo Redirect. config. Debe copiar el archivo
version = 5.0.0.0, Culture = neutral, PublicKeyToken = Redirect. config en la misma ubicación que Migrate. exe y
b77a5c561934e089 ' o una de sus dependencias. La cambiarle el nombre a Migrate. exe. config.
definición del manifiesto del ensamblado encontrado no
coincide con la referencia de ensamblado. (Excepción de
HRESULT: 0x80131040)
Excepción no controlada: System. IO. FileLoadException: no se Esta excepción significa que está ejecutando una aplicación
pudo cargar el archivo o ensamblado ' EntityFramework, .NET 4,5 con el archivo Redirect. config copiado en la ubicación
version = 4.4.0.0, Culture = neutral, PublicKeyToken = Migrate. exe. Si la aplicación es .NET 4,5, no es necesario tener
b77a5c561934e089 ' o una de sus dependencias. La el archivo de configuración con las redirecciones dentro de.
definición del manifiesto del ensamblado encontrado no Elimine el archivo Migrate. exe. config.
coincide con la referencia de ensamblado. (Excepción de
HRESULT: 0x80131040)
ERROR: no se puede actualizar la base de datos para que Este error se produce si se ejecuta Migrate cuando no se ha
coincida con el modelo actual porque hay cambios pendientes creado una migración para hacer frente a los cambios
y la migración automática está deshabilitada. Escriba los realizados en el modelo y la base de datos no coincide con el
cambios de modelo pendientes en una migración basada en modelo. La adición de una propiedad a una clase de modelo y,
código o habilite la migración automática. Establezca a continuación, la ejecución de Migrate. exe sin crear una
DbMigrationsConfiguration. AutomaticMigrationsEnabled en migración para actualizar la base de datos es un ejemplo de
true para habilitar la migración automática. esto.
ERROR: el tipo no se ha resuelto para el miembro ' System. Este error puede deberse al especificar un directorio de inicio
Data. Entity. Migrations. Design. ToolingFacade + incorrecto. Debe ser la ubicación de Migrate. exe.
UpdateRunner, EntityFramework, version = 5.0.0.0, Culture =
neutral, PublicKeyToken = b77a5c561934e089 '.
Excepción no controlada: System. NullReferenceException: Esto puede deberse a que no se especifica un parámetro
referencia de objeto no establecida en una instancia de un necesario para un escenario que se está usando. Por ejemplo,
objeto. si se especifica una cadena de conexión sin especificar el
en System. Data. Entity. Migrations. Console. Program. Main nombre del proveedor.
(String [] args)
ERROR: se encontró más de un tipo de configuración de Como indica el error, hay más de una clase de configuración
migraciones en el ensamblado ' ClassLibrary1 '. Especifique el en el ensamblado especificado. Debe usar el
nombre del que se va a usar. modificador/configurationType para especificar cuál utilizar.
ERROR: no se pudo cargar el archivo o ensamblado Esto puede deberse al hecho de especificar un nombre de
'<assemblyName>' o una de sus dependencias. El nombre de ensamblado incorrectamente o no tener
ensamblado o el código base especificados no son válidos.
(Excepción de HRESULT: 0x80131047)
ERROR: no se pudo cargar el archivo o ensamblado Esto sucede si está intentando ejecutar Migrate. exe en una
'<assemblyName>' o una de sus dependencias. Se ha aplicación x64. EF 5,0 y versiones anteriores solo funcionarán
intentado cargar un programa con un formato incorrecto. en x86.
Migraciones de Code First en entornos de equipo
NOTE
Tome un café, debe leer todo el artículo

Los problemas en los entornos de equipo están principalmente en torno a la combinación de migraciones cuando
dos desarrolladores han generado migraciones en su base de código local. Aunque los pasos para solucionar
estos problemas son bastante sencillos, es necesario tener un conocimiento sólido de cómo funcionan las
migraciones. No avance hasta el final; Tómese el tiempo necesario para leer todo el artículo y asegurarse de que se
ha realizado correctamente.
Algunas directrices generales

Antes de profundizar en cómo administrar las migraciones de combinación generadas por varios desarrolladores,
estas son algunas directrices generales para configurar el éxito.
Cada miembro del equipo debe tener una base de datos de desarrollo local
Las migraciones utilizan la __tabla MigrationsHistor y para almacenar las migraciones que se han aplicado a la
base de datos. Si tiene varios desarrolladores que generan distintas migraciones al intentar tener como destino la
misma base de datos (y, por tanto, compartir una __tabla MigrationsHistor y ), las migraciones se van a
confundir.
Por supuesto, si tiene miembros del equipo que no están generando migraciones, no hay problemas para que
compartan una base de datos de desarrollo central.
Evitar migraciones automáticas
La línea inferior es que las migraciones automáticas tienen un aspecto correcto en los entornos de equipo, pero en
realidad no funcionan. Si desea saber por qué, siga leyendo; si no es así, puede ir directamente a la sección
siguiente.
Migraciones automáticas permite actualizar el esquema de la base de datos para que coincida con el modelo
actual sin necesidad de generar archivos de código (migraciones basadas en código). Las migraciones automáticas
funcionarían bien en un entorno de equipo si solo se usaron y nunca se generaron migraciones basadas en
código. El problema es que las migraciones automáticas están limitadas y no controlan varias operaciones: cambio
de nombre de propiedades o columnas, movimiento de datos a otra tabla, etc. Para controlar estos escenarios,
acaba de generar migraciones basadas en código (y editar el código con scaffolding) que se mezclan entre los
cambios administrados por migraciones automáticas. Esto hace que resulte casi imposible combinar los cambios
cuando dos desarrolladores protegen las migraciones.
Presentaciones en pantalla
Si prefiere ver una screencast que lea este artículo, los dos vídeos siguientes cubren el mismo contenido que este
artículo.
Vídeo uno: "migraciones-bajo el capó"
En esta presentación en pantalla se explica cómo realiza la migración y usa información sobre el modelo para
detectar los cambios de modelo.
Vídeo dos: "migraciones: entornos de equipo"
Basándose en los conceptos del vídeo anterior, esta presentación en pantalla trata los problemas que surgen en un
entorno de equipo y cómo resolverlos.
Descripción de cómo funcionan las migraciones

La clave para usar correctamente las migraciones en un entorno de equipo es una descripción básica de cómo
realiza la migración y usa información sobre el modelo para detectar los cambios de modelo.
La primera migración
Al agregar la primera migración al proyecto, ejecute algo como Add-Migration First en la consola del
administrador de paquetes. Los pasos de alto nivel que realiza este comando se muestran a continuación.
El modelo actual se calcula a partir del código (1). Los objetos de base de datos necesarios se calculan a
continuación por el modelo difiere (2): dado que se trata de la primera migración, el modelo solo se usa un
modelo vacío para la comparación. Los cambios necesarios se pasan al generador de código para compilar el
código de migración necesario (3) que después se agrega a la solución de Visual Studio (4).
Además del código de migración real que se almacena en el archivo de código principal, las migraciones también
generan algunos archivos de código subyacente adicionales. Estos archivos son metadatos que se usan en las
migraciones y no son algo que deba editar. Uno de estos archivos es un archivo de recursos (. resx) que contiene
una instantánea del modelo en el momento en que se generó la migración. Verá cómo se usa en el paso siguiente.
En este momento, probablemente ejecute Update-Database para aplicar los cambios a la base de datos y, a
continuación, vaya a la implementación de otras áreas de la aplicación.
Migraciones posteriores
Más adelante, volverá a realizar algunos cambios en el modelo. en nuestro ejemplo, agregaremos una propiedad
de dirección URL al blog . A continuación, debe emitir un comando como Add-Migration AddUrl para aplicar
scaffolding a una migración a fin de aplicar los cambios de base de datos correspondientes. Los pasos de alto nivel
que realiza este comando se muestran a continuación.
Al igual que la última vez, el modelo actual se calcula a partir del código (1). Sin embargo, esta vez hay
migraciones existentes, por lo que el modelo anterior se recupera de la última migración (2). Estos dos modelos se
diferencian para encontrar los cambios de base de datos necesarios (3) y, a continuación, el proceso se completa
como antes.
Este mismo proceso se usa para las migraciones posteriores que agregue al proyecto.
¿Por qué molestarse con la instantánea del modelo?
Es posible que se pregunte por qué EF ambos con la instantánea del modelo, por qué no solo mirar en la base de
datos. En caso afirmativo, siga leyendo. Si no está interesado, puede omitir esta sección.
Hay varias razones por las que EF mantiene la instantánea del modelo:
Permite que la base de datos se desvíe del modelo EF. Estos cambios se pueden realizar directamente en la base
de datos o puede cambiar el código con scaffolding en las migraciones para realizar los cambios. Estos son
algunos ejemplos de esto en la práctica:
Desea agregar una columna Inserted y Updated to a una o varias tablas, pero no desea incluir estas
columnas en el modelo EF. Si las migraciones examinaban la base de datos, intentaría quitar
continuamente estas columnas cada vez que se aplicara una migración scaffolding. Con la instantánea
del modelo, EF solo detectará los cambios legítimos en el modelo.
Desea cambiar el cuerpo de un procedimiento almacenado usado para que las actualizaciones incluyan
algún registro. Si las migraciones examinaban este procedimiento almacenado desde la base de datos,
intentaría volver a restablecerla continuamente a la definición que EF espera. Mediante el uso de la
instantánea del modelo, EF solo creará código scaffolding para modificar el procedimiento almacenado
cuando cambie la forma del procedimiento en el modelo EF.
Estos mismos principios se aplican a la adición de índices adicionales, incluidas tablas adicionales en la
base de datos, la asignación de EF a una vista de base de datos que se encuentra sobre una tabla, etc.
El modelo EF contiene algo más que la forma de la base de datos. Tener el modelo completo permite a las
migraciones ver información sobre las propiedades y las clases del modelo y cómo se asignan a las columnas y
tablas. Esta información permite que las migraciones sean más inteligentes en el código que scaffolding. Por
ejemplo, si cambia el nombre de la columna que una propiedad se asigna a las migraciones puede detectar el
cambio de nombre observando que es la misma propiedad, algo que no se puede hacer si solo tiene el
esquema de la base de datos.
Qué provoca problemas en los entornos de equipo
El flujo de trabajo que se trata en la sección anterior funciona bien cuando es un desarrollador único que trabaja
en una aplicación. También funciona bien en un entorno de equipo si es la única persona que realiza cambios en el
modelo. En este escenario puede realizar cambios en el modelo, generar migraciones y enviarlos al control de
código fuente. Otros desarrolladores pueden sincronizar los cambios y ejecutar Update-Database para aplicar
los cambios de esquema.
Los problemas empiezan a surgir cuando tiene varios desarrolladores que realizan cambios en el modelo de EF y
envían al control de código fuente al mismo tiempo. Lo que es EF falta es una primera forma de combinar las
migraciones locales con las migraciones que otro desarrollador ha enviado al control de código fuente desde que
se sincronizó por última vez.
Ejemplo de un conflicto de combinación

En primer lugar, echemos un vistazo a un ejemplo concreto de este tipo de conflicto de combinación.
Continuaremos con el ejemplo que hemos examinado anteriormente. Como punto de partida, supongamos que el
desarrollador original protegió los cambios de la sección anterior. Haremos un seguimiento de dos
desarrolladores a medida que realizan cambios en el código base.
Seguiremos el modelo EF y las migraciones a través de una serie de cambios. Para un punto de partida, ambos
desarrolladores se han sincronizado con el repositorio de control de código fuente, tal y como se muestra en el
gráfico siguiente.
Developer #1 y Developer #2 ahora realiza algunos cambios en el modelo de EF en su base de código local.
Developer #1 agrega una propiedad rating al blog y genera una migración AddRating para aplicar los cambios
a la base de datos. Developer #2 agrega una propiedad Readers al blog y genera la migración de AddReaders
correspondiente. Ambos desarrolladores ejecutan Update-Database para aplicar los cambios a sus bases de
datos locales y, a continuación, seguir desarrollando la aplicación.
NOTE
Las migraciones llevan el prefijo de una marca de tiempo, por lo que nuestro gráfico representa que la migración de
AddReaders de Developer #2 viene después de la migración de AddRating de Developer #1. Si Developer #1 o #2 generó la
migración, en primer lugar no realiza ninguna diferencia con los problemas de trabajo en un equipo o el proceso para
combinarlos en la sección siguiente.
El día de la suerte para Developer #1 a medida que se producen para enviar sus cambios en primer lugar. Dado
que no se ha protegido ningún otro usuario desde que se sincronizó su repositorio, solo pueden enviar sus
cambios sin realizar ninguna combinación.
Ahora es el momento de enviar el desarrollador #2. No son tan afortunados. Dado que otra persona ha enviado
cambios desde que se sincronizaron, deberán desplegar los cambios y mezclar. Es posible que el sistema de
control de código fuente pueda fusionar mediante combinación automáticamente los cambios en el nivel de
código, ya que son muy sencillos. El estado del repositorio local del desarrollador #2 después de la sincronización
se muestra en el gráfico siguiente.
En esta fase, el desarrollador #2 puede ejecutar Update-Database , que detectará la nueva migración de
AddRating (que no se ha aplicado a la base de datos de Developer #2) y la aplicará. Ahora se agrega la columna
clasificación a la tabla blogs y la base de datos está sincronizada con el modelo.
Sin embargo, hay un par de problemas:
1. Aunque Update-Database aplicará la migración de AddRating también generará una advertencia: no se
puede actualizar la base de datos para que coincida con el modelo actual porque hay cambios pendientes y la
migración automática está deshabilitada... El problema es que la instantánea del modelo almacenada en la
última migración (AddReader ) no tiene la propiedad rating en el blog (puesto que no formaba parte del
modelo cuando se generó la migración). Code First detecta que el modelo de la última migración no coincide
con el modelo actual y genera la advertencia.
2. Ejecutar la aplicación daría como resultado una excepción InvalidOperationException que indica que "el modelo
de respaldo del contexto ' BloggingContext ' ha cambiado desde que se creó la base de datos. Considere la
posibilidad de usar Migraciones de Code First para actualizar la base de datos... " De nuevo, el problema es que
la instantánea del modelo almacenada en la última migración no coincide con el modelo actual.
3. Por último, esperamos que la ejecución de Add-Migration genere una migración vacía (ya que no hay ningún
cambio que se aplique a la base de datos). Sin embargo, dado que las migraciones comparan el modelo actual
con el de la última migración (que no tiene la propiedad rating ), en realidad scaffolding otra llamada
AddColumn para agregarla a la columna de clasificación . Por supuesto, esta migración produciría un error
durante la actualización de la base de datos porque la columna de clasificación ya existe.
Resolver el conflicto de fusión mediante combinación
La buena noticia es que no es demasiado difícil tratar la combinación manualmente, siempre que tenga un
conocimiento de cómo funcionan las migraciones. Por lo tanto, si ha omitido el paso anterior a esta sección... Lo
sentimos, debe volver y leer el resto del artículo en primer lugar.
Hay dos opciones, lo más fácil es generar una migración en blanco que tenga el modelo actual correcto como una
instantánea. La segunda opción es actualizar la instantánea de la última migración para que tenga la instantánea
del modelo correcta. La segunda opción es un poco más difícil y no se puede usar en todos los escenarios, pero
también es más limpia porque no implica agregar una migración adicional.
Opción 1: agregar una migración de ' Merge ' en blanco
En esta opción, se genera una migración en blanco únicamente con el fin de asegurarse de que la migración más
reciente tenga almacenada la instantánea del modelo correcta.
Esta opción se puede usar independientemente de quién haya generado la última migración. En el ejemplo que
hemos estado siguiendo el desarrollador #2 está tomando en consideración la combinación y se han producido
para generar la última migración. Pero se pueden usar los mismos pasos si Developer #1 generó la última
migración. Los pasos también se aplican si hay varias migraciones implicadas: hemos visto dos con el fin de
simplificar el proceso.
El siguiente proceso se puede usar para este enfoque, a partir del momento en que se dé cuenta de que tiene
cambios que deben sincronizarse desde el control de código fuente.
1. Asegúrese de que los cambios de modelos pendientes en la base de código local se han escrito en una
migración. Este paso garantiza que no se pierda ningún cambio legítimo cuando llegue el momento de generar
la migración en blanco.
2. Sincronizar con control de código fuente.
3. Ejecute Update-Database para aplicar las nuevas migraciones que hayan protegido otros desarrolladores.
Nota: si no recibe ninguna advertencia del comando UPDATE-Database, no habrá nuevas migraciones de otros
desarrolladores y no será necesario realizar ninguna combinación adicional.
4. Ejecute Add-migration <pick_un nombre de_> – IgnoreChanges (por ejemplo, Add-Migration Merge
– IgnoreChanges ). Esto genera una migración con todos los metadatos (incluida una instantánea del modelo
actual), pero omitirá todos los cambios que detecte al comparar el modelo actual con la instantánea en las
últimas Migraciones (lo que significa que obtiene un método en blanco y ver tical ).
5. Continúe desarrollando o envíe el control de código fuente (después de ejecutar las pruebas unitarias del
curso).
Este es el estado de la base de código local del desarrollador #2 después de usar este enfoque.
Opción 2: actualizar la instantánea del modelo en la última migración
Esta opción es muy similar a la opción 1, pero quita la migración en blanco adicional, porque nos encargamos de
ello, que quiere archivos de código adicionales en su solución.
Este enfoque solo es factible si la migración más reciente solo existe en la base de código local y
aún no se ha enviado al control de código fuente (por ejemplo, si la última migración fue generada
por el usuario que realizó la mezcla) . La edición de los metadatos de las migraciones que otros
desarrolladores pueden haber aplicado ya a su base de datos de desarrollo, o incluso peor si se aplican a una base
de datos de producción, puede producir efectos secundarios inesperados. Durante el proceso, vamos a revertir la
última migración en nuestra base de datos local y volver a aplicarla con los metadatos actualizados.
Aunque la última migración debe estar solo en la base de código local, no hay ninguna restricción sobre el
número o el orden de las migraciones que lo continúan. Puede haber varias migraciones de varios desarrolladores
diferentes y se aplican los mismos pasos: simplemente hemos visto dos con el fin de mantenerlos sencillos.
El siguiente proceso se puede usar para este enfoque, a partir del momento en que se dé cuenta de que tiene
cambios que deben sincronizarse desde el control de código fuente.
1. Asegúrese de que los cambios de modelos pendientes en la base de código local se han escrito en una
migración. Este paso garantiza que no se pierda ningún cambio legítimo cuando llegue el momento de generar
la migración en blanco.
2. Sincronizar con el control de código fuente.
3. Ejecute Update-Database para aplicar las nuevas migraciones que hayan protegido otros desarrolladores.
Nota: si no recibe ninguna advertencia del comando UPDATE-Database, no habrá nuevas migraciones de otros
desarrolladores y no será necesario realizar ninguna combinación adicional.
4. Ejecute Update-Database – TargetMigration <second_última_migración> (en el ejemplo que hemos
estado siguiendo esto sería Update-Database – TargetMigration AddRating ). De este modo, la base de
datos vuelve al estado de la segunda migración, con lo que se "anula la aplicación" de la última migración de la
base de datos. Nota: este paso es necesario para que sea seguro editar los metadatos de la migración, ya que
los metadatos también se almacenan en la __MigrationsHistoryTable de la base de datos. Esta es la razón por la
que solo debe usar esta opción si la última migración solo está en la base de código local. Si se ha aplicado la
última migración a otras bases de datos, también tendrá que revertirla y volver a aplicar la última migración
para actualizar los metadatos.
5. Ejecute Add-migration <nombre de_completo_incluido_marca de tiempo___> de migración del
último (en el ejemplo que hemos estado siguiendo esto sería algo como Add-Migration
201311062215252_AddReaders ). Nota: debe incluir la marca de tiempo para que las migraciones sepan
que desea editar la migración existente en lugar de aplicar la técnica scaffolding a una nueva. De esta forma, se
actualizarán los metadatos de la última migración para que coincida con el modelo actual. Obtendrá la
siguiente advertencia cuando se complete el comando, pero eso es exactamente lo que desea. "Solo se volvió a
scaffolding el código del diseñador para la migración ' 201311062215252_AddReaders '. Para volver a aplicar
el scaffolding a toda la migración, use el parámetro-Force ".
6. Ejecute Update-Database para volver a aplicar la migración más reciente con los metadatos actualizados.
7. Continúe desarrollando o envíe el control de código fuente (después de ejecutar las pruebas unitarias del
curso).
Este es el estado de la base de código local del desarrollador #2 después de usar este enfoque.
Resumen
El uso de Migraciones de Code First en un entorno de equipo conlleva algunos desafíos. Sin embargo, una
descripción básica de cómo funcionan las migraciones y algunos enfoques sencillos para resolver los conflictos de
combinación facilitan la superación de estos desafíos.
El problema fundamental son los metadatos incorrectos almacenados en la última migración. Esto hace que Code
First detecte incorrectamente que el modelo actual y el esquema de la base de datos no coinciden y que se debe
aplicar scaffolding al código incorrecto en la siguiente migración. Esta situación se puede solucionar generando
una migración en blanco con el modelo correcto o actualizando los metadatos en la última migración.
Model First
Este vídeo y el tutorial paso a paso proporcionan una introducción al desarrollo de Model First mediante Entity
Framework. Model First permite crear un nuevo modelo mediante el Entity Framework Designer y, a continuación,
generar un esquema de base de datos a partir del modelo. El modelo se almacena en un archivo EDMX (extensión.
EDMX) y se puede ver y editar en el Entity Framework Designer. Las clases con las que interactúa en la aplicación
se generan automáticamente a partir del archivo EDMX.

Este vídeo y el tutorial paso a paso proporcionan una introducción al desarrollo de Model First mediante Entity
Framework. Model First permite crear un nuevo modelo mediante el Entity Framework Designer y, a continuación,
generar un esquema de base de datos a partir del modelo. El modelo se almacena en un archivo EDMX (extensión.
EDMX) y se puede ver y editar en el Entity Framework Designer. Las clases con las que interactúa en la aplicación
se generan automáticamente a partir del archivo EDMX.
Requisitos previos
Para completar este tutorial, deberá tener instalados Visual Studio 2010 o Visual Studio 2012.
Para simplificar las cosas, vamos a crear una aplicación de consola básica que use el Model First para realizar el
acceso a los datos:
Abra Visual Studio.
Escriba ModelFirstSample como nombre
2. crear modelo
modelo.
Escriba BloggingModel como nombre y haga clic en Aceptar . Esto iniciará el Asistente para Entity Data
Model
Seleccione modelo vacío y haga clic en Finalizar .
El Entity Framework Designer se abre con un modelo en blanco. Ahora podemos empezar a agregar entidades,
propiedades y asociaciones al modelo.
Haga clic con el botón derecho en la superficie de diseño y seleccione propiedades .
En el ventana Propiedades cambie el nombre del contenedor de entidades a BloggingContext este es
el nombre del contexto derivado que se generará automáticamente, el contexto representa una sesión con
la base de datos, lo que nos permite consultar y guardar datos .
Haga clic con el botón derecho en la superficie de diseño y seleccione Agregar nueva> entidad.. .
Escriba blog como el nombre de la entidad y BlogId como nombre de la clave y haga clic en Aceptar .
Haga clic con el botón derecho en la nueva entidad en la superficie de diseño y seleccione Agregar nueva-
> propiedad escalar , escriba el nombre de la propiedad.
Repita este proceso para agregar una propiedad de dirección URL .
Haga clic con el botón derecho en la propiedad dirección URL en la superficie de diseño y seleccione
propiedades , en el ventana Propiedades cambie la configuración que acepta valores NULL a true esto
nos permite guardar un blog en la base de datos sin asignarle una dirección URL .
Con las técnicas que acaba de aprender, agregue una entidad post con una propiedad de clave PostId
Agregar propiedades escalares de título y de contenido a la entidad post
Ahora que tenemos un par de entidades, es el momento de agregar una asociación (o relación) entre ellas.
Haga clic con el botón derecho en la superficie de diseño y seleccione Agregar nueva> asociación.. .
Haga que un extremo del punto de relación se envíe a un blog con una multiplicidad de uno y el otro
extremo para publicar con una multiplicidad de muchos Esto significa que un blog tiene muchas
publicaciones y una publicación pertenece a un blog .
Asegúrese de que el cuadro de la entidad agregar propiedades de clave externa al "post" está
activado y haga clic en Aceptar .
Ahora tenemos un modelo simple en el que se puede generar una base de datos y se usa para leer y escribir datos.

Si está trabajando en Visual Studio 2010, hay algunos pasos adicionales que debe seguir para actualizar a la
versión más reciente de Entity Framework. La actualización es importante porque le proporciona acceso a una
superficie de API mejorada, que es mucho más fácil de usar, así como las correcciones de errores más recientes.
En primer lugar, necesitamos obtener la versión más reciente de Entity Framework de NuGet.
Proyecto:> administrar paquetes NuGet... si no tiene la opción administrar paquetes Nuget... , debe
instalar la versión más reciente de Nuget .
A continuación, necesitamos cambiar nuestro modelo para generar código que haga uso de la API de DbContext,
que se presentó en versiones posteriores de Entity Framework.
Seleccione el generador de DbContext de EF 5. x para C# , escriba BloggingModel como nombre y
haga clic en Agregar .
3. generar la base de datos

Dado nuestro modelo, Entity Framework puede calcular un esquema de base de datos que nos permitirá
almacenar y recuperar datos mediante el modelo.
que haya instalado:
Haga clic con el botón secundario en la superficie de diseño y seleccione generar base de datos del
modelo.. .
Haga clic en nueva conexión.. . y especifique LocalDB o SQL Express, en función de la versión de Visual
Studio que use, escriba ModelFirst. blog como nombre de la base de datos.
Seleccione siguiente y el Entity Framework Designer calculará un script para crear el esquema de la base
de datos.
Una vez que se muestre el script, haga clic en Finalizar y el script se agregará al proyecto y se abrirá.
Haga clic con el botón derecho en el script y seleccione Ejecutar ; se le pedirá que especifique la base de
datos a la que se va a conectar, especifique LocalDB o SQL Server Express, en función de la versión de Visual
Studio que use.

Ahora que tenemos un modelo, es el momento de usarlo para tener acceso a algunos datos. Las clases que se van
a usar para obtener acceso a los datos se generan automáticamente basándose en el archivo EDMX.
Esta captura de pantalla es de Visual Studio 2012, si usa Visual Studio 2010, los archivos BloggingModel.tt y
BloggingModel.Context.tt estarán directamente en el proyecto en lugar de anidados en el archivo EDMX.
Implemente el método Main en Program.cs como se muestra a continuación. Este código crea una nueva instancia
de nuestro contexto y, a continuación, la usa para insertar un nuevo blog. A continuación, usa una consulta LINQ
para recuperar todos los blogs de la base de datos ordenados alfabéticamente por título.
class Program
{
{
{

db.Blogs.Add(blog);
db.SaveChanges();

orderby b.Name
select b;

{
}

Console.ReadKey();
}
}
}

ADO.NET Blog
5. tratar con cambios en el modelo
Ahora es el momento de realizar algunos cambios en nuestro modelo, cuando realizamos estos cambios también
necesitamos actualizar el esquema de la base de datos.
Comenzaremos agregando una nueva entidad de usuario a nuestro modelo.
Agregue un nuevo nombre de entidad de usuario con el nombre de usuario como el nombre de clave y la
cadena como el tipo de propiedad de la clave.
Haga clic con el botón derecho en la propiedad username en la superficie de diseño y seleccione
propiedades , en el ventana Propiedades cambie la configuración de MaxLength a 50 esto restringe los
datos que se pueden almacenar en el nombre de usuario a 50 caracteres .
Agregar una propiedad escalar displayName a la entidad User
Ahora tenemos un modelo actualizado y estamos preparados para actualizar la base de datos para dar cabida a
nuestro nuevo tipo de entidad de usuario.
Haga clic con el botón secundario en la superficie de diseño y seleccione generar base de datos a par tir del
modelo... , Entity Framework calculará un script para volver a crear un esquema basado en el modelo
actualizado.
Haga clic en Finish (Finalizar).
Puede recibir advertencias sobre cómo sobrescribir el script DDL existente y las partes de asignación y
almacenamiento del modelo; haga clic en sí para ambas advertencias.
El script SQL actualizado para crear la base de datos se abre automáticamente.
El script que se genera quitará todas las tablas existentes y, a continuación, volverá a crear el esquema desde el
principio. Esto puede funcionar para el desarrollo local, pero no es viable para insertar cambios en una base de
datos que ya se ha implementado. Si necesita publicar cambios en una base de datos que ya se ha
implementado, deberá editar el script o usar una herramienta de comparación de esquemas para calcular un
script de migración.
Haga clic con el botón derecho en el script y seleccione Ejecutar ; se le pedirá que especifique la base de datos
a la que se va a conectar, especifique LocalDB o SQL Server Express, en función de la versión de Visual Studio
que use.
Resumen
En este tutorial, hemos visto Model First desarrollo, que nos permitió crear un modelo en EF Designer y, a
continuación, generar una base de datos a partir de ese modelo. Después usamos el modelo para leer y escribir
algunos datos de la base de datos. Por último, hemos actualizado el modelo y, a continuación, hemos recreado el
esquema de la base de datos para que coincida con el modelo.
Database First
Este vídeo y el tutorial paso a paso proporcionan una introducción al desarrollo de Database First mediante Entity
Framework. Database First permite aplicar ingeniería inversa a un modelo a partir de una base de datos existente.
El modelo se almacena en un archivo EDMX (extensión. EDMX) y se puede ver y editar en el Entity Framework
Designer. Las clases con las que interactúa en la aplicación se generan automáticamente a partir del archivo
EDMX.

Este vídeo proporciona una introducción al desarrollo de Database First mediante Entity Framework. Database
First permite aplicar ingeniería inversa a un modelo a partir de una base de datos existente. El modelo se
almacena en un archivo EDMX (extensión. EDMX) y se puede ver y editar en el Entity Framework Designer. Las
clases con las que interactúa en la aplicación se generan automáticamente a partir del archivo EDMX.
Requisitos previos
1. crear una base de datos existente

que haya instalado:

Abra Visual Studio.
Conéctese a LocalDB o a SQL Express, en función de la que haya instalado y escriba DatabaseFirst. blog
como nombre de la base de datos.
La nueva base de datos aparecerá ahora en Explorador de servidores, haga clic con el botón derecho en ella
y seleccione nueva consulta .
);

CONSTRAINT [FK_dbo.Posts_dbo.Blogs_BlogId] FOREIGN KEY ([BlogId]) REFERENCES [dbo].[Blogs] ([BlogId]) ON
DELETE CASCADE
);
Para simplificar las cosas, vamos a crear una aplicación de consola básica que use el Database First para realizar el
acceso a los datos:
Abra Visual Studio.
Escriba DatabaseFirstSample como nombre
3. modelo de ingeniería inversa

modelo.
Escriba BloggingModel como nombre y haga clic en Aceptar .
Seleccione la conexión a la base de datos creada en la primera sección, escriba BloggingContext como
nombre de la cadena de conexión y haga clic en siguiente .
Haga clic en la casilla situada junto a "tablas" para importar todas las tablas y haga clic en "finalizar".
Una vez que se completa el proceso de ingeniería inversa, el nuevo modelo se agrega al proyecto y se abre para
que pueda verlo en el Entity Framework Designer. También se ha agregado un archivo app. config al proyecto con
los detalles de conexión de la base de datos.

Si está trabajando en Visual Studio 2010, hay algunos pasos adicionales que debe seguir para actualizar a la
versión más reciente de Entity Framework. La actualización es importante porque le proporciona acceso a una
superficie de API mejorada, que es mucho más fácil de usar, así como las correcciones de errores más recientes.
En primer lugar, necesitamos obtener la versión más reciente de Entity Framework de NuGet.
Proyecto:> administrar paquetes NuGet... si no tiene la opción administrar paquetes Nuget... , debe
instalar la versión más reciente de Nuget .
A continuación, necesitamos cambiar nuestro modelo para generar código que haga uso de la API de DbContext,
que se presentó en versiones posteriores de Entity Framework.
Seleccione el generador de DbContext de EF 5. x para C# , escriba BloggingModel como nombre y
haga clic en Agregar .

Ahora que tenemos un modelo, es el momento de usarlo para tener acceso a algunos datos. Las clases que se van
a usar para obtener acceso a los datos se generan automáticamente basándose en el archivo EDMX.
Esta captura de pantalla es de Visual Studio 2012, si usa Visual Studio 2010, los archivos BloggingModel.tt y
BloggingModel.Context.tt estarán directamente en el proyecto en lugar de anidados en el archivo EDMX.
Implemente el método Main en Program.cs como se muestra a continuación. Este código crea una nueva instancia
de nuestro contexto y, a continuación, la usa para insertar un nuevo blog. A continuación, usa una consulta LINQ
para recuperar todos los blogs de la base de datos ordenados alfabéticamente por título.
class Program
{
{
{

db.Blogs.Add(blog);
db.SaveChanges();

orderby b.Name
select b;

{
}

Console.ReadKey();
}
}
}

ADO.NET Blog
5. trabajar con cambios en la base de datos

Ahora es el momento de realizar algunos cambios en el esquema de la base de datos, cuando realizamos estos
cambios también necesitamos actualizar nuestro modelo para reflejar los cambios.
El primer paso consiste en realizar algunos cambios en el esquema de la base de datos. Vamos a agregar una
tabla de usuarios al esquema.
Haga clic con el botón derecho en la base de datos DatabaseFirst. blogs en explorador de servidores y
seleccione nueva consulta .
Copie el siguiente código SQL en la nueva consulta, haga clic con el botón derecho en la consulta y seleccione
Ejecutar .
CREATE TABLE [dbo].[Users]
(
[Username] NVARCHAR(50) NOT NULL PRIMARY KEY,
[DisplayName] NVARCHAR(MAX) NULL
)
Ahora que se ha actualizado el esquema, es el momento de actualizar el modelo con esos cambios.
Haga clic con el botón derecho en una zona vacía del modelo en el diseñador de EF y seleccione "actualizar
modelo desde base de datos". se iniciará el Asistente para actualización.
En la pestaña agregar del Asistente para actualización, active la casilla situada junto a tablas, lo que indica
que queremos agregar nuevas tablas del esquema. La pestaña actualizar muestra las tablas existentes en el
modelo en las que se comprobarán los cambios durante la actualización. Las pestañas eliminar muestran
las tablas que se han quitado del esquema y que también se quitarán del modelo como parte de la
actualización. La información de estas dos pestañas se detecta automáticamente y se proporciona solo con
fines informativos, no se puede cambiar la configuración.
Haga clic en finalizar en el Asistente para actualización
El modelo se ha actualizado para incluir una nueva entidad de usuario que se asigna a la tabla de usuarios que se
agregó a la base de datos.
Resumen
En este tutorial, hemos visto Database First desarrollo, que nos permitió crear un modelo en EF Designer basado
en una base de datos existente. Después usamos ese modelo para leer y escribir algunos datos de la base de
datos. Por último, se actualizó el modelo para reflejar los cambios realizados en el esquema de la base de datos.
Tipos complejos: EF Designer
En este tema se muestra cómo asignar tipos complejos con el Entity Framework Designer (EF Designer) y cómo
consultar entidades que contienen propiedades de tipo complejo.
En la imagen siguiente se muestran las ventanas principales que se usan al trabajar con el diseñador de EF.
NOTE
Al crear el modelo conceptual, es posible que aparezcan advertencias sobre entidades y asociaciones no asignadas en la Lista
de errores. Puede omitir estas advertencias porque, después de elegir generar la base de datos a partir del modelo, los
errores desaparecerán.
Qué es un tipo complejo

Los tipos complejos son propiedades no escalares de tipos de entidad que permiten organizar las propiedades
escalares dentro de las entidades. Al igual que las entidades, los tipos complejos están compuestos de propiedades
escalares u otras propiedades de tipo complejo.
Al trabajar con objetos que representan tipos complejos, tenga en cuenta lo siguiente:
Los tipos complejos no tienen claves y, por lo tanto, no pueden existir de forma independiente. Los tipos
complejos solo pueden existir como propiedades de tipos de entidad u otros tipos complejos.
Los tipos complejos no pueden participar en asociaciones y no pueden contener propiedades de navegación.
Las propiedades de tipo complejo no pueden ser null . Se produce una **excepción
InvalidOperationException **cuando se llama a DbContext. SaveChanges y se encuentra un objeto complejo
null. Las propiedades escalares de objetos complejos pueden ser null .
Los tipos complejos no pueden heredar de otros tipos complejos.
Debe definir el tipo complejo como una clase .
EF detecta los cambios en los miembros de un objeto de tipo complejo cuando se llama a DbContext.
DetectChanges . Entity Framework llama automáticamente a DetectChanges cuando se llama a los
siguientes miembros: DbSet. Find , DbSet. local , DbSet. Remove , DbSet. Add , DbSet. Attach , dbcontext.
SaveChanges , dbcontext. GetValidationErrors , dbcontext. entr y , DbChangeTracker. Entries .
Refactorizar las propiedades de una entidad en un nuevo tipo complejo

Si ya tiene una entidad en el modelo conceptual, puede que desee refactorizar algunas de las propiedades en una
propiedad de tipo complejo.
En la superficie del diseñador, seleccione una o varias propiedades (excepto las propiedades de navegación) de una
entidad, haga clic con el botón derecho y seleccione refactorizar-> moverse al nuevo tipo complejo .
Un nuevo tipo complejo con las propiedades seleccionadas se agrega al Explorador de modelos . Se asigna un
nombre predeterminado al tipo complejo.
Una propiedad compleja del tipo que se acaba de crear reemplaza las propiedades seleccionadas. Se conservan
todas las asignaciones de propiedades.
Crear un nuevo tipo complejo

También puede crear un nuevo tipo complejo que no contenga las propiedades de una entidad existente.
Haga clic con el botón secundario en la carpeta tipos complejos en el explorador de modelos,
seleccione AgregarNuevo tipo complejo. . Como alternativa, puede seleccionar la carpeta tipos complejos y
presionar la tecla Inser tar del teclado.
Un nuevo tipo complejo se agrega a la carpeta con un nombre predeterminado. Ahora puede Agregar propiedades
al tipo.
Agregar propiedades a un tipo complejo

Las propiedades de un tipo complejo pueden ser tipos escalares o los tipos complejos existentes. Sin embargo, las
propiedades de tipo complejo no pueden tener las referencias circulares. Por ejemplo, un tipo
complejo OnsiteCourseDetails no puede tener una propiedad de tipo complejo OnsiteCourseDetails .
Puede agregar una propiedad a un tipo complejo de cualquiera de las formas enumeradas a continuación.
Haga clic con el botón secundario en un tipo complejo en el explorador de modelos, seleccione Agregar y, a
continuación, seleccione propiedad escalar o propiedad compleja y, a continuación, seleccione el tipo de
propiedad que desee. Como alternativa, puede seleccionar un tipo complejo y, a continuación, presionar la
tecla inser tar del teclado.
Se agrega una nueva propiedad al tipo complejo con un nombre predeterminado.

O BIEN
Haga clic con el botón derecho en una propiedad de entidad en la superficie del Diseñador de EF y
seleccione copiar , a continuación, haga clic con el botón secundario en el tipo complejo en el Explorador
de modelos y seleccione pegar .
Cambiar el nombre de un tipo complejo

Al cambiar el nombre de un tipo complejo, todas las referencias al tipo se actualizan en el proyecto.
Haga doble clic lentamente en un tipo complejo en el Explorador de modelos . El nombre se seleccionará
y se abrirá en modo de edición.
O BIEN
Haga clic con el botón secundario en un tipo complejo en el Explorador de modelos y
seleccione cambiar nombre .
O BIEN
Seleccione un tipo complejo en el Explorador de modelos y presione la tecla F2.
O BIEN
Haga clic con el botón secundario en un tipo complejo en el Explorador de modelos y
seleccione propiedades . Edite el nombre en la ventana propiedades .
Agregar un tipo complejo existente a una entidad y asignar sus

propiedades a las columnas de la tabla
1. Haga clic con el botón secundario en una entidad, seleccione Agregar nuevo y seleccione propiedad
compleja . Se agrega a la entidad una propiedad de tipo complejo con un nombre predeterminado. Se
asigna un tipo predeterminado (que se elige entre los tipos complejos existentes) a la propiedad.
2. Asigne el tipo deseado a la propiedad en la ventana propiedades . Después de agregar una propiedad de
tipo complejo a una entidad, debe asignar sus propiedades a las columnas de una tabla.
3. Haga clic con el botón secundario en un tipo de entidad en la superficie de diseño o en el del Explorador
de modelos y seleccione asignaciones de tablas . Las asignaciones de tabla se muestran en la ventana
detalles de la asignación .
4. Expanda la <asignar a nombre de tabla> nodo. Aparece una asignación de columna nodo.
5. Expanda las asignaciones de columna nodo. Aparece una lista de todas las columnas de la tabla. Las
propiedades predeterminadas (si existen) a las que se asignan las columnas aparecen en el
encabezado valor/propiedad .
6. Seleccione la columna que desea asignar y, a continuación, haga clic con el botón secundario en el campo
de valor o propiedad correspondiente. Se muestra una lista desplegable de todas las propiedades
escalares.
7. Seleccione la propiedad apropiada.
8. Repita los pasos 6 y 7 para cada columna de tabla.

NOTE
Para eliminar una asignación de columna, seleccione la columna que desea asignar y, a continuación, haga clic en el
campo valor/propiedad . A continuación, seleccione eliminar en la lista desplegable.
Asignación de una importación de función a un tipo complejo

Las importaciones de función se basan en procedimientos almacenados. Para asignar una importación de función
a un tipo complejo, las columnas devueltas por el procedimiento almacenado correspondiente deben coincidir con
el número de propiedades del tipo complejo y deben tener tipos de almacenamiento compatibles con los tipos de
propiedad.
Haga doble clic en una función importada que desee asignar a un tipo complejo.
Rellene los valores para la nueva importación de función de la siguiente forma:

Especifique el procedimiento almacenado para el que va a crear una importación de función en el
campo nombre de procedimiento almacenado . El campo es una lista desplegable que muestra
todos los procedimientos almacenados del modelo de almacenamiento.
Especifique el nombre de la importación de función en el campo nombre de impor tación de
función .
Seleccione complejo como tipo de valor devuelto y, a continuación, especifique el tipo de valor
devuelto complejo específico eligiendo el tipo adecuado en la lista desplegable.
Haga clic en Aceptar . Se crea la entrada de importación de función en el modelo conceptual.
Personalizar la asignación de columnas para la importación de función
Haga clic con el botón derecho en la importación de función en el explorador de modelos y seleccione función
impor tar asignación . Aparece la ventana detalles de la asignación y muestra la asignación predeterminada
para la importación de función. Las flechas indican las asignaciones entre los valores de columna y de
propiedad. De forma predeterminada, se presupone que los nombres de columna son los mismos que los
nombres de propiedad del tipo complejo. Los nombres de columna predeterminados aparecen en texto gris.
Si es necesario, cambie los nombres de columna para que coincidan con los nombres de columna devueltos por
el procedimiento almacenado que corresponden a la importación de función.
Eliminar un tipo complejo

Al eliminar un tipo complejo, se elimina el tipo del modelo conceptual, así como las asignaciones para todas las
instancias del tipo. Sin embargo, no se actualizan las referencias al tipo. Por ejemplo, si una entidad tiene una
propiedad de tipo complejo de tipo ComplexType1 y ComplexType1 se elimina en el Explorador de modelos , no
se actualiza la propiedad de entidad correspondiente. El modelo no se validará porque contiene una entidad que
hace referencia a un tipo complejo eliminado. Puede actualizar o eliminar referencias a los tipos complejos
eliminados utilizando Entity Designer.
Haga clic con el botón secundario en un tipo complejo en el explorador de modelos y seleccione eliminar .
O BIEN
Seleccione un tipo complejo en el Explorador de modelos y presione la tecla Suprimir del teclado.
Consultar las entidades que contienen propiedades de tipo complejo

En el código siguiente se muestra cómo ejecutar una consulta que devuelve una colección de objetos de tipo
entidad que contienen una propiedad de tipo complejo.
using (SchoolEntities context = new SchoolEntities())

{
var courses =
from c in context.OnsiteCourses
order by c.Details.Time
select c;
foreach (var c in courses)

{
Console.WriteLine("Time: " + c.Details.Time);
Console.WriteLine("Days: " + c.Details.Days);
Console.WriteLine("Location: " + c.Details.Location);
}
}
Compatibilidad con la enumeración: EF Designer
NOTE
Este tutorial de vídeo y paso a paso muestra cómo utilizar tipos de enumeración con el Entity Framework Designer.
También se muestra cómo usar las enumeraciones en una consulta LINQ.
En este tutorial se utilizará Model First para crear una nueva base de datos, pero el diseñador de EF también puede
usarse con el flujo de trabajo de Database First para asignar a una base de datos existente.
La compatibilidad con la enumeración se presentó en Entity Framework 5. Para usar las nuevas características,
como las enumeraciones, los tipos de datos espaciales y las funciones con valores de tabla, debe tener como
En Entity Framework, una enumeración puede tener los siguientes tipos subyacentes: byte , Int16 , Int32 , Int64 o
SByte .
Ver el vídeo
En este vídeo se muestra cómo utilizar tipos de enumeración con el Entity Framework Designer. También se
muestra cómo usar las enumeraciones en una consulta LINQ.
Requisitos previos
este tutorial.
4. Escriba EnumEFDesigner como nombre del proyecto y haga clic en Aceptar .
Crear un nuevo modelo con EF Designer

1. Haga clic con el botón secundario en el nombre del proyecto en Explorador de soluciones, seleccione Agregar y,
a continuación, haga clic en nuevo elemento .
2. Seleccione datos en el menú de la izquierda y, a continuación, seleccione ADO.NET Entity Data Model en el
panel Plantillas.
3. Escriba EnumTestModel. edmx como nombre de archivo y, a continuación, haga clic en Agregar .
4. En la página del Asistente para Entity Data Model, seleccione modelo vacío en el cuadro de diálogo elegir
contenido del modelo.
5. Haga clic en Finish (Finalizar).
Se muestra el diseñador de entidades, que proporciona una superficie de diseño para editar el modelo.
El asistente realiza las siguientes acciones:
Genera el archivo EnumTestModel. edmx que define el modelo conceptual, el modelo de almacenamiento y la
asignación entre ellos. Establece la propiedad de procesamiento de artefactos de metadatos del archivo. edmx
que se va a incrustar en el ensamblado de salida para incrustar los archivos de metadatos generados en el
ensamblado.
Agrega una referencia a los siguientes ensamblados: EntityFramework, System. ComponentModel.
DataAnnotations y System. Data. Entity.
Crea archivos EnumTestModel.tt y EnumTestModel.Context.tt y los agrega en el archivo. edmx. Estos archivos de
plantilla T4 generan el código que define el tipo derivado de DbContext y los tipos POCO que se asignan a las
entidades en el modelo. edmx.
Agregar un nuevo tipo de entidad

1. Haga clic con el botón secundario en un área vacía de la superficie de diseño, seleccione agregar> entidad ,
aparecerá el cuadro de diálogo nueva entidad.
2. Especifique Depar tment como nombre de tipo y especifique depar tmentId como nombre de la propiedad de
clave y deje el tipo como Int32 .
3. Haga clic en Aceptar
4. Haga clic con el botón derecho en la entidad y seleccione Agregar nueva> propiedad escalar .
5. Cambiar el nombre de la nueva propiedad a nombre
6. Cambie el tipo de la nueva propiedad a Int32 (de forma predeterminada, la nueva propiedad es de tipo cadena)
para cambiar el tipo, abra el ventana Propiedades y cambie la propiedad Type a Int32 .
7. Agregue otra propiedad escalar y cambie su nombre a presupuesto , cambie el tipo a decimal .
Agregar un tipo de enumeración

1. En el Entity Framework Designer, haga clic con el botón secundario en la propiedad nombre, seleccione
conver tir en enumeración .
2. En el cuadro de diálogo Agregar enumeración , escriba Depar tmentNames para el nombre del tipo de
enumeración, cambie el tipo subyacente a Int32 y, a continuación, agregue los siguientes miembros al tipo:
Inglés, matemáticas y economía.
3. Presione Aceptar
4. Guardar el modelo y compilar el proyecto
NOTE
Al compilar, las advertencias sobre entidades y asociaciones no asignadas pueden aparecer en el Lista de errores.
Puede omitir estas advertencias porque, después de elegir generar la base de datos a partir del modelo, los errores
desaparecerán.
Si observa el ventana Propiedades, observará que el tipo de la propiedad Name se ha cambiado a

Depar tmentNames y que el tipo de enumeración recién agregado se ha agregado a la lista de tipos.
Si cambia a la ventana Explorador de modelos, verá que el tipo también se agregó al nodo tipos de enumeración.
NOTE
También puede agregar nuevos tipos de enumeración desde esta ventana haciendo clic con el botón secundario del mouse y
seleccionando Agregar tipo de enumeración . Una vez creado el tipo, aparecerá en la lista de tipos y podrá asociarlo a
una propiedad.
Generar base de datos a partir del modelo

Ahora se puede generar una base de datos basada en el modelo.
1. Haga clic con el botón secundario en un espacio vacío en la superficie de Entity Designer y seleccione generar
base de datos a par tir del modelo .
2. Aparece el cuadro de diálogo elegir la conexión de datos del Asistente para generar base de datos, haga clic en
el botón nueva conexión especifique (LocalDB)\mssqllocaldb para el nombre del servidor y EnumTest
para la base de datos y haga clic en Aceptar .
3. Aparecerá un cuadro de diálogo en el que se le pregunta si desea crear una nueva base de datos, haga clic en sí .
4. Haga clic en siguiente y el Asistente para crear bases de datos genera el lenguaje de definición de datos (DDL)
para crear una base de datos. la DDL generada se muestra en el cuadro de diálogo Resumen y configuración.
tenga en cuenta que el DDL no contiene una definición para una tabla que se asigna al tipo de enumeración
5. Haga clic en Finalizar al hacer clic en finalizar no se ejecuta el script DDL.
6. El Asistente para crear bases de datos hace lo siguiente: abre EnumTest. edmx. SQL en el editor de T-SQL
genera las secciones de asignación y esquema de almacenamiento del archivo edmx agrega información de la
cadena de conexión al archivo app. config.
7. Haga clic con el botón secundario del mouse en el editor de T-SQL y seleccione Ejecutar el cuadro de diálogo
conectar con el servidor, escriba la información de conexión del paso 2 y haga clic en conectar .
8. Para ver el esquema generado, haga clic con el botón derecho en el nombre de la base de datos en Explorador
de objetos de SQL Server y seleccione Actualizar .

Abra el archivo Program.cs en el que se define el método Main. Agregue el código siguiente a la función main. El
código agrega un nuevo objeto Department al contexto. Después guarda los datos. El código también ejecuta una
consulta LINQ que devuelve un departamento en el que el nombre es DepartmentNames. English.
using (var context = new EnumTestModelContainer())
{
context.Departments.Add(new Department{ Name = DepartmentNames.English });
var department = (from d in context.Departments

where d.Name == DepartmentNames.English
select d).FirstOrDefault();
Console.WriteLine(
"DepartmentID: {0} and Name: {1}",
department.DepartmentID,
department.Name);
}
DepartmentID: 1 Name: English
Para ver los datos de la base de datos, haga clic con el botón derecho en el nombre de la base de datos en
Explorador de objetos de SQL Server y seleccione Actualizar . A continuación, haga clic con el botón secundario
del mouse en la tabla y seleccione ver datos .
Resumen
En este tutorial, hemos visto cómo asignar tipos de enumeración mediante el Entity Framework Designer y cómo
usar las enumeraciones en el código.
Diseñador espacial-EF
NOTE
En el tutorial de vídeo y paso a paso se muestra cómo asignar tipos espaciales con el Entity Framework Designer.
También se muestra cómo usar una consulta LINQ para buscar una distancia entre dos ubicaciones.
En este tutorial se utilizará Model First para crear una nueva base de datos, pero el diseñador de EF también puede
usarse con el flujo de trabajo de Database First para asignar a una base de datos existente.
La compatibilidad con tipos espaciales se presentó en Entity Framework 5. Tenga en cuenta que para usar las
nuevas características, como el tipo espacial, las enumeraciones y las funciones con valores de tabla, debe tener
como destino .NET Framework 4,5. Visual Studio 2012 tiene como destino .NET 4,5 de forma predeterminada.
Para usar los tipos de datos espaciales, también debe usar un proveedor de Entity Framework que tenga
compatibilidad espacial. Consulte compatibilidad con proveedores para tipos espaciales para obtener más
información.
Hay dos tipos de datos espaciales principales: Geography y Geometry. El tipo de datos Geography almacena los
datos de datos elipsoidales (por ejemplo, las coordenadas de latitud y longitud de GPS). El tipo de datos Geometry
representa el sistema de coordenadas euclidiana (plano).

Este vídeo muestra cómo asignar tipos espaciales con el Entity Framework Designer. También se muestra cómo
usar una consulta LINQ para buscar una distancia entre dos ubicaciones.
Requisitos previos
este tutorial.
4. Escriba SpatialEFDesigner como nombre del proyecto y haga clic en Aceptar .
Crear un nuevo modelo con EF Designer

1. Haga clic con el botón secundario en el nombre del proyecto en Explorador de soluciones, seleccione
Agregar y, a continuación, haga clic en nuevo elemento .
panel Plantillas.
3. Escriba UniversityModel. edmx como nombre de archivo y, a continuación, haga clic en Agregar .
4. En la página del Asistente para Entity Data Model, seleccione modelo vacío en el cuadro de diálogo elegir
contenido del modelo.
5. Haga clic en Finish (Finalizar).
El asistente realiza las siguientes acciones:
Genera el archivo EnumTestModel. edmx que define el modelo conceptual, el modelo de almacenamiento y la
asignación entre ellos. Establece la propiedad de procesamiento de artefactos de metadatos del archivo. edmx
que se va a incrustar en el ensamblado de salida para incrustar los archivos de metadatos generados en el
ensamblado.
Agrega una referencia a los siguientes ensamblados: EntityFramework, System. ComponentModel.
DataAnnotations y System. Data. Entity.
Crea archivos UniversityModel.tt y UniversityModel.Context.tt y los agrega en el archivo. edmx. Estos archivos
de plantilla T4 generan el código que define el tipo derivado de DbContext y los tipos POCO que se asignan a
las entidades en el modelo. edmx.
Agregar un nuevo tipo de entidad

1. Haga clic con el botón secundario en un área vacía de la superficie de diseño, seleccione agregar> entidad ,
aparecerá el cuadro de diálogo nueva entidad.
2. Especifique Universidad como nombre de tipo y especifique UniversityID para el nombre de la propiedad de
clave y deje el tipo como Int32 .
3. Haga clic en Aceptar
4. Haga clic con el botón derecho en la entidad y seleccione Agregar nueva> propiedad escalar .
5. Cambiar el nombre de la nueva propiedad a nombre
6. Agregue otra propiedad escalar y cámbiela a Ubicación . abra el ventana Propiedades y cambie el tipo de la
nueva propiedad a geografía .
7. Guardar el modelo y compilar el proyecto
NOTE
Al compilar, las advertencias sobre entidades y asociaciones no asignadas pueden aparecer en el Lista de errores.
Puede omitir estas advertencias porque, después de elegir generar la base de datos a partir del modelo, los errores
desaparecerán.
Generar base de datos a partir del modelo

Ahora se puede generar una base de datos basada en el modelo.
1. Haga clic con el botón secundario en un espacio vacío en la superficie de Entity Designer y seleccione generar
base de datos a par tir del modelo .
2. Se muestra el cuadro de diálogo elegir la conexión de datos del Asistente para generar base de datos, haga clic
en el botón nueva conexión especifique (LocalDB)\mssqllocaldb para el nombre del servidor y la
Universidad para la base de datos y haga clic en Aceptar .
3. Aparecerá un cuadro de diálogo en el que se le pregunta si desea crear una nueva base de datos, haga clic en
sí .
4. Haga clic en siguiente y el Asistente para crear bases de datos genera el lenguaje de definición de datos (DDL)
para crear una base de datos. la DDL generada se muestra en el cuadro de diálogo Resumen y configuración.
tenga en cuenta que el DDL no contiene una definición para una tabla que se asigna al tipo de enumeración
5. Haga clic en Finalizar al hacer clic en finalizar no se ejecuta el script DDL.
6. El Asistente para crear bases de datos hace lo siguiente: abre UniversityModel. edmx. SQL en el editor de T-
SQL genera las secciones de asignación y esquema de almacenamiento del archivo edmx agrega información
de la cadena de conexión al archivo app. config.
7. Haga clic con el botón secundario del mouse en el editor de T-SQL y seleccione Ejecutar el cuadro de diálogo
conectar con el servidor, escriba la información de conexión del paso 2 y haga clic en conectar .
8. Para ver el esquema generado, haga clic con el botón derecho en el nombre de la base de datos en Explorador
de objetos de SQL Server y seleccione Actualizar .

Abra el archivo Program.cs en el que se define el método Main. Agregue el código siguiente a la función main.
El código agrega dos nuevos objetos universitarios al contexto. Las propiedades espaciales se inicializan mediante
el método DbGeography. FromText. El punto de geografía representado como WellKnownText se pasa al método.
Después, el código guarda los datos. A continuación, se crea y se ejecuta la consulta LINQ que devuelve un objeto
University donde su ubicación es más cercana a la ubicación especificada.
using (var context = new UniversityModelContainer())

{
{
Name = "Graphic Design Institute",
});
{
Name = "School of Fine Art",
});
var myLocation = DbGeography.FromText("POINT(-122.296623 47.640405)");
var university = (from u in context.Universities

orderby u.Location.Distance(myLocation)
select u).FirstOrDefault();
Console.WriteLine(
"The closest University to you is: {0}.",
university.Name);
}
The closest University to you is: School of Fine Art.
Para ver los datos de la base de datos, haga clic con el botón derecho en el nombre de la base de datos en
Explorador de objetos de SQL Server y seleccione Actualizar . A continuación, haga clic con el botón secundario
del mouse en la tabla y seleccione ver datos .
Resumen
En este tutorial, hemos visto cómo asignar tipos espaciales mediante el Entity Framework Designer y cómo usar
tipos espaciales en el código.
División de entidades del diseñador
En este tutorial se muestra cómo asignar un tipo de entidad a dos tablas modificando un modelo con el Entity
Framework Designer (EF Designer). Puede asignar una entidad a varias tablas cuando estas comparten una clave
común. Los conceptos que se aplican a la asignación de un tipo de entidad a dos tablas se amplían fácilmente para
asignar un tipo de entidad a más de dos tablas.
Prerequisites
Visual Studio 2012 o Visual Studio 2010, Ultimate, Premium, Professional o Web Express.
Crear la base de datos

que haya instalado:
Si usa Visual Studio 2012, va a crear una base de datos de LocalDB.
En primer lugar, vamos a crear una base de datos con dos tablas que se van a combinar en una sola entidad.
Abra Visual Studio.
Si no se ha conectado a una base de datos desde Explorador de servidores antes de que tenga que seleccionar
Microsoft SQL Ser ver como origen de datos
Escriba EntitySplitting como nombre de la base de datos
consulta .
Seleccionar datos-> el editor de TRANSACT SQL-> nueva consulta.. .
Escriba .\SQLEXPRESS como nombre del servidor y haga clic en Aceptar .
Seleccione la base de datos EntitySplitting en la lista desplegable de la parte superior del editor de
consultas.
CREATE TABLE [dbo].[Person] (

[PersonId] INT IDENTITY (1, 1) NOT NULL,
[FirstName] NVARCHAR (200) NULL,
[LastName] NVARCHAR (200) NULL,
CONSTRAINT [PK_Person] PRIMARY KEY CLUSTERED ([PersonId] ASC)
);
CREATE TABLE [dbo].[PersonInfo] (

[PersonId] INT NOT NULL,
[Email] NVARCHAR (200) NULL,
[Phone] NVARCHAR (50) NULL,
CONSTRAINT [PK_PersonInfo] PRIMARY KEY CLUSTERED ([PersonId] ASC),
CONSTRAINT [FK_Person_PersonInfo] FOREIGN KEY ([PersonId]) REFERENCES [dbo].[Person] ([PersonId]) ON DELETE
CASCADE
);
Creación del proyecto

En el menú Archivo , seleccione Nuevo y haga clic en Proyecto .
En el panel izquierdo, haga clic en Visual C# y, a continuación, seleccione la plantilla aplicación de consola .
Escriba MapEntityToTablesSample como nombre del proyecto y haga clic en Aceptar .
Haga clic en no si se le pide que guarde la consulta SQL creada en la primera sección.
Crear un modelo basado en la base de datos

Haga clic con el botón secundario en el nombre del proyecto en Explorador de soluciones, seleccione Agregar y,
Seleccione datos en el menú de la izquierda y, a continuación, seleccione ADO.NET Entity Data Model en el
panel Plantillas.
Escriba MapEntityToTablesModel. edmx como nombre de archivo y, a continuación, haga clic en Agregar .
En el cuadro de diálogo elegir contenido del modelo, seleccione generar desde la base de datos y, a
continuación, haga clic en siguiente.
Seleccione la conexión EntitySplitting en el menú desplegable y haga clic en siguiente .
En el cuadro de diálogo elija los objetos de base de datos, active la casilla situada junto al nodo tablas . Se
agregarán todas las tablas de la base de datos EntitySplitting al modelo.
Asignación de una entidad a dos tablas

En este paso, actualizaremos el tipo de entidad Person para combinar datos de las tablas Person y PersonInfo .
Seleccione las propiedades de correo electrónico y teléfono de la entidad **PersonInfo **y presione las
teclas Ctrl + X .
Seleccione la entidad **Person **y presione las teclas Ctrl + V .
En la superficie de diseño, seleccione la entidad PersonInfo y presione el botón eliminar del teclado.
Haga clic en no cuando se le pregunte si desea quitar la tabla PersonInfo del modelo, vamos a asignarla a
la entidad Person .
Los pasos siguientes requieren la ventana detalles de la asignación . Si no puede ver esta ventana, haga clic con el
botón secundario en la superficie de diseño y seleccione detalles de la asignación .
Seleccione la persona tipo de entidad y haga clic en <agregar una tabla o vista> en la ventana detalles de
la asignación .
Seleccione **PersonInfo ** de la lista desplegable. La ventana detalles de la asignación se actualiza con las
asignaciones de columnas predeterminadas, estas son correctas para nuestro escenario.
El tipo de entidad persona está asignado ahora a las tablas Person y PersonInfo .
Usar el modelo
Pegue el código siguiente en el método Main.
using (var context = new EntitySplittingEntities())
{
var person = new Person
{
FirstName = "John",
LastName = "Doe",
Email = "john@example.com",
Phone = "555-555-5555"
};
context.People.Add(person);
foreach (var item in context.People)

{
Console.WriteLine(item.FirstName);
}
}
Compile y ejecute la aplicación.

Las siguientes instrucciones T-SQL se ejecutaron en la base de datos como resultado de la ejecución de esta
aplicación.
Las dos instrucciones Inser t siguientes se ejecutaron como resultado de la ejecución del contexto.
SaveChanges (). Toman los datos de la entidad Person y los dividen entre las tablas Person y PersonInfo .
La siguiente selección se ejecutó como resultado de enumerar las personas en la base de datos. Combina
los datos de la tabla Person y PersonInfo .
División de tablas del diseñador
En este tutorial se muestra cómo asignar varios tipos de entidad a una sola tabla modificando un modelo con el
Entity Framework Designer (EF Designer).
Uno de los motivos por los que puede querer usar la división de tablas es retrasar la carga de algunas propiedades
al usar la carga diferida para cargar los objetos. Puede separar las propiedades que pueden contener una gran
cantidad de datos en una entidad independiente y solo cargarlos cuando sea necesario.
Prerequisites
Para completar este tutorial, necesitará:
Una versión reciente de Visual Studio.
La base de datos de ejemplo School.
En este tutorial se usa Visual Studio 2012.
Abra Visual Studio 2012.
En el panel izquierdo, haga clic en Visual C#y, a continuación, seleccione la plantilla aplicación de consola.
Escriba TableSplittingSample como nombre del proyecto y haga clic en Aceptar .
Creación de un modelo basado en la base de datos School

Haga clic con el botón secundario en el nombre del proyecto en Explorador de soluciones, seleccione Agregar y,
panel Plantillas.
Escriba TableSplittingModel. edmx como nombre de archivo y, a continuación, haga clic en Agregar .
continuación, haga clic en siguiente.
Haga clic en nueva conexión. En el cuadro de diálogo Propiedades de conexión, escriba el nombre del servidor
(por ejemplo, LocalDB)\mssqllocaldb ), seleccione el método de autenticación, escriba School para el
nombre de la base de datos y, a continuación, haga clic en Aceptar . El cuadro de diálogo elegir la conexión de
datos se actualiza con la configuración de conexión de la base de datos.
En el cuadro de diálogo elija los objetos de base de datos, desactive las tablas nodo y Compruebe la tabla
Person . Esto agregará la tabla especificada al modelo School .
Se muestra el diseñador de entidades, que proporciona una superficie de diseño para editar el modelo. Todos los
objetos que seleccionó en el cuadro de diálogo Elija los objetos de base de datos se agregan al modelo.
Asignación de dos entidades a una sola tabla

En esta sección dividirá la entidad Person en dos entidades y, a continuación, las asignará a una sola tabla.
NOTE
La entidad Person no contiene propiedades que puedan contener grandes cantidades de datos. simplemente se usa como
ejemplo.
Haga clic con el botón secundario en un área vacía de la superficie de diseño, seleccione Agregar nuevo y haga
clic en entidad . Aparecerá el cuadro de diálogo nuevo de entidades .
Escriba HireInfo para el nombre de entidad y PersonID para el nombre de la propiedad de clave .
Haga clic en Aceptar .
Se crea y se muestra un nuevo tipo de entidad en la superficie de diseño.
Seleccione la propiedad HireDate del tipo de entidad Person y presione las teclas Ctrl + X .
Seleccione la entidad HireInfo y presione las teclas Ctrl + V .
Cree una asociación entre Person y HireInfo . Para ello, haga clic con el botón secundario en un área vacía de la
superficie de diseño, seleccione Agregar nuevo y haga clic en Asociación .
Aparece el cuadro de diálogo Agregar de Asociación . El nombre de PersonHireInfo se proporciona de forma
predeterminada.
Especifique Multiplicity 1 (uno) en ambos extremos de la relación.
Presione Aceptar .
El paso siguiente requiere la ventana detalles de la asignación . Si no puede ver esta ventana, haga clic con el
botón secundario en la superficie de diseño y seleccione detalles de la asignación .
Seleccione el tipo de entidad HireInfo y haga clic en <agregar una tabla o vista> en la ventana detalles
de la asignación .
Seleccione persona en la lista desplegable <agregar una tabla o vista> campo . La lista contiene tablas
o vistas a las que se puede asignar la entidad seleccionada. Las propiedades adecuadas deben estar
asignadas de forma predeterminada.
Seleccione la Asociación PersonHireInfo en la superficie de diseño.
Haga clic con el botón secundario en la asociación en la superficie de diseño y seleccione propiedades .
En la ventana propiedades , seleccione la propiedad restricciones referenciales y haga clic en el botón
de puntos suspensivos.
Seleccione persona en la lista desplegable principal .
Presione Aceptar .
Usar el modelo
Pegue el código siguiente en el método Main.
using (var context = new SchoolEntities())

{
Person person = new Person()
{
FirstName = "Kimberly",
LastName = "Morgan",
Discriminator = "Instructor",
};
person.HireInfo = new HireInfo()

{
HireDate = DateTime.Now
};
// Add the new person to the context.

context.People.Add(person);
// Insert a row into the Person table.

// Execute a query against the Person table.

// The query returns columns that map to the Person entity.
var existingPerson = context.People.FirstOrDefault();
// Execute a query against the Person table.

// The query returns columns that map to the Instructor entity.
var hireInfo = existingPerson.HireInfo;
Console.WriteLine("{0} was hired on {1}",

existingPerson.LastName, hireInfo.HireDate);
}
Compile y ejecute la aplicación.

Las siguientes instrucciones T-SQL se ejecutaron en la base de datos School como resultado de la ejecución de
esta aplicación.
La siguiente inserción se ejecutó como resultado de la ejecución del contexto. SaveChanges () y combina
datos de las entidades Person y HireInfo
La siguiente selección se ejecutó como resultado de la ejecución del contexto. People. FirstOrDefault () y
selecciona solo las columnas asignadas a Person
La siguiente selección se ejecutó como resultado del acceso a la propiedad de navegación ExistingPerson.
instructor y selecciona solo las columnas asignadas a HireInfo
Herencia TPH del diseñador
En este tutorial paso a paso se muestra cómo implementar la herencia de tabla por jerarquía (TPH) en el modelo
conceptual con el Entity Framework Designer (EF Designer). La herencia TPH utiliza una tabla de base de datos
para mantener los datos de todos los tipos de entidad en una jerarquía de herencia.
En este tutorial asignaremos la tabla Person a tres tipos de entidad: person (el tipo base), Student (derive de
person) y instructor (derive de person). Vamos a crear un modelo conceptual a partir de la base de datos
(Database First) y, a continuación, modificar el modelo para implementar la herencia TPH mediante el diseñador de
EF.
Es posible asignar una herencia TPH mediante Model First pero tendría que escribir su propio flujo de trabajo de
generación de base de datos, que es complejo. A continuación, asignaría este flujo de trabajo a la propiedad flujo
de trabajo de generación de base de datos en el diseñador de EF. Una alternativa más sencilla es usar Code
First.
Otras opciones de herencia

Tabla por tipo (TPT) es otro tipo de herencia en la que las tablas independientes de la base de datos se asignan a
las entidades que participan en la herencia. Para obtener información sobre cómo asignar la herencia de tabla por
tipo con el diseñador de EF, consulte herencia del diseñador de EF.
El tiempo de ejecución de Entity Framework admite la herencia de tipo de tabla por hormigón (TPC) y los modelos
de herencia mixto, pero no son compatibles con el diseñador de EF. Si desea utilizar la herencia de TPC o mixta,
tiene dos opciones: usar Code First o editar manualmente el archivo EDMX. Si decide trabajar con el archivo
EDMX, la ventana detalles de la asignación se colocará en "modo seguro" y no podrá usar el diseñador para
cambiar las asignaciones.
Prerequisites
Seleccionar archivo-> nuevo-> proyecto
En el panel izquierdo, haga clic en Visual C# y, a continuación, seleccione la plantilla de consola .
Escriba TPHDBFirstSample como nombre.
Haga clic con el botón derecho en el nombre del proyecto en Explorador de soluciones y seleccione agregar>
nuevo elemento .
panel Plantillas.
Escriba TPHModel. edmx como nombre de archivo y, a continuación, haga clic en Agregar .
continuación, haga clic en siguiente .
Haga clic en nueva conexión . En el cuadro de diálogo Propiedades de conexión, escriba el nombre del
servidor (por ejemplo, LocalDB)\mssqllocaldb ), seleccione el método de autenticación, escriba School para
el nombre de la base de datos y, a continuación, haga clic en Aceptar . El cuadro de diálogo elegir la conexión
de datos se actualiza con la configuración de conexión de la base de datos.
En el cuadro de diálogo elija los objetos de base de datos, en el nodo tablas, seleccione la tabla Person .
objetos que seleccionó en el cuadro de diálogo elija los objetos de base de datos se agregan al modelo.
Este es el aspecto de la tabla Person en la base de datos.
Implementar la herencia de tabla por jerarquía

La tabla Person tiene la columna Discriminator , que puede tener uno de dos valores: "Student" y "instructor". En
función del valor, la tabla Person se asignará a la entidad Student o a la entidad instructor . La tabla Person
también tiene dos columnas, HireDate y EnrollmentDate , que deben admitir valores NULL porque una
persona no puede ser Student ni un instructor al mismo tiempo (al menos no en este tutorial).
Agregar nuevas entidades
Agregue una nueva entidad. Para ello, haga clic con el botón secundario en un espacio vacío de la superficie de
diseño del Entity Framework Designer y seleccione agregar>entidad .
Escriba Instructor para el nombre de entidad y seleccione Person en la lista desplegable del tipo base .
Agregue otra entidad nueva. Escriba Student para el nombre de entidad y seleccione Person en la lista
desplegable del tipo base .
Se han agregado dos nuevos tipos de entidad a la superficie de diseño. Una flecha señala desde los nuevos tipos
de entidad hasta la persona tipo de entidad; Esto indica que Person es el tipo base para los nuevos tipos de
entidad.
Haga clic con el botón secundario en la propiedad HireDate de la entidad Person . Seleccione cor tar (o use la
tecla Ctrl-X).
Haga clic con el botón secundario en la entidad del instructor y seleccione pegar (o use la tecla Ctrl-V).
Haga clic con el botón secundario en la propiedad HireDate y seleccione propiedades .
En la ventana propiedades , establezca la propiedad Nullable en false .
Haga clic con el botón secundario en la propiedad EnrollmentDate de la entidad Person . Seleccione cor tar
(o use la tecla Ctrl-X).
Haga clic con el botón secundario en la entidad Student y seleccione pegar (o use la tecla Ctrl-V).
Seleccione la propiedad EnrollmentDate y establezca la propiedad Nullable en false .
Seleccione la persona tipo de entidad. En la ventana propiedades , establezca su propiedad abstract en true .
Elimine la propiedad Discriminator de Person . La razón por la que se debe eliminar se explica en la sección
siguiente.
Asignación de las entidades
Haga clic con el botón secundario en el instructor y seleccione asignación de tabla. La entidad instructor
está seleccionada en la ventana detalles de la asignación.
Haga clic en <agregar una tabla o vista> en la ventana detalles de la asignación . El <agregar una
tabla o vista> campo se convierte en una lista desplegable de tablas o vistas a las que se puede asignar la
entidad seleccionada.
Seleccione Person en la lista desplegable.
La ventana detalles de la asignación se actualiza con las asignaciones de columnas predeterminadas y una
opción para agregar una condición.
Haga clic en <agregar una condición> . El <agregar una condición> campo se convierte en una lista
desplegable de columnas para las que se pueden establecer condiciones.
Seleccione discriminator en la lista desplegable.
En la columna operador de la ventana detalles de la asignación , seleccione = en la lista desplegable.
En la columna valor/propiedad , escriba instructor . El resultado final debería ser similar al siguiente:
Repita estos pasos para el tipo de entidad student , pero haga que la condición sea igual que el valor
Student .
La razón por la que queríamos quitar la propiedad Discriminator , es que no se puede asignar más de una
vez una columna de tabla. Esta columna se utilizará para la asignación condicional, por lo que no se puede
usar también para la asignación de propiedades. La única manera en que se puede usar para ambos, si una
condición usa es null o no es null comparación.
Ahora se implementa la herencia de tabla por jerarquía.
Usar el modelo
Abra el archivo Program.CS en el que se define el método Main . Pegue el código siguiente en la función Main .
El código ejecuta tres consultas. La primera consulta devuelve todos los objetos Person . La segunda consulta
utiliza el método Intype para devolver los objetos instructor . La tercera consulta utiliza el método Intype para
devolver objetos Student .

{
Console.WriteLine("All people:");
foreach (var person in context.People)
{
Console.WriteLine(" {0} {1}", person.FirstName, person.LastName);
}
Console.WriteLine("Instructors only: ");

foreach (var person in context.People.OfType<Instructor>())
{
}
Console.WriteLine("Students only: ");

foreach (var person in context.People.OfType<Student>())
{
}
}
Herencia de diseñador TPT
En este tutorial paso a paso se muestra cómo implementar la herencia de tabla por tipo (TPT) en el modelo
mediante el Entity Framework Designer (EF Designer). La herencia de tabla por tipo utiliza una tabla independiente
de la base de datos para mantener los datos de las propiedades no heredadas y de las propiedades de clave para
cada tipo de la jerarquía de herencia.
En este tutorial, asignaremos las entidades Course (tipo base), OnlineCourse (se deriva de course)
y OnsiteCourse (se deriva de Course ) a tablas con los mismos nombres. Vamos a crear un modelo a partir de la
base de datos y, a continuación, modificaremos el modelo para implementar la herencia de TPT.
También puede empezar con el Model First y, a continuación, generar la base de datos a partir del modelo. El
diseñador de EF usa la estrategia TPT de forma predeterminada, por lo que cualquier herencia del modelo se
asignará a tablas independientes.
Otras opciones de herencia

Tabla por jerarquía (TPH) es otro tipo de herencia en la que se utiliza una tabla de base de datos para mantener los
datos de todos los tipos de entidad en una jerarquía de herencia. Para obtener información sobre cómo asignar la
herencia de tabla por jerarquía con Entity Designer, vea la herencia TPH del diseñador de EF.
Tenga en cuenta que, la herencia de tipos por hormigón (TPC) y los modelos de herencia mixtos son compatibles
con el tiempo de ejecución de Entity Framework pero no son compatibles con el diseñador de EF. Si desea utilizar
la herencia de TPC o mixta, tiene dos opciones: usar Code First o editar manualmente el archivo EDMX. Si decide
trabajar con el archivo EDMX, la ventana detalles de la asignación se colocará en "modo seguro" y no podrá usar el
diseñador para cambiar las asignaciones.
Prerequisites
Escriba TPTDBFirstSample como nombre.
Haga clic con el botón derecho en el proyecto en Explorador de soluciones y seleccione agregar> nuevo
elemento .
panel Plantillas.
Escriba TPTModel. edmx como nombre de archivo y, a continuación, haga clic en Agregar .
En el cuadro de diálogo elegir contenido del modelo, seleccione ** generar desde la base de datosy, a
servidor (por ejemplo, LocalDB)\mssqllocaldb ), seleccione el método de autenticación, escriba School para
el nombre de la base de datos y, a continuación, haga clic en Aceptar . El cuadro de diálogo elegir la conexión
de datos se actualiza con la configuración de conexión de la base de datos.
En el cuadro de diálogo elija los objetos de base de datos, en el nodo tablas, seleccione las tablas Depar tment ,
Course, OnlineCourse y OnsiteCourse .
objetos que seleccionó en el cuadro de diálogo elija los objetos de base de datos se agregan al modelo.
Implementar la herencia de tabla por tipo

En la superficie de diseño, haga clic con el botón secundario en el tipo de entidad OnlineCourse y seleccione
propiedades .
En la ventana propiedades , establezca la propiedad tipo base en Course .
Haga clic con el botón secundario en el tipo de entidad OnsiteCourse y seleccione propiedades .
En la ventana propiedades , establezca la propiedad tipo base en Course .
Haga clic con el botón secundario en la Asociación (la línea) entre los tipos de entidad OnlineCourse y
Course . Seleccione eliminar del modelo .
Haga clic con el botón secundario en la asociación entre los tipos de entidad OnsiteCourse y Course .
Seleccione eliminar del modelo .
Ahora eliminaremos la propiedad CourseID de OnlineCourse y OnsiteCourse , ya que estas clases heredan
courseid del tipo base Course .
Haga clic con el botón secundario en la propiedad CourseID del tipo de entidad OnlineCourse y, a
continuación, seleccione eliminar del modelo .
Haga clic con el botón secundario en la propiedad CourseID del tipo de entidad OnsiteCourse y, a
continuación, seleccione eliminar del modelo .
Ya está implementada la herencia de tabla por tipo.
Usar el modelo
Abra el archivo Program.CS en el que se define el método Main . Pegue el código siguiente en la función Main .
El código ejecuta tres consultas. La primera consulta devuelve todos los cursos relacionados con el Departamento
especificado. La segunda consulta utiliza el método Intype para devolver OnlineCourses relacionado con el
Departamento especificado. La tercera consulta devuelve OnsiteCourses .
{
foreach (var department in context.Departments)
{
Console.WriteLine("The {0} department has the following courses:",
department.Name);
Console.WriteLine(" All courses");

foreach (var course in department.Courses )
{
Console.WriteLine(" {0}", course.Title);
}
foreach (var course in department.Courses.

OfType<OnlineCourse>())
{
Console.WriteLine(" Online - {0}", course.Title);
}
foreach (var course in department.Courses.

OfType<OnsiteCourse>())
{
Console.WriteLine(" Onsite - {0}", course.Title);
}
}
}
Procedimientos almacenados de consulta del
diseñador
En este tutorial paso a paso se muestra cómo usar el Entity Framework Designer (EF Designer) para importar
procedimientos almacenados en un modelo y, a continuación, llamar a los procedimientos almacenados
importados para recuperar los resultados.
Tenga en cuenta que Code First no admite la asignación a funciones o procedimientos almacenados. Sin embargo,
puede llamar a procedimientos almacenados o funciones mediante el método System. Data. Entity. DbSet.
SqlQuery. Por ejemplo:
var query = context.Products.SqlQuery("EXECUTE [dbo].[GetAllProducts]")`;
Prerequisites
Escriba EFwithSProcsSample como nombre.
Haga clic con el botón derecho en el proyecto en Explorador de soluciones y seleccione agregar> nuevo
elemento .
Seleccione datos en el menú de la izquierda y, a continuación, seleccione ADO.NET Entity Data Model en
el panel Plantillas.
Escriba EFwithSProcsModel. edmx como nombre de archivo y, a continuación, haga clic en Agregar .
Haga clic en nueva conexión .
En el cuadro de diálogo Propiedades de conexión, escriba el nombre del servidor (por ejemplo,
LocalDB)\mssqllocaldb ), seleccione el método de autenticación, escriba School para el nombre de la
base de datos y, a continuación, haga clic en Aceptar .
El cuadro de diálogo elegir la conexión de datos se actualiza con la configuración de conexión de la base de
datos.
En el cuadro de diálogo elija los objetos de base de datos, active la casilla de tablas para seleccionar todas
las tablas.
Además, seleccione los siguientes procedimientos almacenados en el nodo procedimientos
almacenados y funciones : GetStudentGrades y GetDepar tmentName .
A partir de Visual Studio 2012, el diseñador de EF admite la importación masiva de procedimientos

almacenados. La impor tación de funciones y procedimientos almacenados seleccionados en el
modelo de entidad está activada de forma predeterminada.
De forma predeterminada, la forma de resultado de cada procedimiento almacenado importado o función que
devuelve más de una columna se convierte automáticamente en un nuevo tipo complejo. En este ejemplo,
queremos asignar los resultados de la función GetStudentGrades a la entidad StudentGrade y los resultados
de GetDepar tmentName a None (ninguno es el valor predeterminado).
Para que una importación de función devuelva un tipo de entidad, las columnas devueltas por el procedimiento
almacenado correspondiente deben coincidir exactamente con las propiedades escalares del tipo de entidad
devuelto. Una importación de función también puede devolver colecciones de tipos simples, tipos complejos o
ningún valor.
Haga clic con el botón secundario en la superficie de diseño y seleccione Explorador de modelos .
En el Explorador de modelos , seleccione impor taciones de función y, a continuación, haga doble clic en la
función GetStudentGrades .
En el cuadro de diálogo Editar importación de función, seleccione entidades y elija StudentGrade .
La casilla impor tación de función con composición en la parte superior del cuadro de diálogo de
impor taciones de funciones le permitirá asignar funciones que admiten composición. Si activa esta casilla,
solo aparecerán las funciones que admiten composición (funciones con valores de tabla) en la lista desplegable
procedimiento almacenado o nombre de función . Si no activa esta casilla, solo se mostrarán en la lista
las funciones que no admiten composición.
Usar el modelo
Abra el archivo Program.CS en el que se define el método Main . Agregue el código siguiente a la función main.
El código llama a dos procedimientos almacenados: GetStudentGrades (devuelve StudentGrades para el
StudentIdespecificado) y GetDepar tmentName (devuelve el nombre del Departamento en el parámetro de
salida).
using (SchoolEntities context = new SchoolEntities())

{
// Specify the Student ID.
int studentId = 2;
// Call GetStudentGrades and iterate through the returned collection.

foreach (StudentGrade grade in context.GetStudentGrades(studentId))
{
Console.WriteLine("StudentID: {0}\tSubject={1}", studentId, grade.Subject);
Console.WriteLine("Student grade: " + grade.Grade);
}
// Call GetDepartmentName.
// Declare the name variable that will contain the value returned by the output parameter.
ObjectParameter name = new ObjectParameter("Name", typeof(String));
context.GetDepartmentName(1, name);
Console.WriteLine("The department name is {0}", name.Value);
StudentID: 2
Student grade: 4.00
StudentID: 2
Student grade: 3.50
The department name is Engineering
Parámetros de salida
Si se utilizan parámetros de salida, sus valores no estarán disponibles hasta que los resultados se hayan leído por
completo. Esto se debe al comportamiento subyacente de DbDataReader, consulte recuperación de datos mediante
un DataReader para obtener más detalles.
Procedimientos almacenados CUD del diseñador
Este tutorial paso a paso muestra cómo asignar las operaciones de creación\inserción, actualización y eliminación
(CUD) de un tipo de entidad a procedimientos almacenados mediante el Entity Framework Designer (EF Designer).
De forma predeterminada, el Entity Framework genera automáticamente las instrucciones SQL para las
operaciones CUD, pero también puede asignar procedimientos almacenados a estas operaciones.
Tenga en cuenta que Code First no admite la asignación a funciones o procedimientos almacenados. Sin embargo,
puede llamar a procedimientos almacenados o funciones mediante el método System. Data. Entity. DbSet.
SqlQuery. Por ejemplo:
var query = context.Products.SqlQuery("EXECUTE [dbo].[GetAllProducts]");
Consideraciones al asignar las operaciones CUD a procedimientos

almacenados
Al asignar las operaciones CUD a los procedimientos almacenados, se aplican las consideraciones siguientes:
Si va a asignar una de las operaciones de CUD a un procedimiento almacenado, asígnela todas. Si no asigna los
tres, se producirá un error en las operaciones no asignadas si se ejecutan y se producirá
una UpdateException .
Debe asignar todos los parámetros del procedimiento almacenado a las propiedades de la entidad.
Si el servidor genera el valor de clave principal para la fila insertada, debe volver a asignar este valor a la
propiedad clave de la entidad. En el ejemplo siguiente, el procedimiento almacenado Inser tPerson devuelve la
clave principal recién creada como parte del conjunto de resultados del procedimiento almacenado. La clave
principal se asigna a la clave de entidad (PersonID ) mediante el <agregar enlaces de resultados>
característica del diseñador de EF.
Las llamadas a procedimientos almacenados se asignan 1:1 con las entidades del modelo conceptual. Por
ejemplo, si implementa una jerarquía de herencia en el modelo conceptual y, a continuación, asigna los
procedimientos almacenados CUD para las entidades primaria (base) y secundaria (derivada), al guardar los
cambios secundarios solo se llamará a los procedimientos almacenados del elemento secundario , no se
desencadenarán las llamadas a procedimientos almacenados del elemento primario .
Prerequisites
Escriba CUDSProcsSample como nombre.
Haga clic con el botón derecho en el nombre del proyecto en Explorador de soluciones y seleccione
agregar> nuevo elemento .
Escriba CUDSProcs. edmx como nombre de archivo y, a continuación, haga clic en Agregar .
servidor (por ejemplo, LocalDB)\mssqllocaldb ), seleccione el método de autenticación,
escriba School para el nombre de la base de datos y, a continuación, haga clic en Aceptar . El cuadro de
diálogo elegir la conexión de datos se actualiza con la configuración de conexión de la base de datos.
En el cuadro de diálogo elija los objetos de base de datos, en el nodo tablas , seleccione la tabla Person .
Además, seleccione los siguientes procedimientos almacenados en el nodo procedimientos
almacenados y funciones : DeletePerson , Inser tPerson y UpdatePerson .
A partir de Visual Studio 2012, el diseñador de EF admite la importación masiva de procedimientos
almacenados. La impor tación de funciones y procedimientos almacenados seleccionados en el
modelo de entidad está activada de forma predeterminada. Como en este ejemplo tenemos
procedimientos almacenados que insertan, actualizan y eliminan tipos de entidad, no queremos
importarlos y desactivarán esta casilla.
Haga clic en Finalizar . Se muestra el diseñador de EF, que proporciona una superficie de diseño para editar
el modelo.
Asignar la entidad Person a procedimientos almacenados

Haga clic con el botón secundario en la persona tipo de entidad y seleccione asignación de
procedimiento almacenado .
Las asignaciones de procedimientos almacenados aparecen en la ventana detalles de la asignación .
Haga clic en <seleccionar Inser tar función> . El campo se convierte en una lista desplegable de los
procedimientos almacenados del modelo de almacenamiento que se puede asignar a tipos de entidad del
modelo conceptual. Seleccione Inser tPerson de la lista desplegable.
Aparecen las asignaciones predeterminadas entre los parámetros de procedimiento almacenado y las
propiedades de entidad. Observe que las flechas indican la dirección de la asignación: se proporcionan
valores de propiedad como parámetros de procedimiento almacenado.
Haga clic en **<agregar>de enlace de resultados **.
Escriba NewPersonID , el nombre del parámetro devuelto por el procedimiento
almacenado Inser tPerson . Asegúrese de no escribir espacios iniciales ni finales.
Presione entrar .
De forma predeterminada, NewPersonID se asigna a la clave de entidad PersonID . Observe que una
flecha indica la dirección de la asignación: el valor de la columna de resultado se proporciona para la
propiedad.
Haga clic en <seleccione Actualizar función> y seleccione UpdatePerson en la lista desplegable

resultante.
propiedades de entidad.
Haga clic en <seleccionar eliminar función> y seleccione DeletePerson en la lista desplegable
resultante.
propiedades de entidad.
Las operaciones de inserción, actualización y eliminación de la persona tipo de entidad ahora están asignadas a
procedimientos almacenados.
Si desea habilitar la comprobación de simultaneidad al actualizar o eliminar una entidad con procedimientos
almacenados, use una de las siguientes opciones:
Use un parámetro de salida para devolver el número de filas afectadas del procedimiento almacenado y active
las casillas de los parámetros afectados de las filas junto al nombre del parámetro. Si el valor devuelto es
cero cuando se llama a la operación, se producirá una OptimisticConcurrencyException .
Active la casilla usar valor original junto a una propiedad que quiera usar para la comprobación de
simultaneidad. Cuando se intenta realizar una actualización, se usará el valor de la propiedad que se leyó
originalmente de la base de datos al escribir datos de nuevo en la base de datos. Si el valor no coincide con el
valor de la base de datos, se producirá una OptimisticConcurrencyException .
Usar el modelo
Abra el archivo Program.CS en el que se define el método Main . Agregue el código siguiente a la función main.
El código crea un nuevo objeto Person y, a continuación, actualiza el objeto y, por último, elimina el objeto.

{
var newInstructor = new Person
{
FirstName = "Robyn",
LastName = "Martin",
HireDate = DateTime.Now,
Discriminator = "Instructor"
}
// Add the new object to the context.

context.People.Add(newInstructor);
Console.WriteLine("Added {0} {1} to the context.",

newInstructor.FirstName, newInstructor.LastName);
Console.WriteLine("Before SaveChanges, the PersonID is: {0}",

newInstructor.PersonID);
// SaveChanges will call the InsertPerson sproc.

// The PersonID property will be assigned the value
// returned by the sproc.
Console.WriteLine("After SaveChanges, the PersonID is: {0}",

// Modify the object and call SaveChanges.

// This time, the UpdatePerson will be called.
newInstructor.FirstName = "Rachel";
// Remove the object from the context and call SaveChanges.

// The DeletePerson sproc will be called.
context.People.Remove(newInstructor);
Person deletedInstructor = context.People.

Where(p => p.PersonID == newInstructor.PersonID).
FirstOrDefault();
if (deletedInstructor == null)
Console.WriteLine("A person with PersonID {0} was deleted.",
}
Compile y ejecute la aplicación. El programa genera el siguiente resultado *
NOTE
El servidor genera automáticamente PersonID, por lo que probablemente verá un número diferente *
Added Robyn Martin to the context.

Before SaveChanges, the PersonID is: 0
After SaveChanges, the PersonID is: 51
A person with PersonID 51 was deleted.
Si está trabajando con la versión Ultimate de Visual Studio, puede usar IntelliTrace con el depurador para ver las
instrucciones SQL que se ejecutan.
Relaciones: EF Designer
NOTE
En esta página se proporciona información sobre cómo configurar las relaciones en el modelo mediante el diseñador de EF.
Para obtener información general sobre las relaciones en EF y cómo obtener acceso a los datos y manipularlos mediante
relaciones, vea relaciones & propiedades de navegación.
Las asociaciones definen las relaciones entre los tipos de entidad de un modelo. En este tema se muestra cómo
asignar asociaciones con el Entity Framework Designer (EF Designer). En la imagen siguiente se muestran las
ventanas principales que se usan al trabajar con el diseñador de EF.
NOTE
Al crear el modelo conceptual, es posible que aparezcan advertencias sobre entidades y asociaciones no asignadas en la Lista
de errores. Puede omitir estas advertencias porque, después de elegir generar la base de datos a partir del modelo, los
errores desaparecerán.
Información general sobre asociaciones

Al diseñar el modelo mediante el diseñador de EF, un archivo. edmx representa el modelo. En el archivo. edmx, un
elemento Association define una relación entre dos tipos de entidad. Una asociación debe especificar los tipos de
entidad que están implicados en la relación y el posible número de tipos de entidad en cada extremo de la
relación, que se conoce como multiplicidad. La multiplicidad de un extremo de asociación puede tener un valor de
uno (1), cero o uno (0. 1) o varios (*). Esta información se especifica en dos elementos End secundarios.
En tiempo de ejecución, se puede tener acceso a las instancias de tipo de entidad en un extremo de una asociación
a través de las propiedades de navegación o las claves externas (si elige exponer las claves externas en las
entidades). Con las claves externas expuestas, la relación entre las entidades se administra con un elemento
ReferentialConstraint (un elemento secundario del elemento Association ). Se recomienda exponer siempre
las claves externas para las relaciones de las entidades.
NOTE
En varios a varios (*:*) no se pueden agregar claves externas a las entidades. En una relación de *:*, la información de
asociación se administra con un objeto independiente.
Para obtener información sobre los elementos CSDL (ReferentialConstraint , Association , etc.), vea la
especificación de CSDL.
Crear y eliminar asociaciones

La creación de una asociación con el diseñador de EF actualiza el contenido del modelo del archivo. edmx. Después
de crear una asociación, debe crear las asignaciones para la Asociación (que se describen más adelante en este
tema).
NOTE
En esta sección se supone que ya ha agregado las entidades con las que desea crear una asociación entre el modelo.
Para crear una asociación

1. Haga clic con el botón secundario en un área vacía de la superficie de diseño, seleccione Agregar nuevo y
seleccione asociación. .
2. Rellene la configuración de la asociación en el cuadro de diálogo Agregar Asociación .
NOTE
Puede optar por no agregar propiedades de navegación ni propiedades de clave externa a las entidades en los
extremos de la asociación si desactiva la **propiedad de navegación **y **agrega propiedades de clave externa al
<nombre de tipo de entidad> **las casillas de entidad. Si agrega solo una propiedad de navegación, la asociación se
podrá recorrer en una única dirección. Si no agrega ninguna propiedad de navegación, deberá agregar propiedades
de clave externa para poder tener acceso a las entidades situadas en los extremos de la asociación.
3. Haga clic en Aceptar .

Para eliminar una asociación
Para eliminar una asociación, realice una de las acciones siguientes:
Haga clic con el botón derecho en la asociación en la superficie del diseñador EF y seleccione eliminar .
O BIEN
Seleccione una o más asociaciones y presione la tecla Supr.
Incluir propiedades de clave externa en las entidades (restricciones

referenciales)
Se recomienda exponer siempre las claves externas para las relaciones de las entidades. Entity Framework usa una
restricción referencial para identificar que una propiedad actúa como clave externa de una relación.
Si activó la casilla Agregar propiedades de clave externa al <nombre de tipo de entidad> entidad al
crear una relación, esta restricción referencial se agregó automáticamente.
Cuando se usa EF Designer para agregar o editar una restricción referencial, el diseñador de EF agrega o modifica
un elemento de ReferentialConstraint en el contenido CSDL del archivo. edmx.
Haga doble clic en la asociación que desee editar. Aparecerá el cuadro de diálogo de restricción
referencial .
En la lista desplegable principal , seleccione la entidad de entidad de seguridad en la restricción referencial.
Las propiedades de clave de la entidad se agregan a la lista de de la clave principal en el cuadro de
diálogo.
En la lista desplegable dependiente , seleccione la entidad dependiente en la restricción referencial.
Para cada clave principal que tenga una clave dependiente, seleccione una clave dependiente
correspondiente en las listas desplegables de la columna de clave dependiente .
Crear y editar asignaciones de asociación

Puede especificar cómo se asigna una asociación a la base de datos en la ventana detalles de la asignación del
diseñador de EF.
NOTE
Solo puede asignar los detalles de las asociaciones que no tienen una restricción referencial especificada. Si se especifica una
restricción referencial, se incluye una propiedad de clave externa en la entidad y se pueden usar los detalles de asignación de
la entidad para controlar a qué columna se asigna la clave externa.
Crear una asignación de asociación

Haga clic con el botón secundario en una asociación en la superficie de diseño y seleccione asignación de
tabla . Esto muestra la asignación de asociación en la ventana detalles de la asignación .
Haga clic en Agregar una tabla o vista . Aparece una lista desplegable que incluye todas las tablas del
modelo de almacenamiento.
Seleccione la tabla a la que se asignará la asociación. La ventana detalles de la asignación muestra los
extremos de la asociación y las propiedades clave del tipo de entidad en cada extremo .
Para cada propiedad de clave, haga clic en el campo columna y seleccione la columna a la que se asignará
la propiedad.
Editar una asignación de asociación

Haga clic con el botón secundario en una asociación en la superficie de diseño y seleccione asignación de
tabla . Esto muestra la asignación de asociación en la ventana detalles de la asignación .
Haga clic en asignaciones para <nombre de tabla> . Aparece una lista desplegable que incluye todas las
tablas del modelo de almacenamiento.
Seleccione la tabla a la que se asignará la asociación. La ventana detalles de la asignación muestra los
extremos de la asociación y las propiedades clave del tipo de entidad en cada extremo.
Para cada propiedad de clave, haga clic en el campo columna y seleccione la columna a la que se asignará la
propiedad.
Editar y eliminar propiedades de navegación

Las propiedades de navegación son propiedades de acceso directo que se usan para buscar las entidades en los
extremos de una asociación en un modelo. Las propiedades de navegación se pueden crear al definir una
asociación entre dos tipos de entidad.
Para editar las propiedades de navegación
Seleccione una propiedad de navegación en la superficie del diseñador de EF. La información sobre la
propiedad de navegación se muestra en la ventana de propiedades de Visual Studio.
Cambie la configuración de propiedades en la ventana propiedades .
Para eliminar propiedades de navegación
Si las claves externas no se exponen en los tipos de entidad del modelo conceptual, la eliminación de una
propiedad de navegación puede provocar que la asociación correspondiente solo se pueda recorrer en una
dirección o incluso en ninguna.
Haga clic con el botón derecho en una propiedad de navegación en la superficie del diseñador EF y
seleccione eliminar .
Varios diagramas por modelo
NOTE
En este vídeo y en la página se muestra cómo dividir un modelo en varios diagramas mediante el Entity
Framework Designer (EF Designer). Es posible que desee usar esta característica cuando el modelo sea demasiado
grande para verlo o editarlo.
En versiones anteriores del diseñador de EF solo podía tener un diagrama por el archivo EDMX. A partir de Visual
Studio 2012, puede usar el diseñador de EF para dividir el archivo EDMX en varios diagramas.

En este vídeo se muestra cómo dividir un modelo en varios diagramas mediante el Entity Framework Designer (EF
Designer). Es posible que desee usar esta característica cuando el modelo sea demasiado grande para verlo o
editarlo.
Información general del diseñador EF

Al crear un modelo mediante el Asistente para Entity Data Model del diseñador de EF, se crea un archivo. edmx y se
agrega a la solución. Este archivo define la forma de las entidades y cómo se asignan a la base de datos.
El diseñador de EF consta de los siguientes componentes:
Superficie de diseño visual para editar el modelo. Puede crear, modificar o eliminar entidades y asociaciones.
Una ventana de del Explorador de modelos que proporciona vistas de árbol del modelo. Las entidades y sus
asociaciones se encuentran en la carpeta [ModelName] . Las tablas y restricciones de base de datos se
encuentran en el ][modelname . Carpeta de almacenamiento.
Una ventana de detalles de asignación para ver y editar asignaciones. Puede asignar tipos de entidad o
asociaciones a tablas, columnas y procedimientos almacenados de base de datos.
La ventana superficie de diseño visual se abre automáticamente cuando finaliza el Asistente para Entity Data
Model. Si el explorador de modelos no está visible, haga clic con el botón secundario en la superficie de diseño
principal y seleccione Explorador de modelos .
En la captura de pantalla siguiente se muestra un archivo. edmx abierto en el diseñador de EF. En la captura de
pantalla se muestra la superficie de diseño visual (a la izquierda) y la ventana del Explorador de modelos (a la
derecha).
Para deshacer una operación realizada en EF Designer, haga clic en Ctrl + Z.
Trabajar con diagramas

De forma predeterminada, el diseñador de EF crea un diagrama denominado Diagram1. Si tiene un diagrama con
un gran número de entidades y asociaciones, lo más conveniente es dividirlos lógicamente. A partir de Visual
Studio 2012, puede ver el modelo conceptual en varios diagramas.
A medida que agrega nuevos diagramas, aparecen en la carpeta diagramas de la ventana Explorador de modelos.
Para cambiar el nombre de un diagrama: seleccione el diagrama en la ventana Explorador de modelos, haga clic en
una vez en el nombre y escriba el nuevo nombre. También puede hacer clic con el botón secundario en el nombre
del diagrama y seleccionar cambiar nombre .
El nombre del diagrama se muestra junto al nombre del archivo. edmx en el editor de Visual Studio. Por ejemplo,
Model1. edmx[Diagram1].
El contenido de los diagramas (forma y color de las entidades y asociaciones) se almacena en el archivo. edmx.
diagram. Para ver este archivo, seleccione Explorador de soluciones y desdoblar el archivo. edmx.
No debe modificar manualmente el archivo. edmx. Diagram, es posible que el contenido de este archivo se
sobrescriba con el diseñador de EF.
Dividir entidades y asociaciones en un nuevo diagrama

Puede seleccionar entidades en el diagrama existente (mantenga presionada la tecla Mayús para seleccionar varias
entidades). Haga clic con el botón secundario del mouse y seleccione ir al nuevo diagrama . Se crea el nuevo
diagrama y las entidades seleccionadas y sus asociaciones se mueven al diagrama.
Como alternativa, puede hacer clic con el botón secundario en la carpeta diagramas del explorador de modelos y
seleccionar Agregar nuevo diagrama. Después, puede arrastrar y colocar entidades desde la carpeta tipos de
entidad del explorador de modelos hasta la superficie de diseño.
También puede cortar o copiar entidades (con las teclas Ctrl-X o Ctrl + C) de un diagrama y pegar (mediante la
tecla Ctrl-V) en la otra. Si el diagrama en el que pega una entidad ya contiene una entidad con el mismo nombre, se
creará una nueva entidad y se agregará al modelo. Por ejemplo: Diagram2 contiene la entidad Department. A
continuación, pegue otro departamento en Diagram2. La entidad Department1 se crea y se agrega al modelo
conceptual.
Para incluir entidades relacionadas en un diagrama, haga clic en la entidad y seleccione incluir relacionados . Esto
hará que se realice una copia de las entidades y asociaciones relacionadas en el diagrama especificado.
Cambiar el color de las entidades

Además de dividir un modelo en varios diagramas, también puede cambiar los colores de las entidades.
Para cambiar el color, seleccione una entidad (o varias entidades) en la superficie de diseño. A continuación, haga
clic con el botón secundario del mouse y seleccione propiedades . En el ventana Propiedades, seleccione la
propiedad color de relleno . Especifique el color mediante un nombre de color válido (por ejemplo, rojo) o un
RGB válido (por ejemplo, 255, 128, 128).
Resumen
En este tema, hemos examinado cómo dividir un modelo en varios diagramas y cómo especificar un color diferente
para una entidad mediante el Entity Framework Designer.
Selección de Entity Framework versión en tiempo de
ejecución para los modelos EF Designer
NOTE
A partir de EF6, se ha agregado la siguiente pantalla a EF Designer para que pueda seleccionar la versión del
tiempo de ejecución al que desea dirigirse al crear un modelo. La pantalla aparecerá cuando la versión más reciente
de Entity Framework no esté ya instalada en el proyecto. Si ya está instalada la versión más reciente, se usará de
forma predeterminada.
Destino de EF6. x
Puede elegir EF6 en la pantalla "elegir su versión" para agregar el tiempo de ejecución de EF6 al proyecto. Una vez
que haya agregado EF6, dejará de ver esta pantalla en el proyecto actual.
EF6 se deshabilitará si ya tiene instalada una versión anterior de EF (ya que no puede tener como destino varias
versiones del tiempo de ejecución del mismo proyecto). Si la opción EF6 no está habilitada aquí, siga estos pasos
para actualizar el proyecto a EF6:
1. Haga clic con el botón derecho en el proyecto en Explorador de soluciones y seleccione administrar paquetes
NuGet...
2. Seleccionar actualizaciones
3. Seleccione EntityFramework (Asegúrese de que se va a actualizar a la versión que quiera)
4. Haga clic en Update (Actualizar).
Destino de EF5. x
Puede elegir EF5 en la pantalla "elegir su versión" para agregar el tiempo de ejecución de EF5 al proyecto. Una vez
que haya agregado EF5, seguirá viendo la pantalla con la opción EF6 deshabilitada.
Si ya tiene instalada una versión de EF4. x del Runtime, verá que la versión de EF aparece en la pantalla en lugar de
EF5. En esta situación, puede actualizar a EF5 siguiendo estos pasos:
1. Seleccione herramientas-administrador de paquetes de la biblioteca de>-> consola del
administrador de paquetes
2. Ejecute Install-Package EntityFramework-version 5.0.0
Destino de EF4. x
Puede instalar el tiempo de ejecución de EF4. x en el proyecto mediante los pasos siguientes:
1. Seleccione herramientas-administrador de paquetes de la biblioteca de>-> consola del
administrador de paquetes
2. Ejecute Install-Package EntityFramework-version 4.3.0
Plantillas de generación de código del diseñador
Cuando se crea un modelo con Entity Framework Designer, las clases y el contexto derivado se generan
automáticamente. Además de la generación de código predeterminada, también se proporcionan una serie de
plantillas que pueden usarse para personalizar el código que se genera. Estas plantillas se proporcionan como
plantillas de texto T4, lo que permite personalizarlas en caso necesario.
El código que se genera de forma predeterminada depende de la versión de Visual Studio en que se cree el
modelo:
Los modelos creados en Visual Studio 2012 y 2013 generan clases de entidad POCO simples y un contexto que
se deriva del elemento DbContext simplificado.
Los modelos creados en Visual Studio 2010 generan clases de entidad que se derivan de EntityObject y un
contexto que se deriva de ObjectContext.
NOTE
Se recomienda cambiar a la plantilla Generador de DbContext una vez agregado el modelo.
En esta página se habla de las plantillas disponibles y luego se proporcionan instrucciones para agregar una
plantilla al modelo.
Plantillas disponibles
El equipo de Entity Framework proporciona las siguientes plantillas:
Generador de DbContext
Esta plantilla genera clases de entidad POCO simples y un contexto que se deriva de DbContext mediante EF6. Es la
plantilla recomendada, a menos que tenga motivos para usar una de las otras plantillas que se indican a
continuación. También es la plantilla de generación de código que se obtiene de forma predeterminada si se usan
versiones recientes de Visual Studio (de Visual Studio 2013 en adelante): Al crear un modelo, se usa esta plantilla
de forma predeterminada y los archivos T4 (.tt) se anidados bajo el archivo .edmx.
Versiones anteriores de Visual Studio
Visual Studio 2012: para obtener las plantillas DbContextGenerator de EF 6.x , tiene que instalar la versión
más reciente de Entity Framework Tools para Visual Studio : vea la página Obtener Entity Framework para
más información.
Visual Studio 2010: las plantillas DbContextGenerator de EF 6.x no están disponibles para Visual
Studio 2010.
Generador de DbContext para EF 5.x
Si usa una versión anterior del paquete NuGet de EntityFramework (uno con una versión principal de 5), tiene que
usar la plantilla Generador de DbContext para EF 5.x .
Si usa Visual Studio 2013 o 2012, esta plantilla ya está instalada.
Si usa Visual Studio 2010, tiene que seleccionar la pestaña Online al agregar la plantilla para descargarla desde la
Galería de Visual Studio. También puede instalar la plantilla directamente desde la Galería de Visual Studio
previamente. Dado que las plantillas están incluidas en las versiones posteriores de Visual Studio, las versiones de
la galería solo se pueden instalar en Visual Studio 2010.
Generador de DbContext para EF 5.x para C#
Generador de DbContext para EF 5.x para sitios web de C#
Generador de DbContext para EF 5.x para VB.NET
Generador de DbContext para EF 5.x para sitios web de VB.NET
Generador de DbContext para EF 4.x
Si usa una versión anterior del paquete NuGet de EntityFramework (uno con una versión principal de 4), tiene que
usar la plantilla Generador de DbContext para EF 4.x . La encontrará en la pestaña Online al agregar la plantilla
o puede instalarla directamente desde la Galería de Visual Studio previamente.
Generador de DbContext para EF 4.x para C#
Generador de DbContext para EF 4.x para sitios web de C#
Generador de DbContext para EF 4.x para VB.NET
Generador de DbContext para EF 4.x para sitios web de VB.NET
Generador de EntityObject
Esta plantilla genera clases de entidad que se derivan de EntityObject y un contexto que se deriva de ObjectContext.
NOTE
Considere la posibilidad de usar Generador de DbContext
Generador de DbContext es ahora la plantilla recomendada para las nuevas aplicaciones. Generador de DbContext
aprovecha la API de DbContext, que es más sencilla. Generador de EntityObject sigue estando disponible para la
compatibilidad con las aplicaciones existentes.
Visual Studio 2010, 2012 & 2013
Tiene que seleccionar la pestaña Online al agregar la plantilla para descargarla desde la Galería de Visual Studio.
También puede instalar la plantilla directamente desde la Galería de Visual Studio previamente.
Generador de EntityObject para EF 6.x para C#
Generador de EntityObject para EF 6.x para sitios web de C#
Generador de EntityObject para EF 6.x para VB.NET
Generador de EntityObject para EF 6.x para sitios web de VB.NET
Generador de EntityObject para EF 5.x
Si usa Visual Studio 2012 o 2013, tiene que seleccionar la pestaña Online al agregar la plantilla para descargarla
desde la Galería de Visual Studio. También puede instalar la plantilla directamente desde la Galería de Visual Studio
previamente. Dado que las plantillas están incluidas en Visual Studio 2010, las versiones de la galería solo se
pueden instalar en Visual Studio 2012 y 2013.
Generador de EntityObject para EF 5.x para C#
Generador de EntityObject para EF 5.x para sitios web de C#
Generador de EntityObject para EF 5.x para VB.NET
Generador de EntityObject para EF 5.x para sitios web de VB.NET
Si solo quiere la generación de código de ObjectContext y no necesita editar la plantilla, puede revertir a la
generación de código de EntityObject.
Si usa Visual Studio 2010, esta plantilla ya está instalada. Si crea un nuevo modelo en Visual Studio 2010, esta
plantilla se usa de forma predeterminada, pero los archivos .tt no se incluyen en el proyecto. Si quiere personalizar
la plantilla, tiene que agregarla al proyecto.
Generador de entidades de autoseguimiento (STE)
Esta plantilla genera clases de entidad de autoseguimiento y un contexto que se deriva de ObjectContext. En una
aplicación de EF, un contexto es el responsable de realizar el seguimiento de los cambios en las entidades. Pero en
los escenarios de n niveles, es posible que el contexto no esté disponible en el nivel que modifica las entidades. Las
entidades de autoseguimiento ayudan a realizar el seguimiento de los cambios en cualquier nivel. Para obtener
más información, vea Entidades de autoseguimiento.
NOTE
La plantilla STE no se recomienda
Ya no se recomienda usar la plantilla STE en las aplicaciones nuevas, aunque sigue estando disponible para la
compatibilidad con las aplicaciones existentes. Visite el artículo sobre entidades desconectadas para ver otras
opciones recomendadas para escenarios de n niveles.
NOTE
No hay ninguna versión para EF 6.x de la plantilla STE.
NOTE
No hay ninguna versión para Visual Studio 2013 de la plantilla STE.
Visual Studio 2012

Si usa Visual Studio 2012, tiene que seleccionar la pestaña Online al agregar la plantilla para descargarla desde la
Galería de Visual Studio. También puede instalar la plantilla directamente desde la Galería de Visual Studio
previamente. Dado que las plantillas están incluidas en Visual Studio 2010, las versiones de la galería solo se
pueden instalar en Visual Studio 2012.
Generador de STE para EF 5.x para C#
Generador de STE para EF 5.x para sitios web de C#
Generador de STE para EF 5.x para VB.NET
Generador de STE para EF 5.x para sitios web de VB.NET
Visual Studio 2010**
Si usa Visual Studio 2010, esta plantilla ya está instalada.
Generador de entidades POCO
Esta plantilla genera clases de entidad POCO y un contexto que se deriva de ObjectContext
NOTE
Considere la posibilidad de usar Generador de DbContext
Generador de DbContext es ahora la plantilla recomendada para generar clases POCO en nuevas aplicaciones.
Generador de DbContext aprovecha la nueva API de DbContext y puede generar clases POCO más sencillas.
Generador de entidades POCO sigue estando disponible para la compatibilidad con las aplicaciones existentes.
NOTE
No hay ninguna versión para EF 5.x o EF 6.x de la plantilla STE.
NOTE
No hay ninguna versión para Visual Studio 2013 de la plantilla POCO.
Visual Studio 2012 y Visual Studio 2010

Tiene que seleccionar la pestaña Online al agregar la plantilla para descargarla desde la Galería de Visual Studio.
También puede instalar la plantilla directamente desde la Galería de Visual Studio previamente.
Generador de POCO para EF 4.x para C#
Generador de POCO para EF 4.x para sitios web de C#
Generador de POCO para EF 4.x para VB.NET
Generador de POCO para EF 4.x para sitios web de VB.NET
Qué son las plantillas "Sitios web"
Las plantillas "Sitios web" (es decir, Generador de DbContext para EF 5.x para sitios web de C# ) se usan en
proyectos de sitio web creados con Archivo -> Nuevo -> Sitio web... . Son distintas a las aplicaciones web,
creadas con Archivo -> Nuevo -> Proyecto... , que usan las plantillas estándar. Se proporcionan plantillas
independientes porque así lo exige el sistema de plantilla de elemento de Visual Studio.
Uso de una plantilla

Para empezar a usar una plantilla de generación de código, haga clic con el botón derecho en un punto vacío de la
superficie de diseño de EF Designer y seleccione Agregar elemento de generación de código...
Si ya ha instalado la plantilla que quiere usar (o estaba incluida en Visual Studio), estará disponible en la sección
Código o Datos del menú izquierdo.
Si aún no tiene instalada la plantilla, seleccione Online en el menú izquierdo y busque la plantilla que quiere.
Si usa Visual Studio 2012, los nuevos archivos .tt aparecen anidados en el archivo .edmx.*
NOTE
En el caso de los modelos creados en Visual Studio 2012, tiene que eliminar las plantillas usadas para la generación de código
predeterminada; si no lo hace, se generarán clases y contexto duplicados. Los archivos predeterminados son
<nombreDelModelo>.tt y <nombreDelModelo>.context.tt .
Si usa Visual Studio 2010, los archivos tt se agregan directamente al proyecto.
Revertir a ObjectContext en Entity Framework
Designer
Con la versión anterior de Entity Framework un modelo creado con EF Designer generaría un contexto derivado
de ObjectContext y clases de entidad derivadas de EntityObject.
A partir de EF 4.1, se recomienda cambiar a una plantilla de generación de código que genera un contexto que se
deriva de las clases de entidad DbContext y POCO.
En Visual Studio 2012, se obtiene el código DbContext generado de forma predeterminada para todos los nuevos
modelos creados con el diseñador de EF. Los modelos existentes seguirán generando código basado en
ObjectContext a menos que decida cambiar al generador de código basado en DbContext.
Revertir a la generación de código de ObjectContext

1. deshabilitar la generación de código DbContext
La generación de las clases DbContext y POCO derivadas se controla mediante dos archivos. TT en el proyecto. Si
expande el archivo. edmx en el explorador de soluciones, verá estos archivos. Elimine ambos archivos del
proyecto.
Si usa VB.NET, debe seleccionar el botón Mostrar todos los archivos para ver los archivos anidados.
2. volver a habilitar la generación de código de ObjectContext

Abra el modelo en el diseñador de EF, haga clic con el botón derecho en una sección en blanco de la superficie de
diseño y seleccione propiedades .
En el ventana Propiedades cambie la estrategia de generación de código de ninguno a predeterminado .
Especificación CSDL
El lenguaje de definición de esquemas conceptuales (CSDL) es un lenguaje basado en XML que describe las
entidades, las relaciones y las funciones que conforman un modelo conceptual de una aplicación controlada por
datos. Este modelo conceptual puede ser utilizado por el Entity Framework o WCF Data Services. Los metadatos
que se describen con CSDL los utiliza el Entity Framework para asignar entidades y relaciones que se definen en un
modelo conceptual a un origen de datos. Para obtener más información, vea especificación de SSDL y
especificación de MSL.
CSDL es la implementación del Entity Framework del Entity Data Model.
En una aplicación Entity Framework, los metadatos del modelo conceptual se cargan desde un archivo. CSDL
(escrito en CSDL) en una instancia de System. Data. Metadata. Edm. EdmItemCollection y es accesible mediante
métodos en el Clase System. Data. Metadata. Edm. MetadataWorkspace. Entity Framework utiliza los metadatos del
modelo conceptual para traducir las consultas del modelo conceptual a comandos específicos del origen de datos.
El diseñador de EF almacena la información del modelo conceptual en un archivo. edmx en tiempo de diseño. En el
momento de la compilación, el diseñador de EF usa información en un archivo. edmx para crear el archivo. CSDL
que necesita Entity Framework en tiempo de ejecución.
Las versiones de CSDL se diferencian por los espacios de nombres XML.
VERSIÓ N DE C SDL ESPA C IO DE N O M B RES XM L
CSDL v1 https://schemas.microsoft.com/ado/2006/04/edm
CSDL V2 https://schemas.microsoft.com/ado/2008/09/edm
CSDL V3 https://schemas.microsoft.com/ado/2009/11/edm
Elemento Association (CSDL)

Un elemento Association define una relación entre dos tipos de entidad. Una asociación debe especificar los tipos
de entidad que están implicados en la relación y el posible número de tipos de entidad en cada extremo de la
relación, que se conoce como multiplicidad. La multiplicidad de un extremo de asociación puede tener un valor de
uno (1), cero o uno (0.. 1) o varios (*). Esta información se especifica en dos elementos End secundarios.
Es posible obtener acceso a las instancias de tipo de entidad situadas en un extremo de la asociación a través de las
propiedades de navegación o las claves externas, si estas se exponen en un tipo de entidad.
En una aplicación, una instancia de una asociación representa una asociación concreta entre las instancias de tipos
de entidad. Las instancias de la asociación se agrupan de manera lógica en un conjunto de asociaciones.
Un elemento Association puede tener los elementos secundarios siguientes (en el orden mostrado):
Documentation (cero o un elemento)
End (exactamente 2 elementos)
ReferentialConstraint (cero o un elemento)
Elementos Annotation (cero o más elementos)
Atributos aplicables
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento Association .
N O M B RE DEL AT RIB UTO ES O B L IGATO RIO VA L UE
Nombre Sí El nombre de la asociación.
NOTE
Se puede aplicar cualquier número de atributos de anotación (atributos XML personalizados) al elemento Association . Sin
embargo, es posible que los atributos personalizados no pertenezcan a ningún espacio de nombres XML reservado para
CSDL. Dos atributos personalizados cualesquiera no pueden tener nombres completos idénticos.
Ejemplo
En el ejemplo siguiente se muestra un elemento Association que define la Asociación CustomerOrders cuando
las claves externas no se han expuesto en los tipos de entidad Customer y Order . Los valores de multiplicidad
de cada extremo de la Asociación indican que se pueden asociar muchos pedidos a un cliente , pero solo un
cliente puede asociarse a un pedido . Además, el elemento aleliminar indica que todos los pedidos relacionados
con un cliente determinado y que se han cargado en el ObjectContext se eliminarán si se elimina el cliente .
<Association Name="CustomerOrders">
<End Type="ExampleModel.Customer" Role="Customer" Multiplicity="1" >
<OnDelete Action="Cascade" />
</End>
<End Type="ExampleModel.Order" Role="Order" Multiplicity="*" />
</Association>
En el ejemplo siguiente se muestra un elemento Association que define la Asociación CustomerOrders cuando
las claves externas se han expuesto en los tipos de entidad Customer y Order . Con las claves externas expuestas,
la relación entre las entidades se administra con un elemento ReferentialConstraint . Un elemento
AssociationSetMapping correspondiente no es necesario para asignar esta asociación al origen de datos.
<End Type="ExampleModel.Customer" Role="Customer" Multiplicity="1" >
</End>
<ReferentialConstraint>
<Principal Role="Customer">
<PropertyRef Name="Id" />
</Principal>
<Dependent Role="Order">
<PropertyRef Name="CustomerId" />
</Dependent>
</ReferentialConstraint>
</Association>
AssociationSet (Elemento) (CSDL)
El elemento AssociationSet en el lenguaje de definición de esquemas conceptuales (CSDL) es un contenedor
lógico para las instancias de asociación del mismo tipo. Un conjunto de asociaciones proporciona una definición
para agrupar las instancias de la asociación con objeto de que se puedan asignar a un origen de datos.
El elemento AssociationSet puede tener los elementos secundarios siguientes (en el orden mostrado):
Documentación (cero o un elemento permitido)
End (exactamente dos elementos necesarios)
Elementos Annotation (cero o más elementos permitidos)
El atributo Association especifica el tipo de asociación que contiene un conjunto de asociaciones. Los conjuntos
de entidades que componen los extremos de un conjunto de asociaciones se especifican con exactamente dos
elementos finales secundarios.
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento AssociationSet .
Nombre Sí El nombre del conjunto de entidades. El

valor del atributo Name no puede ser
el mismo que el valor del atributo
Association .
Asociación Sí Nombre completo de la asociación

cuyas instancias contiene el conjunto de
asociaciones. La asociación debe estar
en el mismo espacio de nombres que el
conjunto de asociaciones.
NOTE
Se puede aplicar cualquier número de atributos de anotación (atributos XML personalizados) al elemento AssociationSet .
Sin embargo, es posible que los atributos personalizados no pertenezcan a ningún espacio de nombres XML reservado para
Ejemplo
En el ejemplo siguiente se muestra un elemento EntityContainer con dos elementos AssociationSet :
<EntityContainer Name="BooksContainer" >
<EntitySet Name="Books" EntityType="BooksModel.Book" />
<EntitySet Name="Publishers" EntityType="BooksModel.Publisher" />
<EntitySet Name="Authors" EntityType="BooksModel.Author" />
<AssociationSet Name="PublishedBy" Association="BooksModel.PublishedBy">
<End Role="Book" EntitySet="Books" />
<End Role="Publisher" EntitySet="Publishers" />
</AssociationSet>
<AssociationSet Name="WrittenBy" Association="BooksModel.WrittenBy">
<End Role="Author" EntitySet="Authors" />
</AssociationSet>
</EntityContainer>
CollectionType (Elemento de CSDL)

El elemento CollectionType del lenguaje de definición de esquemas conceptuales (CSDL) especifica que un
parámetro de función o un tipo de valor devuelto de función es una colección. El elemento CollectionType puede
ser un elemento secundario del elemento Parameter o del elemento ReturnType (function). El tipo de colección se
puede especificar mediante el atributo Type o uno de los siguientes elementos secundarios:
CollectionType
ReferenceType
RowType
TypeRef
NOTE
Un modelo no se validará si el tipo de una colección se especifica con el atributo Type y un elemento secundario.
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento CollectionType . Tenga en
cuenta que los atributos DefaultValue , MaxLength , FixedLength , Precision , Scale , Unicode y collation solo
se aplican a las colecciones de EDMSimpleTypes .
Tipo No Tipo de la colección.
Admisión de valores NULL No True (el valor predeterminado) o False ,

según si la propiedad puede tener un
valor nulo.
[!NOTE]
> En CSDL v1, una propiedad de tipo

complejo debe tener
Nullable="False" .
DefaultValue No Valor predeterminado de la propiedad.

MaxLength No La longitud máxima del valor de la

propiedad.
FixedLength No True o false , dependiendo de si el

valor de la propiedad se almacenará
como una cadena de longitud fija.
Precisión No Precisión del valor de propiedad.
Escala No Escala del valor de propiedad.
SRID No Identificador de referencia del sistema

espacial. Solo es válido para las
propiedades de los tipos espaciales.
Para obtener más información, consulte
SRID y SRID (SQL Server) .
Unicode No True o false , dependiendo de si el

como una cadena Unicode.
Intercalación No Cadena que especifica la secuencia de

intercalación que se usará en el origen
de datos.
NOTE
Se puede aplicar cualquier número de atributos de anotación (atributos XML personalizados) al elemento CollectionType .
Ejemplo
En el ejemplo siguiente se muestra una función definida por el modelo que utiliza un elemento CollectionType
para especificar que la función devuelve una colección de tipos de entidad Person (tal y como se especifica con el
atributo elementType ).
<Function Name="LastNamesAfter">
<Parameter Name="someString" Type="Edm.String"/>
<ReturnType>
<CollectionType ElementType="SchoolModel.Person"/>
</ReturnType>
<DefiningExpression>
SELECT VALUE p
FROM SchoolEntities.People AS p
WHERE p.LastName >= someString
</DefiningExpression>
</Function>
para especificar que la función devuelve una colección de filas (tal y como se especifica en el elemento RowType ).
<Parameter Name="someString" Type="Edm.String" />
<ReturnType>
<CollectionType>
<RowType>
<Property Name="FirstName" Type="Edm.String" Nullable="false" />
<Property Name="LastName" Type="Edm.String" Nullable="false" />
</RowType>
</CollectionType>
</ReturnType>
SELECT VALUE ROW(p.FirstName, p.LastName)
WHERE p.LastName >= somestring
</Function>
En el ejemplo siguiente se muestra una función definida por el modelo que usa el elemento CollectionType para
especificar que la función acepta como parámetro una colección de tipos de entidad Depar tment .
<Function Name="GetAvgBudget">
<Parameter Name="Departments">
<CollectionType>
<TypeRef Type="SchoolModel.Department"/>
</CollectionType>
</Parameter>
<ReturnType Type="Collection(Edm.Decimal)"/>
SELECT VALUE AVG(d.Budget) FROM Departments AS d
</Function>
ComplexType (Elemento) (CSDL)

Un elemento complexType define una estructura de datos formada por propiedades EdmSimpleType u otros
tipos complejos. Un tipo complejo puede ser una propiedad de un tipo de entidad u otro tipo complejo. Un tipo
complejo se parece a un tipo de entidad en que también define datos. Sin embargo, existen algunas diferencias
clave entre los tipos complejos y los tipos de entidad:
Los tipos complejos no tienen identidades (o claves) y, por consiguiente, no pueden existir de forma
independiente. Los tipos complejos solo pueden existir como propiedades de tipos de entidad u otros tipos
complejos.
Los tipos complejos no pueden participar en asociaciones. Los extremos de una asociación no pueden ser tipos
complejos y, por consiguiente, no se pueden definir propiedades de navegación para tipos complejos.
Una propiedad de tipo complejo no puede tener un valor nulo, aunque las propiedades escalares de un tipo
complejo se pueden establecer cada una con el valor nulo.
Un elemento complexType puede tener los elementos secundarios siguientes (en el orden mostrado):
Property (cero o más elementos)
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento complexType .
Nombre Sí El nombre del tipo complejo. El nombre

de un tipo complejo no puede ser igual
que el nombre de otro tipo complejo,
tipo de entidad o asociación que esté
dentro del ámbito del modelo.
BaseType No El nombre de otro tipo complejo que es

el tipo base del tipo complejo que se
define.
[!NOTE]
> Este atributo no es aplicable en CSDL

v1. La herencia de los tipos complejos
no se admite en esa versión.
Descripción breve No True o false (valor predeterminado) en

función de si el tipo complejo es un tipo
abstracto.
[!NOTE]
> Este atributo no es aplicable en CSDL

v1. Los tipos complejos de esa versión
no pueden ser tipos abstractos.
NOTE
Se puede aplicar cualquier número de atributos de anotación (atributos XML personalizados) al elemento complexType . Sin
Ejemplo
En el ejemplo siguiente se muestra un tipo complejo, Address , con las propiedades EdmSimpleType
StreetAddress , City , StateOrProvince , Countr y y PostalCode .
<ComplexType Name="Address" >

<Property Type="String" Name="StreetAddress" Nullable="false" />
<Property Type="String" Name="City" Nullable="false" />
<Property Type="String" Name="StateOrProvince" Nullable="false" />
<Property Type="String" Name="Country" Nullable="false" />
<Property Type="String" Name="PostalCode" Nullable="false" />
</ComplexType>
Para definir la Dirección de tipo complejo (anterior) como una propiedad de un tipo de entidad, debe declarar el
tipo de propiedad en la definición de tipo de entidad. En el ejemplo siguiente se muestra la propiedad Address
como un tipo complejo en un tipo de entidad (publicador ):
<EntityType Name="Publisher">
<Key>
</Key>
<Property Type="Int32" Name="Id" Nullable="false" />
<Property Type="String" Name="Name" Nullable="false" />
<Property Type="BooksModel.Address" Name="Address" Nullable="false" />
<NavigationProperty Name="Books" Relationship="BooksModel.PublishedBy"
FromRole="Publisher" ToRole="Book" />
</EntityType>
DefiningExpression (Elemento) (CSDL)

El elemento DefiningExpression en el lenguaje de definición de esquemas conceptuales (CSDL) contiene una
expresión Entity SQL que define una función en el modelo conceptual.
NOTE
Para fines de validación, un elemento DefiningExpression puede contener contenido arbitrario. Sin embargo, Entity
Framework producirá una excepción en tiempo de ejecución si un elemento DefiningExpression no contiene Entity SQL
válidos.
Se puede aplicar cualquier número de atributos de anotación (atributos XML personalizados) al elemento
DefiningExpression . Sin embargo, es posible que los atributos personalizados no pertenezcan a ningún espacio
de nombres XML reservado para CSDL. Dos atributos personalizados cualesquiera no pueden tener nombres
completos idénticos.
Ejemplo
En el ejemplo siguiente se usa un elemento DefiningExpression para definir una función que devuelve el
número de años transcurridos desde que se publicó un libro. El contenido del elemento DefiningExpression se
escribe en Entity SQL.
<Function Name="GetYearsInPrint" ReturnType="Edm.Int32" >

<Parameter Name="book" Type="BooksModel.Book" />
Year(CurrentDateTime()) - Year(cast(book.PublishedDate as DateTime))
</Function>
Dependent (Elemento) (CSDL)

El elemento dependiente en el lenguaje de definición de esquemas conceptuales (CSDL) es un elemento
secundario del elemento ReferentialConstraint y define el extremo dependiente de una restricción referencial. Un
elemento ReferentialConstraint define una funcionalidad similar a una restricción de integridad referencial en
una base de datos relacional. Del mismo modo que una columna (o columnas) de una tabla de base de datos
puede hacer referencia a la clave principal de otra tabla, una propiedad (o propiedades) de un tipo de entidad
puede hacer referencia a la clave de entidad de otro tipo de entidad. El tipo de entidad al que se hace referencia se
denomina extremo principal de la restricción. El tipo de entidad que hace referencia al extremo principal se
denomina extremo dependiente de la restricción. Los elementos Proper tyRef se usan para especificar qué claves
hacen referencia al extremo principal.
El elemento dependiente puede tener los elementos secundarios siguientes (en el orden mostrado):
PropertyRef (uno o más elementos)
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento dependiente .
Rol Sí Nombre del tipo de entidad del extremo

dependiente de la asociación.
NOTE
Se puede aplicar cualquier número de atributos de anotación (atributos XML personalizados) al elemento dependiente . Sin
Ejemplo
En el ejemplo siguiente se muestra un elemento ReferentialConstraint que se usa como parte de la definición de
la Asociación PublishedBy . La propiedad PublisherId del tipo de entidad book constituye el extremo
dependiente de la restricción referencial.
<Association Name="PublishedBy">
<End Type="BooksModel.Book" Role="Book" Multiplicity="*" >
</End>
<End Type="BooksModel.Publisher" Role="Publisher" Multiplicity="1" />
<Principal Role="Publisher">
</Principal>
<Dependent Role="Book">
<PropertyRef Name="PublisherId" />
</Dependent>
</Association>
Documentation (Elemento) (CSDL)

El elemento Documentation del lenguaje de definición de esquemas conceptuales (CSDL) se puede usar para
proporcionar información sobre un objeto que se define en un elemento primario. En un archivo. edmx, cuando el
elemento Documentation es un elemento secundario de un elemento que aparece como un objeto en la
superficie de diseño del diseñador EF (como una entidad, asociación o propiedad), el contenido del elemento
Documentation aparecerá en la ventana propiedades de Visual Studio para el objeto.
El elemento Documentation puede tener los elementos secundarios siguientes (en el orden mostrado):
Summar y : breve descripción del elemento primario. (cero o un elemento).
LongDescription : una descripción amplia del elemento primario. (cero o un elemento).
Elementos de anotación. (cero o más elementos).
Documentation . Sin embargo, es posible que los atributos personalizados no pertenezcan a ningún espacio de
nombres XML reservado para CSDL. Dos atributos personalizados cualesquiera no pueden tener nombres
Ejemplo
En el ejemplo siguiente se muestra el elemento Documentation como un elemento secundario de un elemento
EntityType. Si el fragmento de código siguiente estaba en el contenido CSDL de un archivo. edmx, el contenido de
los elementos Summar y y longDescription aparecerá en la ventana propiedades de Visual Studio al hacer clic
en el tipo de entidad Customer .
<EntityType Name="Customer">
<Documentation>
<Summary>Summary here.</Summary>
<LongDescription>Long description here.</LongDescription>
</Documentation>
<Key>
</Key>
<Property Type="Int32" Name="CustomerId" Nullable="false" />
</EntityType>
End (Elemento) (CSDL)

El elemento End en el lenguaje de definición de esquemas conceptuales (CSDL) puede ser un elemento secundario
del elemento Association o del elemento AssociationSet. En cada caso, el rol del elemento final es diferente y los
atributos correspondientes son diferentes.
Elemento End como elemento secundario del elemento Association
Un elemento End (como elemento secundario del elemento Association ) identifica el tipo de entidad en un
extremo de una asociación y el número de instancias de tipo de entidad que pueden existir en ese extremo de una
asociación. Los extremos de asociación se definen como parte de una asociación, y esta debe tener exactamente
dos extremos. Es posible obtener acceso a las instancias de tipo de entidad situadas en un extremo de la asociación
a través de las propiedades de navegación o las claves externas si estas se exponen en un tipo de entidad.
Un elemento End puede tener los elementos secundarios siguientes (en el orden mostrado):
Aleliminar (cero o un elemento)
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento End cuando es el elemento
secundario de un elemento Association .
Tipo Sí Nombre del tipo de entidad de un

extremo de la asociación.
Rol No Nombre para el extremo de la

asociación. Si no se proporciona ningún
nombre, se usará el nombre del tipo de
entidad del extremo de la asociación.
Multiplicidad Sí 1 , 0.. 1 o * en función del número de

instancias de tipo de entidad que
pueden estar al final de la asociación.
1 indica que existe exactamente una
instancia de tipo de entidad en el
0.. 1 indica que hay cero o una
instancia de tipo de entidad en el
* indica que hay cero, una o más
instancias de tipo de entidad en el
NOTE
Se puede aplicar cualquier número de atributos de anotación (atributos XML personalizados) al elemento final . Sin
Ejemplo
En el ejemplo siguiente se muestra un elemento Association que define la Asociación CustomerOrders . Los
valores de multiplicidad de cada extremo de la Asociación indican que se pueden asociar muchos pedidos a un
cliente , pero solo un cliente puede asociarse a un pedido . Además, el elemento aleliminar indica que todos los
pedidos relacionados con un cliente determinado y que se han cargado en el ObjectContext se eliminarán si se
elimina el cliente .
<End Type="ExampleModel.Customer" Role="Customer" Multiplicity="1" />
<End Type="ExampleModel.Order" Role="Order" Multiplicity="*">
</End>
</Association>
Elemento End como elemento secundario del elemento AssociationSet

El elemento End especifica un extremo de un conjunto de asociaciones. El elemento AssociationSet debe
contener dos elementos End . La información contenida en un elemento End se utiliza para asignar un conjunto de
asociaciones a un origen de datos.
NOTE
Los elementos de anotación deben aparecer después de todos los demás elementos secundarios. Los elementos Annotation
solo se permiten en CSDL V2 y versiones posteriores.
secundario de un elemento AssociationSet .
#A4 Sí Nombre del elemento EntitySet que

define un extremo del elemento
primario AssociationSet . El elemento
EntitySet debe definirse en el mismo
contenedor de entidades que el
elemento primario AssociationSet .
Rol No Nombre del extremo del conjunto de

asociaciones. Si no se utiliza el atributo
role , el nombre del extremo del
conjunto de asociaciones será el
nombre del conjunto de entidades.
NOTE
Ejemplo
En el ejemplo siguiente se muestra un elemento EntityContainer con dos elementos AssociationSet , cada uno
con dos elementos End :
</AssociationSet>
</AssociationSet>
</EntityContainer>
Elemento EntityContainer (CSDL)

El elemento EntityContainer en el lenguaje de definición de esquemas conceptuales (CSDL) es un contenedor
lógico para conjuntos de entidades, conjuntos de asociaciones e importaciones de funciones. Un contenedor de
entidades de modelo conceptual se asigna a un contenedor de entidades de modelo de almacenamiento a través
del elemento EntityContainerMapping. Un contenedor de entidades de modelo de almacenamiento describe la
estructura de la base de datos: los conjuntos de entidades describen las tablas, los conjuntos de asociaciones
describen las restricciones de clave externa y las importaciones de función describen los procedimientos
almacenados en una base de datos.
Un elemento EntityContainer puede tener cero o un elemento de documentación. Si hay un elemento de
documentación , debe preceder a todos los elementos EntitySet , AssociationSet y FunctionImpor t .
Un elemento EntityContainer puede tener cero o más de los elementos secundarios siguientes (en el orden
mostrado):
EntitySet
AssociationSet
FunctionImport
Elementos Annotation
Puede extender un elemento EntityContainer para incluir el contenido de otro EntityContainer que esté en el
mismo espacio de nombres. Para incluir el contenido de otro EntityContainer , en el elemento EntityContainer
de referencia, establezca el valor del atributo extends en el nombre del elemento EntityContainer que desea
incluir. Todos los elementos secundarios del elemento EntityContainer incluido se tratarán como elementos
secundarios del elemento EntityContainer que hace la referencia.
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento using .
Nombre Sí Nombre del contenedor de entidades.
Llegar No Nombre de otro contenedor de

entidades dentro del mismo espacio de
nombres.
NOTE
Se puede aplicar cualquier número de atributos de anotación (atributos XML personalizados) al elemento EntityContainer .
Ejemplo
En el ejemplo siguiente se muestra un elemento EntityContainer que define tres conjuntos de entidades y dos
conjuntos de asociaciones.

</AssociationSet>
</AssociationSet>
</EntityContainer>
EntitySet (Elemento) (CSDL)

El elemento EntitySet del lenguaje de definición de esquemas conceptuales es un contenedor lógico para las
instancias de un tipo de entidad y las instancias de cualquier tipo que se deriva de ese tipo de entidad. La relación
entre un tipo de entidad y un conjunto de entidades es análoga a la relación entre una fila y una tabla en una base
de datos relacional. Igual que una fila, un tipo de entidad define un conjunto de datos relacionados y, lo mismo que
una tabla, un conjunto de entidades contiene instancias de esa definición. Un conjunto de entidades proporciona
una construcción para agrupar las instancias del tipo de entidad para que se pueden asignar a las estructuras de
datos relacionadas en un origen de datos.
Se pueden definir varios conjuntos de entidades para un tipo de entidad determinado.
NOTE
El diseñador de EF no es compatible con los modelos conceptuales que contienen varios conjuntos de entidades por tipo.
El elemento EntitySet puede tener los elementos secundarios siguientes (en el orden mostrado):
Elemento Documentation (cero o un elemento permitidos)
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento EntitySet .
Nombre Sí El nombre del conjunto de entidades.
EntityType Sí El nombre completo del tipo de entidad

para el que el conjunto de entidades
contiene las instancias.
NOTE
Se puede aplicar cualquier número de atributos de anotación (atributos XML personalizados) al elemento EntitySet . Sin
Ejemplo
En el ejemplo siguiente se muestra un elemento EntityContainer con tres elementos EntitySet :

</AssociationSet>
</AssociationSet>
</EntityContainer>
Es posible definir varios conjuntos de entidades por tipo (MEST). En el ejemplo siguiente se define un contenedor
de entidades con dos conjuntos de entidades para el tipo de entidad book :

<EntitySet Name="FictionBooks" EntityType="BooksModel.Book" />
</AssociationSet>
<AssociationSet Name="BookAuthor" Association="BooksModel.BookAuthor">
</AssociationSet>
</EntityContainer>
Elemento EntityType (CSDL)
El elemento EntityType representa la estructura de un concepto de nivel superior, como un cliente o un pedido, en
un modelo conceptual. Un tipo de entidad es una plantilla para las instancias de los tipos de entidad de una
aplicación. Cada plantilla contiene la información siguiente:
Un nombre único. (Requerido)
Una clave de entidad definida por una o varias propiedades. (Requerido)
Propiedades para el almacenamiento de datos. (Opcional).
Propiedades de navegación que permiten desplazarse de un extremo de la asociación al otro. (Opcional).
En una aplicación, una instancia de un tipo de entidad representa un objeto específico (como un cliente o un
pedido concreto). Cada instancia de un tipo de entidad debe tener una clave de entidad única dentro de un
conjunto de entidades.
Dos instancias de tipo de entidad se consideran iguales solo si son del mismo tipo y los valores de sus claves de
entidad son idénticos.
Un elemento EntityType puede tener los elementos secundarios siguientes (en el orden mostrado):
Key (cero o un elemento)
Property (cero o más elementos)
NavigationProperty (cero o más elementos)
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento EntityType .
Nombre Sí El nombre del tipo de entidad.
BaseType No El nombre de otro tipo de entidad que

sea el tipo base del tipo de entidad que
se define.
Descripción No True o false , dependiendo de si el tipo

de entidad es un tipo abstracto.
OpenType No True o false , dependiendo de si el tipo

de entidad es un tipo de entidad
abierto.
[!NOTE]
> El atributo OpenType solo es

aplicable a los tipos de entidad que se
definen en los modelos conceptuales
que se usan con el Data Services
ADO.net.
NOTE
Se puede aplicar cualquier número de atributos de anotación (atributos XML personalizados) al elemento EntityType . Sin
Ejemplo
En el ejemplo siguiente se muestra un elemento EntityType con tres elementos Proper ty y dos elementos
NavigationProper ty :
<EntityType Name="Book">
<Key>
<PropertyRef Name="ISBN" />
</Key>
<Property Type="String" Name="ISBN" Nullable="false" />
<Property Type="String" Name="Title" Nullable="false" />
<Property Type="Decimal" Name="Revision" Nullable="false" Precision="29" Scale="29" />
<NavigationProperty Name="Publisher" Relationship="BooksModel.PublishedBy"
FromRole="Book" ToRole="Publisher" />
<NavigationProperty Name="Authors" Relationship="BooksModel.WrittenBy"
FromRole="Book" ToRole="Author" />
</EntityType>
Elemento EnumType (CSDL)

El elemento enumType representa un tipo enumerado.
Un elemento enumType puede tener los elementos secundarios siguientes (en el orden mostrado):
Miembro (cero o más elementos)
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento enumType .
Nombre Sí El nombre del tipo de entidad.
IsFlags No True o false , dependiendo de si el tipo

de enumeración se puede usar como un
conjunto de marcas. El valor
predeterminado es false.
UnderlyingType No EDM. Byte , EDM. Int16 , EDM.

Int32 , EDM. Int64 o EDM. SByte
que define el intervalo de valores del
tipo. El tipo subyacente
predeterminado de los elementos de
enumeración es EDM. Int32. .
NOTE
Se puede aplicar cualquier número de atributos de anotación (atributos XML personalizados) al elemento enumType . Sin
Ejemplo
En el ejemplo siguiente se muestra un elemento enumType con tres elementos member :
<EnumType Name="Color" IsFlags=”false” UnderlyingTyp=”Edm.Byte”>

<Member Name="Red" />
<Member Name="Green" />
<Member Name="Blue" />
</EntityType>
Function (Elemento) (CSDL)

El elemento function en el lenguaje de definición de esquemas conceptuales (CSDL) se utiliza para definir o
declarar funciones en el modelo conceptual. Una función se define utilizando un elemento DefiningExpression.
Un elemento function puede tener los elementos secundarios siguientes (en el orden mostrado):
Parameter (cero o más elementos)
DefiningExpression (cero o un elemento)
ReturnType (función) (cero o un elemento)
Un tipo de valor devuelto para una función debe especificarse con el elemento ReturnType (function) o el atributo
ReturnType (consulte a continuación), pero no ambos. Los tipos de valores devueltos posibles son
EdmSimpleType, tipo de entidad, tipo complejo, tipo de fila o tipo ref (o una colección de uno de estos tipos).
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento de función .
Nombre Sí El nombre de la función.
ReturnType No El tipo devuelto por la función.

NOTE
Se puede aplicar cualquier número de atributos de anotación (atributos XML personalizados) al elemento de función . Sin
Ejemplo
En el ejemplo siguiente se usa un elemento function para definir una función que devuelve el número de años
transcurridos desde que se contrató a un instructor.
<Function Name="YearsSince" ReturnType="Edm.Int32">

<Parameter Name="date" Type="Edm.DateTime" />
Year(CurrentDateTime()) - Year(date)
</Function>
FunctionImport (Elemento) (CSDL)

El elemento FunctionImpor t del lenguaje de definición de esquemas conceptuales (CSDL) representa una función
que se define en el origen de datos, pero que está disponible para los objetos a través del modelo conceptual. Por
ejemplo, un elemento Function del modelo de almacenamiento se puede usar para representar un procedimiento
almacenado en una base de datos. Un elemento FunctionImpor t del modelo conceptual representa la función
correspondiente en una aplicación Entity Framework y se asigna a la función de modelo de almacenamiento
mediante el elemento FunctionImportMapping. Cuando se llama a la función en la aplicación, el procedimiento
almacenado correspondiente se ejecuta en la base de datos.
El elemento FunctionImpor t puede tener los elementos secundarios siguientes (en el orden mostrado):
Parameter (cero o más elementos)
ReturnType (FunctionImport) (cero o más elementos permitidos)
Debe definirse un elemento de parámetro para cada parámetro aceptado por la función.
Un tipo de valor devuelto para una función debe especificarse con el elemento ReturnType (FunctionImport) o el
atributo ReturnType (consulte a continuación), pero no ambos. El valor de tipo devuelto debe ser una colección de
EdmSimpleType, EntityType o ComplexType.
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento FunctionImpor t .
Nombre Sí Nombre de la función importada.

ReturnType No Tipo devuelto por la función. No utilice

este atributo si la función no devuelve
un valor. De lo contrario, el valor debe
ser una colección de ComplexType,
EntityType o EDMSimpleType.
#A4 No Si la función devuelve una colección de

tipos de entidad, el valor de EntitySet
debe ser el conjunto de entidades al
que pertenece la colección. De lo
contrario, el atributo EntitySet no
debe usarse.
IsComposable No Si el valor se establece en true, la

función es ajustable (función con
valores de tabla) y se puede usar en
una consulta LINQ. El valor
predeterminado es false .
NOTE
Se puede aplicar cualquier número de atributos de anotación (atributos XML personalizados) al elemento FunctionImpor t .
Ejemplo
En el ejemplo siguiente se muestra un elemento FunctionImpor t que acepta un parámetro y devuelve una
colección de tipos de entidad:
<FunctionImport Name="GetStudentGrades"
EntitySet="StudentGrade"
ReturnType="Collection(SchoolModel.StudentGrade)">
<Parameter Name="StudentID" Mode="In" Type="Int32" />
</FunctionImport>
Key (Elemento) (CSDL)

El elemento key es un elemento secundario del elemento EntityType y define una clave de entidad (una propiedad
o un conjunto de propiedades de un tipo de entidad que determinan la identidad). Las propiedades que
constituyen una entidad se eligen en tiempo de diseño. Los valores de las propiedades de clave de entidad deben
identificar de forma inequívoca en tiempo de ejecución una instancia de tipo de entidad dentro de un conjunto de
entidades. Las propiedades que constituyen una clave de entidad se deben elegir de tal forma que garanticen la
unicidad de las instancias de un conjunto de entidades. El elemento key define una clave de entidad haciendo
referencia a una o más de las propiedades de un tipo de entidad.
El elemento key puede tener los siguientes elementos secundarios:
Se puede aplicar cualquier número de atributos de anotación (atributos XML personalizados) al elemento key . Sin
embargo, es posible que los atributos personalizados no pertenezcan a ningún espacio de nombres XML
reservado para CSDL. Dos atributos personalizados cualesquiera no pueden tener nombres completos idénticos.
Ejemplo
En el ejemplo siguiente se define un tipo de entidad denominado book . La clave de entidad se define haciendo
referencia a la propiedad ISBN del tipo de entidad.
<Key>
</Key>
</EntityType>
La propiedad ISBN es una buena elección para la clave de entidad porque un número de libro estándar
internacional (ISBN) identifica de forma única un libro.
En el ejemplo siguiente se muestra un tipo de entidad (autor ) que tiene una clave de entidad que consta de dos
propiedades, nombre y Dirección .
<EntityType Name="Author">
<Key>
<PropertyRef Name="Name" />
<PropertyRef Name="Address" />
</Key>
<Property Type="String" Name="Address" Nullable="false" />
<NavigationProperty Name="Books" Relationship="BooksModel.WrittenBy"
FromRole="Author" ToRole="Book" />
</EntityType>
Usar el nombre y la Dirección de la clave de entidad es una opción razonable, ya que es poco probable que dos
autores del mismo nombre se encuentren en la misma dirección. Sin embargo, esta opción no garantiza por
completo la existencia de claves de entidad únicas en un conjunto de entidades. En este caso, se recomienda
agregar una propiedad, como AuthorId , que pueda usarse para identificar de forma única un autor.
Elemento Member (CSDL)

El elemento member es un elemento secundario del elemento enumType y define un miembro del tipo
enumerado.
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento FunctionImpor t .
Nombre Sí Nombre del miembro.
Valor No Valor del miembro. De forma

predeterminada, el primer miembro
tiene el valor 0 y el valor de cada
enumerador sucesivo se incrementa en
1. Pueden existir varios miembros con
los mismos valores.
NOTE
Se puede aplicar cualquier número de atributos de anotación (atributos XML personalizados) al elemento FunctionImpor t .
Ejemplo
En el ejemplo siguiente se muestra un elemento enumType con tres elementos member :
<EnumType Name="Color">
<Member Name="Red" Value=”1”/>
<Member Name="Green" Value=”3” />
<Member Name="Blue" Value=”5”/>
</EntityType>
Elemento NavigationProperty (CSDL)

Un elemento NavigationProper ty define una propiedad de navegación, que proporciona una referencia al otro
extremo de una asociación. A diferencia de las propiedades definidas con el elemento Property, las propiedades de
navegación no definen la forma ni las características de los datos. Proporcionan una manera de desplazarse por
una asociación entre dos tipos de entidad.
Las propiedades de navegación son opcionales en los dos tipos de entidad de los extremos de una asociación. Si
define una propiedad de navegación en un tipo de entidad del extremo de una asociación, no tiene que definir una
propiedad de navegación en el tipo de entidad del otro extremo de la asociación.
El tipo de datos devuelto por una propiedad de navegación viene determinado por la multiplicidad de su extremo
remoto de la asociación. Por ejemplo, supongamos que existe una propiedad de navegación, OrdersNavProp , en
un tipo de entidad Customer y navega por una asociación uno a varios entre Customer y Order . Dado que el
extremo remoto de la Asociación para la propiedad de navegación tiene una multiplicidad de muchos (*), su tipo
de datos es una colección (de orden ). Del mismo modo, si una propiedad de navegación, CustomerNavProp ,
existe en el tipo de entidad Order , su tipo de datos sería Customer , ya que la multiplicidad del extremo remoto
es uno (1).
Un elemento NavigationProper ty puede tener los elementos secundarios siguientes (en el orden mostrado):
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento NavigationProper ty .
Nombre Sí El nombre de la propiedad de

navegación.
Vínculo Sí Nombre de una asociación que se

encuentra dentro del ámbito del
modelo.
ToRole Sí Extremo de la asociación en el que

finaliza la navegación. El valor del
atributo ToRole debe ser el mismo que
el valor de uno de los atributos de rol
definidos en uno de los extremos de la
Asociación (definidos en el elemento
AssociationEnd).
FromRole Sí Extremo de la asociación desde el que

comienza la navegación. El valor del
atributo FromRole debe ser el mismo
que el valor de uno de los atributos de
rol definidos en uno de los extremos de
la Asociación (definidos en el elemento
AssociationEnd).
NOTE
NavigationProper ty . Sin embargo, es posible que los atributos personalizados no pertenezcan a ningún espacio de
nombres XML reservado para CSDL. Dos atributos personalizados cualesquiera no pueden tener nombres completos
idénticos.
Ejemplo
En el ejemplo siguiente se define un tipo de entidad (book ) con dos propiedades de navegación (PublishedBy y
WrittenBy ):
<Key>
</Key>
</EntityType>
OnDelete (Elemento) (CSDL)

El elemento aldelete en el lenguaje de definición de esquemas conceptuales (CSDL) define el comportamiento
que está conectado a una asociación. Si el atributo Action se establece en Cascade en un extremo de una
asociación, los tipos de entidad relacionados en el otro extremo de la asociación se eliminan cuando se elimina el
tipo de entidad del primer extremo. Si la asociación entre dos tipos de entidad es una relación entre clave principal
y clave principal, se elimina un objeto dependiente cargado cuando se elimina el objeto de entidad de seguridad
del otro extremo de la asociación, independientemente de la especificación de la eliminación .
NOTE
El elemento aldelete solo afecta al comportamiento de tiempo de ejecución de una aplicación; no afecta al comportamiento
en el origen de datos. El comportamiento definido en el origen de datos debe ser igual que el definido en la aplicación.
Un elemento aldelete puede tener los elementos secundarios siguientes (en el orden mostrado):
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento aleliminar .
Acción Sí Cascade o None . Si en cascada , los

tipos de entidad dependientes se
eliminarán cuando se elimine el tipo de
entidad de entidad de seguridad. Si no
hay ninguno , los tipos de entidad
dependientes no se eliminarán cuando
se elimine el tipo de entidad de entidad
de seguridad.
NOTE
Ejemplo
En el ejemplo siguiente se muestra un elemento Association que define la Asociación CustomerOrders . El
elemento aleliminar indica que todos los pedidos relacionados con un cliente determinado y que se han
cargado en el ObjectContext se eliminarán cuando se elimine el cliente .
<End Type="ExampleModel.Customer" Role="Customer" Multiplicity="1">
</End>
</Association>
Parameter (Elemento) (CSDL)

El elemento Parameter en el lenguaje de definición de esquemas conceptuales (CSDL) puede ser un elemento
secundario del elemento FunctionImport o del elemento function.
Aplicación para el elemento FunctionImport
Un elemento Parameter (como elemento secundario del elemento FunctionImpor t ) se usa para definir los
parámetros de entrada y salida para las importaciones de funciones que se declaran en CSDL.
El elemento Parameter puede tener los elementos secundarios siguientes (en el orden mostrado):
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento Parameter .
Nombre Sí El nombre del parámetro.
Tipo Sí El tipo de parámetro. El valor tiene que

ser un tipo EDMSimpleType o un tipo
complejo que se encuentre dentro del
ámbito del modelo.
Modo No In , out o INOUT dependiendo de si el

parámetro es un parámetro de entrada,
de salida o de entrada/salida.
MaxLength No La longitud máxima permitida del

parámetro.
Precisión No La precisión del parámetro.
Escala No La escala del parámetro.

espacial. Válido solo para los
parámetros de los tipos espaciales. Para
obtener más información, vea SRID y
SRID (SQL Server).
NOTE
Se puede aplicar cualquier número de atributos de anotación (atributos XML personalizados) al elemento Parameter . Sin
Ejemplo
En el ejemplo siguiente se muestra un elemento FunctionImpor t con un elemento secundario Parameter . La
función acepta un parámetro de entrada y devuelve una colección de tipos de entidad.
<FunctionImport Name="GetStudentGrades"
EntitySet="StudentGrade"
</FunctionImport>
Aplicación para el elemento Function

Un elemento Parameter (como elemento secundario del elemento function ) define los parámetros de las
funciones que se definen o declaran en un modelo conceptual.
CollectionType (cero o un elemento)
ReferenceType (cero o un elemento)
RowType (cero o un elemento)
NOTE
Solo uno de los elementos CollectionType , referenceType o RowType puede ser un elemento secundario de un elemento
Proper ty .

NOTE
Los elementos de anotación deben aparecer después de todos los demás elementos secundarios. Los elementos Annotation
solo se permiten en CSDL V2 y versiones posteriores.
Tipo No El tipo de parámetro. Un parámetro

puede ser de cualquiera de los
siguientes tipos (o colecciones de estos
tipos):
EdmSimpleType
tipo de entidad
tipo complejo
tipo de fila
tipo de referencia
Admisión de valores NULL No True (valor predeterminado) o false ,

dependiendo de si la propiedad puede
tener un valor null .

propiedad.


Para obtener más información, vea SRID
y SRID (SQL Server).


de datos.
NOTE
Ejemplo
En el ejemplo siguiente se muestra un elemento de función que usa un elemento secundario Parameter para
definir un parámetro de función.
<Function Name="GetYearsEmployed" ReturnType="Edm.Int32">

<Parameter Name="Instructor" Type="SchoolModel.Person" />
Year(CurrentDateTime()) - Year(cast(Instructor.HireDate as DateTime))
</Function>
Principal (Elemento) (CSDL)

El elemento principal del lenguaje de definición de esquemas conceptuales (CSDL) es un elemento secundario del
elemento ReferentialConstraint que define el extremo principal de una restricción referencial. Un elemento
ReferentialConstraint define una funcionalidad similar a una restricción de integridad referencial en una base de
datos relacional. Del mismo modo que una columna (o columnas) de una tabla de base de datos puede hacer
referencia a la clave principal de otra tabla, una propiedad (o propiedades) de un tipo de entidad puede hacer
referencia a la clave de entidad de otro tipo de entidad. El tipo de entidad al que se hace referencia se denomina
extremo principal de la restricción. El tipo de entidad que hace referencia al extremo principal se denomina
extremo dependiente de la restricción. Los elementos Proper tyRef se utilizan para especificar las claves a las que
hace referencia el extremo dependiente.
El elemento principal puede tener los elementos secundarios siguientes (en el orden mostrado):
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento principal .
Rol Sí Nombre del tipo de entidad del extremo

principal de la asociación.
NOTE
Se puede aplicar cualquier número de atributos de anotación (atributos XML personalizados) al elemento principal . Sin
Ejemplo
En el ejemplo siguiente se muestra un elemento ReferentialConstraint que forma parte de la definición de la
Asociación PublishedBy . La propiedad ID del tipo de entidad Publisher constituye el extremo principal de la
restricción referencial.
</End>
</Principal>
</Dependent>
</Association>
Property (Elemento) (CSDL)

El elemento Proper ty del lenguaje de definición de esquemas conceptuales (CSDL) puede ser un elemento
secundario del elemento EntityType, el elemento complexType o el elemento RowType.
Aplicaciones de elemento EntityType y ComplexType
Los elementos de propiedad (como elementos secundarios de los elementos EntityType o complexType )
definen la forma y las características de los datos que contendrá una instancia de tipo de entidad o una instancia
de tipo complejo. Las propiedades en un modelo conceptual son análogas a las propiedades que se definen en una
clase. Del mismo modo que las propiedades en una clase definen la forma de la clase y proporcionan información
sobre los objetos, las propiedades en un modelo conceptual definen la forma de un tipo de entidad y proporcionan
información sobre las instancias del tipo de entidad.
El elemento Proper ty puede tener los elementos secundarios siguientes (en el orden mostrado):
Elemento Documentation (cero o un elemento permitidos)
Las siguientes caras se pueden aplicar a un elemento Proper ty : Nullable , DefaultValue , MaxLength ,
FixedLength , Precision , Scale , Unicode , collation , ConcurrencyMode . Las facetas son atributos XML que
proporcionan información sobre cómo los valores de propiedad se almacenan en el almacén de datos.
NOTE
Las caras solo se pueden aplicar a propiedades de tipo EDMSimpleType .
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento Proper ty .
Nombre Sí El nombre de la propiedad.
Tipo Sí El tipo de valor de la propiedad. El tipo

de valor de la propiedad debe ser un
tipo EDMSimpleType o un tipo
complejo (indicado mediante un
nombre completo) que se encuentre
dentro del ámbito del modelo.

valor nulo.
[!NOTE]
> En el CSDL v1, una propiedad de tipo

complejo debe tener
Nullable="False" .

propiedad.




de datos.
ConcurrencyMode No None (el valor predeterminado) o

Fixed . Si el valor se establece en Fixed ,
el valor de la propiedad se usará en las
comprobaciones de simultaneidad
optimista.
NOTE
Se puede aplicar cualquier número de atributos de anotación (atributos XML personalizados) al elemento de propiedad . Sin
Ejemplo
En el ejemplo siguiente se muestra un elemento EntityType con tres elementos Proper ty :
<Key>
</Key>
</EntityType>
En el ejemplo siguiente se muestra un elemento complexType con cinco elementos Proper ty :
<ComplexType Name="Address" >

<Property Type="String" Name="StreetAddress" Nullable="false" />
<Property Type="String" Name="City" Nullable="false" />
<Property Type="String" Name="StateOrProvince" Nullable="false" />
<Property Type="String" Name="Country" Nullable="false" />
<Property Type="String" Name="PostalCode" Nullable="false" />
</ComplexType>
Aplicación de elemento RowType

Los elementos de propiedad (como elementos secundarios de un elemento RowType ) definen la forma y las
características de los datos que se pueden pasar o devolver desde una función definida por el modelo.
El elemento Proper ty puede tener exactamente uno de los siguientes elementos secundarios:
CollectionType
ReferenceType
RowType
El elemento Proper ty puede tener cualquier número de elementos Annotation secundarios.
NOTE
Los elementos Annotation solo se permiten en CSDL V2 y versiones posteriores.
Nombre Sí El nombre de la propiedad.
Tipo Sí El tipo de valor de la propiedad.

valor nulo.
[!NOTE]

complejo debe tener
Nullable="False" .

propiedad.




de datos.
NOTE
Se puede aplicar cualquier número de atributos de anotación (atributos XML personalizados) al elemento de propiedad . Sin
Ejemplo
En el ejemplo siguiente se muestran los elementos de propiedad que se utilizan para definir la forma del tipo de
valor devuelto de una función definida por el modelo.
<ReturnType>
<CollectionType>
<RowType>
</RowType>
</CollectionType>
</ReturnType>
</Function>
PropertyRef (Elemento) (CSDL)

El elemento Proper tyRef en el lenguaje de definición de esquemas conceptuales (CSDL) hace referencia a una
propiedad de un tipo de entidad para indicar que la propiedad realizará uno de los roles siguientes:
Parte de la clave de la entidad (una propiedad o un conjunto de propiedades de un tipo de entidad que
determinan la identidad). Se pueden usar uno o varios elementos Proper tyRef para definir una clave de
entidad.
El extremo dependiente o principal de una restricción referencial.
El elemento Proper tyRef solo puede tener elementos Annotation (cero o más) como elementos secundarios.
NOTE
Los elementos Annotation solo se permiten en CSDL V2 y versiones posteriores.
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento Proper tyRef .
Nombre Sí Nombre de la propiedad a la que se

hace referencia.
NOTE
Se puede aplicar cualquier número de atributos de anotación (atributos XML personalizados) al elemento Proper tyRef . Sin
Ejemplo
En el ejemplo siguiente se define un tipo de entidad (book ). La clave de entidad se define haciendo referencia a la
propiedad ISBN del tipo de entidad.
<Key>
</Key>
</EntityType>
En el ejemplo siguiente, se usan dos elementos Proper tyRef para indicar que dos propiedades (ID y PublisherId )
son los extremos principal y dependiente de una restricción referencial.
</End>
</Principal>
</Dependent>
</Association>
ReferenceType (Elemento) (CSDL)

El elemento referenceType en el lenguaje de definición de esquemas conceptuales (CSDL) especifica una
referencia a un tipo de entidad. El elemento referenceType puede ser un elemento secundario de los siguientes
elementos:
ReturnType (función)
Parámetro
CollectionType
El elemento referenceType se utiliza al definir un parámetro o un tipo de valor devuelto para una función.
Un elemento referenceType puede tener los elementos secundarios siguientes (en el orden mostrado):
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento referenceType .
Tipo Sí Nombre del tipo de entidad al que se

hace referencia.
NOTE
Se puede aplicar cualquier número de atributos de anotación (atributos XML personalizados) al elemento referenceType .
Ejemplo
En el ejemplo siguiente se muestra el elemento referenceType que se usa como elemento secundario de un
elemento Parameter en una función definida por el modelo que acepta una referencia a un tipo de entidad
Person :
<Function Name="GetYearsEmployed" ReturnType="Edm.Int32">

<Parameter Name="instructor">
<ReferenceType Type="SchoolModel.Person" />
</Parameter>
Year(CurrentDateTime()) - Year(cast(instructor.HireDate as DateTime))
</Function>
En el ejemplo siguiente se muestra el elemento referenceType usado como elemento secundario de un elemento
ReturnType (function) en una función definida por el modelo que devuelve una referencia a un tipo de entidad
Person :
<Function Name="GetPersonReference">
<Parameter Name="p" Type="SchoolModel.Person" />
<ReturnType>
<ReferenceType Type="SchoolModel.Person" />
</ReturnType>
REF(p)
</Function>
ReferentialConstraint (Elemento) (CSDL)

Un elemento ReferentialConstraint en el lenguaje de definición de esquemas conceptuales (CSDL) define una
funcionalidad similar a una restricción de integridad referencial en una base de datos relacional. Del mismo modo
que una columna (o columnas) de una tabla de base de datos puede hacer referencia a la clave principal de otra
tabla, una propiedad (o propiedades) de un tipo de entidad puede hacer referencia a la clave de entidad de otro
tipo de entidad. El tipo de entidad al que se hace referencia se denomina extremo principal de la restricción. El tipo
de entidad que hace referencia al extremo principal se denomina extremo dependiente de la restricción.
Si una clave externa que se expone en un tipo de entidad hace referencia a una propiedad en otro tipo de entidad,
el elemento ReferentialConstraint define una asociación entre los dos tipos de entidad. Dado que el elemento
ReferentialConstraint proporciona información sobre cómo se relacionan dos tipos de entidad, no es necesario
ningún elemento AssociationSetMapping correspondiente en el lenguaje de especificación de asignaciones (MSL).
Una asociación entre dos tipos de entidad que no tienen claves externas expuestas debe tener un elemento
AssociationSetMapping correspondiente para asignar información de asociación al origen de datos.
Si una clave externa no se expone en un tipo de entidad, el elemento ReferentialConstraint solo puede definir
una restricción PRIMARY KEY-PRIMARY KEY entre el tipo de entidad y otro tipo de entidad.
Un elemento ReferentialConstraint puede tener los elementos secundarios siguientes (en el orden mostrado):
Principal (exactamente un elemento)
Dependent (exactamente un elemento)
El elemento ReferentialConstraint puede tener cualquier número de atributos de anotación (atributos XML
personalizados). Sin embargo, es posible que los atributos personalizados no pertenezcan a ningún espacio de
Ejemplo
En el ejemplo siguiente se muestra un elemento ReferentialConstraint que se usa como parte de la definición de
la Asociación PublishedBy .
</End>
</Principal>
</Dependent>
</Association>
ReturnType (function) (elemento) (CSDL)

El elemento ReturnType (function) en el lenguaje de definición de esquemas conceptuales (CSDL) especifica el
tipo de valor devuelto para una función que se define en un elemento de función. Un tipo de valor devuelto de
función también se puede especificar con un atributo ReturnType .
Los tipos de valor devuelto pueden ser cualquier EdmSimpleType , tipo de entidad, tipo complejo, tipo de fila, tipo
de referencia o una colección de uno de estos tipos.
El tipo de valor devuelto de una función se puede especificar con el atributo Type del elemento ReturnType
(function) o con uno de los siguientes elementos secundarios:
CollectionType
ReferenceType
RowType
NOTE
Un modelo no se validará si especifica un tipo de valor devuelto de función con el atributo Type del elemento ReturnType
(function) y uno de los elementos secundarios.
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento ReturnType (function).
ReturnType No El tipo devuelto por la función.
NOTE
Se puede aplicar cualquier número de atributos de anotación (atributos XML personalizados) al elemento ReturnType
(function). Sin embargo, es posible que los atributos personalizados no pertenezcan a ningún espacio de nombres XML
reservado para CSDL. Dos atributos personalizados cualesquiera no pueden tener nombres completos idénticos.
Ejemplo
En el ejemplo siguiente se usa un elemento function para definir una función que devuelve el número de años
que un libro se ha impreso. Tenga en cuenta que el tipo de valor devuelto se especifica mediante el atributo Type
de un elemento ReturnType (function).
<Function Name="GetYearsInPrint">
<ReturnType Type=="Edm.Int32">
<Parameter Name="book" Type="BooksModel.Book" />
Year(CurrentDateTime()) - Year(cast(book.PublishedDate as DateTime))
</Function>
ReturnType (FunctionImport) (elemento) (CSDL)

El elemento ReturnType (FunctionImport) en el lenguaje de definición de esquemas conceptuales (CSDL)
especifica el tipo de valor devuelto para una función que se define en un elemento FunctionImport. Un tipo de
valor devuelto de función también se puede especificar con un atributo ReturnType .
Los tipos devueltos pueden ser cualquier colección de tipo de entidad, tipo complejo o EdmSimpleType .
El tipo de valor devuelto de una función se especifica con el atributo Type del elemento ReturnType
(FunctionImport).
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento ReturnType (FunctionImport).
Tipo No Tipo devuelto por la función. El valor

debe ser una colección de ComplexType,
EntityType o EDMSimpleType.
#A4 No Si la función devuelve una colección de

tipos de entidad, el valor de EntitySet
debe ser el conjunto de entidades al
que pertenece la colección. De lo
contrario, el atributo EntitySet no
debe usarse.
NOTE
Se puede aplicar cualquier número de atributos de anotación (atributos XML personalizados) al elemento ReturnType
(FunctionImport). Sin embargo, es posible que los atributos personalizados no pertenezcan a ningún espacio de nombres
XML reservado para CSDL. Dos atributos personalizados cualesquiera no pueden tener nombres completos idénticos.
Ejemplo
En el ejemplo siguiente se usa una FunctionImpor t que devuelve libros y publicadores. Tenga en cuenta que la
función devuelve dos conjuntos de resultados y, por tanto, se especifican dos elementos ReturnType
(FunctionImport).
<FunctionImport Name="GetBooksAndPublishers">
<ReturnType Type=="Collection(BooksModel.Book )" EntitySet=”Books”>
<ReturnType Type=="Collection(BooksModel.Publisher)" EntitySet=”Publishers”>
</FunctionImport>
RowType (Elemento) (CSDL)

Un elemento RowType en el lenguaje de definición de esquemas conceptuales (CSDL) define una estructura sin
nombre como un parámetro o tipo de valor devuelto para una función definida en el modelo conceptual.
Un elemento RowType puede ser el elemento secundario de los siguientes elementos:
CollectionType
Parámetro
ReturnType (función)
Un elemento RowType puede tener los elementos secundarios siguientes (en el orden mostrado):
Property (uno o varios)
Elementos Annotation (cero o más)
RowType . Sin embargo, es posible que los atributos personalizados no pertenezcan a ningún espacio de nombres
XML reservado para CSDL. Dos atributos personalizados cualesquiera no pueden tener nombres completos
idénticos.
Ejemplo
para especificar que la función devuelve una colección de filas (tal y como se especifica en el elemento RowType ).
<ReturnType>
<CollectionType>
<RowType>
</RowType>
</CollectionType>
</ReturnType>
</Function>
Schema (Elemento) (CSDL)

El elemento Schema es el elemento raíz de una definición de modelo conceptual. Contiene las definiciones para
los objetos, las funciones y los contenedores que conforman un modelo conceptual.
El elemento Schema puede contener cero o más de los siguientes elementos secundarios:
Uso
EntityContainer
EntityType
EnumType
Asociación
ComplexType
Función
Un elemento Schema puede contener cero o un elemento Annotation.
NOTE
El elemento de función y los elementos de anotación solo se permiten en CSDL V2 y versiones posteriores.
El elemento Schema usa el atributo namespace para definir el espacio de nombres para el tipo de entidad, el tipo
complejo y los objetos de Asociación de un modelo conceptual. Dentro de un espacio de nombres, no puede haber
dos objetos con el mismo nombre. Los espacios de nombres pueden abarcar varios elementos de esquema y
varios archivos. CSDL.
Un espacio de nombres del modelo conceptual es diferente del espacio de nombres XML del elemento Schema .
Un espacio de nombres del modelo conceptual (tal y como se define en el atributo de espacio de nombres ) es
un contenedor lógico para tipos de entidad, tipos complejos y tipos de asociación. El espacio de nombres XML
(indicado por el atributo xmlns ) de un elemento Schema es el espacio de nombres predeterminado para los
elementos secundarios y los atributos del elemento Schema . Los espacios de nombres XML con el formato
https://schemas.microsoft.com/ado/YYYY/MM/edm (donde YYYY y MM representan un año y un mes
respectivamente) se reservan para CSDL. No puede haber elementos y atributos personalizados en espacios de
nombres que tengan este formato.
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento Schema .
Espacio de nombres Sí El espacio de nombres del modelo

conceptual. El valor del atributo
namespace se usa para formar el
nombre completo de un tipo. Por
ejemplo, si un EntityType denominado
Customer está en el espacio de
nombres simple. example. Model, el
nombre completo del EntityType es
SimpleExampleModel. Customer.
Las siguientes cadenas no se pueden
usar como el valor del atributo
namespace : System , Transient o
EDM . El valor del atributo namespace
no puede ser el mismo que el valor del
atributo namespace del elemento
Schema de SSDL.
Alias No Un identificador usado en lugar del

nombre del espacio de nombres. Por
nombres simple. example. Model y el
valor del atributo alias es Model, puede
usar Model. Customer como nombre
completo del EntityType.
NOTE
Se puede aplicar cualquier número de atributos de anotación (atributos XML personalizados) al elemento Schema . Sin
Ejemplo
En el ejemplo siguiente se muestra un elemento Schema que contiene un elemento EntityContainer , dos
elementos EntityType y un elemento Association .
<Schema xmlns="https://schemas.microsoft.com/ado/2009/11/edm"
xmlns:cg="https://schemas.microsoft.com/ado/2009/11/codegeneration"
xmlns:store="https://schemas.microsoft.com/ado/2009/11/edm/EntityStoreSchemaGenerator"
Namespace="ExampleModel" Alias="Self">
<EntityContainer Name="ExampleModelContainer">
<EntitySet Name="Customers"
EntityType="ExampleModel.Customer" />
<EntitySet Name="Orders" EntityType="ExampleModel.Order" />
<AssociationSet
Name="CustomerOrder"
Association="ExampleModel.CustomerOrders">
<End Role="Customer" EntitySet="Customers" />
<End Role="Order" EntitySet="Orders" />
</AssociationSet>
</EntityContainer>
<EntityType Name="Customer">
<Key>
</Key>
<NavigationProperty
Name="Orders"
Relationship="ExampleModel.CustomerOrders"
FromRole="Customer" ToRole="Order" />
</EntityType>
<EntityType Name="Order">
<Key>
<PropertyRef Name="OrderId" />
</Key>
<Property Type="Int32" Name="OrderId" Nullable="false" />
<Property Type="Int32" Name="ProductId" Nullable="false" />
<Property Type="Int32" Name="Quantity" Nullable="false" />
<NavigationProperty
Name="Customer"
Relationship="ExampleModel.CustomerOrders"
FromRole="Order" ToRole="Customer" />
</EntityType>
<End Type="ExampleModel.Customer"
Role="Customer" Multiplicity="1" />
<End Type="ExampleModel.Order"
Role="Order" Multiplicity="*" />
<Principal Role="Customer">
</Principal>
<Dependent Role="Order">
</Dependent>
</Association>
</Schema>
TypeRef (Elemento) (CSDL)

El elemento TypeRef en el lenguaje de definición de esquemas conceptuales (CSDL) proporciona una referencia a
un tipo con nombre existente. El elemento TypeRef puede ser un elemento secundario del elemento
CollectionType, que se usa para especificar que una función tiene una colección como parámetro o tipo de valor
devuelto.
Un elemento TypeRef puede tener los elementos secundarios siguientes (en el orden mostrado):
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento TypeRef . Tenga en cuenta que
los atributos DefaultValue , MaxLength , FixedLength , Precision , Scale , Unicode y collation solo se aplican a
EDMSimpleTypes .
Tipo No El nombre del tipo al que se hace

referencia.

valor nulo.
[!NOTE]

complejo debe tener
Nullable="False" .

propiedad.




de datos.
NOTE
Ejemplo
En el ejemplo siguiente se muestra una función definida por el modelo que usa el elemento TypeRef (como
elemento secundario de un elemento CollectionType ) para especificar que la función acepta una colección de
tipos de entidad Depar tment .
<Function Name="GetAvgBudget">
<Parameter Name="Departments">
<CollectionType>
<TypeRef Type="SchoolModel.Department"/>
</CollectionType>
</Parameter>
<ReturnType Type="Collection(Edm.Decimal)"/>
SELECT VALUE AVG(d.Budget) FROM Departments AS d
</Function>
Using (Elemento) (CSDL)

El elemento using del lenguaje de definición de esquemas conceptuales (CSDL) importa el contenido de un
modelo conceptual que existe en un espacio de nombres diferente. Al establecer el valor del atributo de espacio
de nombres , puede hacer referencia a los tipos de entidad, tipos complejos y tipos de asociación que se definen
en otro modelo conceptual. Más de un elemento using puede ser un elemento secundario de un elemento
Schema .
NOTE
El elemento using en CSDL no funciona exactamente igual que una instrucción using en un lenguaje de programación. Al
importar un espacio de nombres con una instrucción using en un lenguaje de programación, no afecta a los objetos del
espacio de nombres original. En CSDL, un espacio de nombres importado puede contener un tipo de entidad derivado de un
tipo de entidad del espacio de nombres original. Esto puede afectar a los conjuntos de entidades declarados en el espacio de
nombres original.
El elemento using puede tener los siguientes elementos secundarios:

En la tabla siguiente se describen los atributos que se pueden aplicar al elemento using .
Espacio de nombres Sí Nombre del espacio de nombres

importado.
Alias Sí Un identificador usado en lugar del

nombre del espacio de nombres.
Aunque este atributo es obligatorio, no
es necesario usarlo en lugar del nombre
del espacio de nombres para calificar los
nombres de los objetos.
NOTE
Se puede aplicar cualquier número de atributos de anotación (atributos XML personalizados) al elemento using . Sin
Ejemplo
En el ejemplo siguiente se muestra el elemento using que se usa para importar un espacio de nombres que se
define en otro lugar. Tenga en cuenta que el espacio de nombres para el elemento de esquema que se muestra es
BooksModel . La propiedad Address en el Publisher EntityType es un tipo complejo que se define en el espacio de
nombres ExtendedBooksModel (importado con el elemento using ).
<Schema xmlns="https://schemas.microsoft.com/ado/2009/11/edm"
xmlns:cg="https://schemas.microsoft.com/ado/2009/11/codegeneration"
xmlns:store="https://schemas.microsoft.com/ado/2009/11/edm/EntityStoreSchemaGenerator"
Namespace="BooksModel" Alias="Self">
<Using Namespace="BooksModel.Extended" Alias="BMExt" />

</EntityContainer>
<EntityType Name="Publisher">
<Key>
</Key>
<Property Type="Int32" Name="Id" Nullable="false" />
<Property Type="BMExt.Address" Name="Address" Nullable="false" />
</EntityType>
</Schema>
Atributos de anotación (CSDL)

En el lenguaje de definición de esquemas conceptuales (CSDL), los atributos de anotación son atributos XML
personalizados del modelo conceptual. Además de tener una estructura XML válida, los atributos de anotación
deben cumplir las condiciones siguientes:
Los atributos de anotación no deben estar en ningún espacio de nombres XML reservado para CSDL.
Se pueden aplicar varios atributos de anotación a un elemento CSDL determinado.
Dos atributos de anotación cualesquiera no pueden tener el mismo nombre completo.
Los atributos de anotación se pueden usar para proporcionar metadatos adicionales sobre los elementos en un
modelo conceptual. Se puede tener acceso a los metadatos contenidos en los elementos Annotation en tiempo de
ejecución mediante el uso de clases en el espacio de nombres System. Data. Metadata. Edm.
Ejemplo
En el ejemplo siguiente se muestra un elemento EntityType con un atributo Annotation (CustomAttribute ). El
ejemplo también muestra un elemento Annotation aplicado al elemento de tipo de entidad.
<Schema Namespace="SchoolModel" Alias="Self"

xmlns:annotation="https://schemas.microsoft.com/ado/2009/02/edm/annotation"
xmlns="https://schemas.microsoft.com/ado/2009/11/edm">
<EntityContainer Name="SchoolEntities" annotation:LazyLoadingEnabled="true">
<EntitySet Name="People" EntityType="SchoolModel.Person" />
</EntityContainer>
<EntityType Name="Person" xmlns:p="http://CustomNamespace.com"
p:CustomAttribute="Data here.">
<Key>
<PropertyRef Name="PersonID" />
</Key>
<Property Name="PersonID" Type="Int32" Nullable="false"
annotation:StoreGeneratedPattern="Identity" />
<Property Name="LastName" Type="String" Nullable="false"
MaxLength="50" Unicode="true" FixedLength="false" />
<Property Name="FirstName" Type="String" Nullable="false"
<Property Name="HireDate" Type="DateTime" />
<Property Name="EnrollmentDate" Type="DateTime" />
<p:CustomElement>
Custom metadata.
</p:CustomElement>
</EntityType>
</Schema>
El siguiente código recupera los metadatos del atributo Annotation y los escribe en la consola:
EdmItemCollection collection = new EdmItemCollection("School.csdl");

MetadataWorkspace workspace = new MetadataWorkspace();
workspace.RegisterItemCollection(collection);
EdmType contentType;
workspace.TryGetType("Person", "SchoolModel", DataSpace.CSpace, out contentType);
if (contentType.MetadataProperties.Contains("http://CustomNamespace.com:CustomAttribute"))
{
MetadataProperty annotationProperty =
contentType.MetadataProperties["http://CustomNamespace.com:CustomAttribute"];
object annotationValue = annotationProperty.Value;
Console.WriteLine(annotationValue.ToString());
}
El código anterior supone que el archivo School.csdl está en el directorio de resultados del proyecto y que se han
agregado las siguientes instrucciones Imports y Using al proyecto:
using System.Data.Metadata.Edm;
Elementos Annotation (CSDL)

Los elementos Annotation en el lenguaje de definición de esquemas conceptuales (CSDL) son los elementos XML
personalizados del modelo conceptual. Además de tener una estructura XML válida, lo siguiente debe ser
verdadero para los elementos Annotation:
Los elementos Annotation no deben estar en un espacio de nombres XML que esté reservado para CSDL.
Más de un elemento Annotation puede ser un elemento secundario de un elemento CSDL determinado.
Los nombres completos de dos elementos Annotation cualesquiera no deben ser los mismos.
Los elementos Annotation deben aparecer después de todos los demás elementos secundarios de un elemento
CSDL determinado.
Los elementos Annotation pueden utilizarse para proporcionar metadatos adicionales sobre los elementos en un
modelo conceptual. A partir de la .NET Framework versión 4, se puede tener acceso a los metadatos contenidos en
los elementos Annotation en tiempo de ejecución mediante el uso de clases en el espacio de nombres System.
Data. Metadata. Edm.
Ejemplo
En el ejemplo siguiente se muestra un elemento EntityType con un elemento Annotation (CustomElement ). El
ejemplo también muestra un atributo de anotación aplicado al elemento de tipo de entidad.
<Schema Namespace="SchoolModel" Alias="Self"

xmlns:annotation="https://schemas.microsoft.com/ado/2009/02/edm/annotation"
xmlns="https://schemas.microsoft.com/ado/2009/11/edm">
<EntityContainer Name="SchoolEntities" annotation:LazyLoadingEnabled="true">
<EntitySet Name="People" EntityType="SchoolModel.Person" />
</EntityContainer>
<EntityType Name="Person" xmlns:p="http://CustomNamespace.com"
p:CustomAttribute="Data here.">
<Key>
</Key>
<Property Name="LastName" Type="String" Nullable="false"
<Property Name="FirstName" Type="String" Nullable="false"
<p:CustomElement>
Custom metadata.
</p:CustomElement>
</EntityType>
</Schema>
El siguiente código recupera los metadatos del elemento de anotación y los escribe en la consola:
EdmItemCollection collection = new EdmItemCollection("School.csdl");
MetadataWorkspace workspace = new MetadataWorkspace();
workspace.RegisterItemCollection(collection);
EdmType contentType;
workspace.TryGetType("Person", "SchoolModel", DataSpace.CSpace, out contentType);
if (contentType.MetadataProperties.Contains("http://CustomNamespace.com:CustomElement"))
{
MetadataProperty annotationProperty =
contentType.MetadataProperties["http://CustomNamespace.com:CustomElement"];
object annotationValue = annotationProperty.Value;
Console.WriteLine(annotationValue.ToString());
}
El código anterior supone que el archivo School.csdl está en el directorio de resultados del proyecto y que se han
agregado las siguientes instrucciones Imports y Using al proyecto:
using System.Data.Metadata.Edm;
Tipos de modelos conceptuales (CSDL)

El lenguaje de definición de esquemas conceptuales (CSDL) admite un conjunto de tipos de datos primitivos
abstractos, denominados EDMSimpleTypes , que definen propiedades en un modelo conceptual. Los
EDMSimpleTypes son proxies para los tipos de datos primitivos que se admiten en el entorno de
almacenamiento o de hospedaje.
En la tabla siguiente se enumeran los tipos de datos primitivos admitidos por CSDL. En la tabla también se
enumeran las caras que se pueden aplicar a cada EDMSimpleType .
EDM SIM P L ET Y P E DESC RIP C IÓ N FA C ETA S A P L IC A B L ES
EDM. Binar y Contiene datos binarios. MaxLength, FixedLength, Nullable,

Default
Edm.Boolean Contiene el valor true o false . Nullable, Default
EDM. Byte Contiene un valor entero de 8 bits sin Precision, Nullable, Default
signo.
EDM. DateTime Representa una fecha y hora. Precision, Nullable, Default
Edm.DateTimeOffset Contiene una fecha y hora como Precision, Nullable, Default

desplazamiento en minutos respecto de
GMT.
EDM. decimal Contiene un valor numérico con una Precision, Nullable, Default
precisión y escala fijas.
Edm.Double Contiene un número de punto flotante Precision, Nullable, Default

con una precisión de 15 dígitos
EDM. Float Contiene un número de punto flotante Precision, Nullable, Default

con una precisión de 7 dígitos.
EDM. GUID Contiene un identificador único de 16 Precision, Nullable, Default

bytes.
EDM. Int16 Contiene un valor entero de 16 bits con Precision, Nullable, Default
signo.
Edm.Int32 Contiene un valor entero de 32 bits con Precision, Nullable, Default

signo.
Edm.Int64 Contiene un valor entero de 64 bits con Precision, Nullable, Default

signo.
EDM. SByte Contiene un valor entero de 8 bits con Precision, Nullable, Default
signo.
Edm.String Contiene datos de caracteres. Unicode, FixedLength, MaxLength,

Collation, Precision, Nullable, Default
EDM. Time Contiene una hora del día. Precision, Nullable, Default
EDM. Geography Nullable, default, SRID
Edm.GeographyPoint Nullable, default, SRID
EDM. GeographyLineString Nullable, default, SRID
EDM. GeographyPolygon Nullable, default, SRID
EDM. GeographyMultiPoint Nullable, default, SRID
EDM. GeographyMultiLineString Nullable, default, SRID
EDM. GeographyMultiPolygon Nullable, default, SRID
EDM. GeographyCollection Nullable, default, SRID
EDM. Geometr y Nullable, default, SRID
EDM. Geometr yPoint Nullable, default, SRID
EDM. Geometr yLineString Nullable, default, SRID
EDM. Geometr yPolygon Nullable, default, SRID
EDM. Geometr yMultiPoint Nullable, default, SRID
EDM. Geometr yMultiLineString Nullable, default, SRID

EDM. Geometr yMultiPolygon Nullable, default, SRID
EDM. Geometr yCollection Nullable, default, SRID
Facets (CSDL)
En el lenguaje de definición de esquemas conceptuales (CSDL), las facetas representan restricciones en las
propiedades de tipos de entidad y tipos complejos. Las facetas aparecen como atributos XML en los elementos
CSDL siguientes:
Propiedad
TypeRef
Parámetro
En la tabla siguiente se describen las facetas que se admiten en CSDL. Todas las facetas son opcionales. El Entity
Framework usa algunas de las caras que se indican a continuación al generar una base de datos a partir de un
modelo conceptual.
NOTE
Para obtener información sobre los tipos de datos de un modelo conceptual, vea tipos de modelos conceptuales (CSDL).
SE UT IL IZ A PA RA L A
GEN ERA C IÓ N DE L A
FA C ETA DESC RIP C IÓ N SE A P L IC A A B A SE DE DATO S L A USA EL RUN T IM E.
Intercalación Especifica la secuencia Edm.String Sí No

de intercalación (o
secuencia de orden)
que se va a usar
cuando se realicen las
operaciones de
comparación y
ordenación sobre los
valores de la
propiedad.
ConcurrencyMode Indica que el valor de Todas las propiedades No Sí

propiedad se debería de EDMSimpleType
utilizar para las
comprobaciones de la
simultaneidad
optimista.
Valor Especifica el valor Todas las propiedades Sí Sí

predeterminado predeterminado de la de EDMSimpleType
propiedad si no se
proporciona ningún
valor al crear las
instancias.
FixedLength Especifica si la EDM. Binar y , EDM. Sí No

longitud del valor de String
propiedad puede
variar.
MaxLength Especifica la longitud EDM. Binar y , EDM. Sí No

máxima del valor de String
propiedad.
Admisión de Especifica si la Todas las propiedades Sí Sí

valores NULL propiedad puede de EDMSimpleType
tener un valor null .
Precisión Para las propiedades EDM. DateTime , Sí No

de tipo decimal, EDM.
especifica el número DateTimeOffset ,
de dígitos que puede EDM. decimal,
tener un valor de EDM. Time
propiedad. En el caso
de las propiedades de
tipo Time ,
DateTime y
DateTimeOffset ,
especifica el número
de dígitos para la
parte fraccionaria de
los segundos del
valor de propiedad.
Escala Especifica el número EDM. decimal Sí No

de dígitos que puede
haber a la derecha del
separador decimal
para el valor de
propiedad.
SRID Especifica el EDM. Geography, No Sí

identificador del EDM.
sistema espacial de GeographyPoint,
referencia del sistema. EDM.
Para obtener más GeographyLineStri
información, vea SRID ng, EDM.
y SRID (SQL Server). GeographyPolygon
, EDM.
GeographyMultiPoi
nt, EDM.
GeographyMultiLin
eString, EDM.
GeographyMultiPol
ygon, EDM.
GeographyCollecti
on, EDM.
Geometr y, EDM.
Geometr yPoint,
EDM.
Geometr yLineStrin
g, EDM.
Geometr yPolygon,
EDM.
Geometr yMultiPoi
nt, EDM.
Geometr yMultiLine
String, EDM.
Geometr yMultiPoly
gon, EDM.
Geometr yCollectio
n
Unicode Indica si el valor de Edm.String Sí Sí

propiedad está
almacenado como
Unicode.
NOTE
Al generar una base de datos a partir de un modelo conceptual, el Asistente para generar base de datos reconocerá el valor
del atributo StoreGeneratedPattern en un elemento Proper ty si está en el siguiente espacio de nombres:
https://schemas.microsoft.com/ado/2009/02/edm/annotation. Los valores admitidos para el atributo son Identity y
Computed . Un valor de Identity producirá una columna de base de datos con un valor de identidad que se genera en la
base de datos. Un valor de calculado producirá una columna con un valor que se calcula en la base de datos.
Ejemplo
En el ejemplo siguiente se muestran facetas aplicadas a las propiedades de un tipo de entidad:
<EntityType Name="Product">
<Key>
<PropertyRef Name="ProductId" />
</Key>
<Property Type="Int32"
Name="ProductId" Nullable="false"
a:StoreGeneratedPattern="Identity"
xmlns:a="https://schemas.microsoft.com/ado/2009/02/edm/annotation" />
<Property Type="String"
Name="ProductName"
Nullable="false"
MaxLength="50" />
<Property Type="String"
Name="Location"
Nullable="true"
MaxLength="25" />
</EntityType>
Especificación MSL
El lenguaje de especificación de asignaciones (MSL) es un lenguaje basado en XML que describe la asignación entre
el modelo conceptual y el modelo de almacenamiento de una aplicación Entity Framework.
En una aplicación Entity Framework, la asignación de metadatos se carga desde un archivo. MSL (escrito en MSL)
en tiempo de compilación. Entity Framework usa la asignación de metadatos en tiempo de ejecución para traducir
las consultas en el modelo conceptual para almacenar comandos específicos de.
El Entity Framework Designer (EF Designer) almacena la información de asignación en un archivo. edmx en tiempo
de diseño. En tiempo de compilación, Entity Designer usa información en un archivo. edmx para crear el archivo.
MSL que Entity Framework necesita en tiempo de ejecución.
Los nombres de todos los tipos de modelos conceptuales o de almacenamiento a los que se hace referencia en
MSL deben estar calificados con sus respectivos nombres de espacios de nombres. Para obtener información sobre
el nombre del espacio de nombres del modelo conceptual, vea especificación de CSDL. Para obtener información
sobre el nombre del espacio de nombres del modelo de almacenamiento, vea SSDL Specification.
Las versiones de MSL se diferencian en los espacios de nombres XML.
VERSIÓ N DE M SL ESPA C IO DE N O M B RES XM L
MSL v1 urn: schemas-microsoft-com: Windows: Storage: asignación:

CS
MSL V2 https://schemas.microsoft.com/ado/2008/09/mapping/cs
MSL V3 https://schemas.microsoft.com/ado/2009/11/mapping/cs
Alias (Elemento) (MSL)

El elemento alias del lenguaje de especificación de asignaciones (MSL) es un elemento secundario del elemento
mapping que se utiliza para definir los alias para los espacios de nombres de modelos conceptuales y de
almacenamiento. Los nombres de todos los tipos de modelos conceptuales o de almacenamiento a los que se hace
referencia en MSL deben estar calificados con sus respectivos nombres de espacios de nombres. Para obtener
información sobre el nombre del espacio de nombres del modelo conceptual, vea elemento Schema (CSDL). Para
obtener información sobre el nombre del espacio de nombres del modelo de almacenamiento, vea schema
(elemento) (SSDL).
El elemento alias no puede tener elementos secundarios.
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento alias .
Clave Sí El alias para el espacio de nombres

especificado por el atributo de valor .
Valor Sí Espacio de nombres para el que el valor

del elemento key es un alias.
Ejemplo
En el ejemplo siguiente se muestra un elemento alias que define un alias, c , para los tipos que se definen en el
modelo conceptual.
<Mapping Space="C-S"
xmlns="https://schemas.microsoft.com/ado/2009/11/mapping/cs">
<Alias Key="c" Value="SchoolModel"/>
<EntityContainerMapping StorageEntityContainer="SchoolModelStoreContainer"
CdmEntityContainer="SchoolModelEntities">
<EntitySetMapping Name="Courses">
<EntityTypeMapping TypeName="c.Course">
<MappingFragment StoreEntitySet="Course">
<ScalarProperty Name="CourseID" ColumnName="CourseID" />
<ScalarProperty Name="Title" ColumnName="Title" />
<ScalarProperty Name="Credits" ColumnName="Credits" />
<ScalarProperty Name="DepartmentID" ColumnName="DepartmentID" />
</MappingFragment>
</EntityTypeMapping>
</EntitySetMapping>
<EntitySetMapping Name="Departments">
<EntityTypeMapping TypeName="c.Department">
<MappingFragment StoreEntitySet="Department">
<ScalarProperty Name="Name" ColumnName="Name" />
<ScalarProperty Name="Budget" ColumnName="Budget" />
<ScalarProperty Name="StartDate" ColumnName="StartDate" />
<ScalarProperty Name="Administrator" ColumnName="Administrator" />
</MappingFragment>
</EntitySetMapping>
</EntityContainerMapping>
</Mapping>
AssociationEnd (Elemento) (MSL)

El elemento AssociationEnd del lenguaje de especificación de asignaciones (MSL) se utiliza cuando las funciones
de modificación de un tipo de entidad en el modelo conceptual se asignan a los procedimientos almacenados en la
base de datos subyacente. Si un procedimiento almacenado de modificación toma un parámetro cuyo valor se
mantiene en una propiedad de asociación, el elemento AssociationEnd asigna el valor de la propiedad al
parámetro. Para obtener más información, vea el ejemplo siguiente.
Para obtener más información sobre la asignación de funciones de modificación de tipos de entidad a
procedimientos almacenados, vea ModificationFunctionMapping (elemento) (MSL) y Walkthrough: asignar una
entidad a procedimientos almacenados.
El elemento AssociationEnd puede tener los siguientes elementos secundarios:
ScalarProperty
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento AssociationEnd .
AssociationSet Sí El nombre de la asociación que se está

asignando.
From Sí Valor del atributo FromRole de la

propiedad de navegación que
corresponde a la asociación que se está
asignando. Para obtener más
información, vea elemento
NavigationProperty (CSDL).
To Sí Valor del atributo ToRole de la

propiedad de navegación que
corresponde a la asociación que se está
asignando. Para obtener más
información, vea elemento
NavigationProperty (CSDL).
Ejemplo
Considere el siguiente tipo de entidad del modelo conceptual:
<EntityType Name="Course">
<Key>
<PropertyRef Name="CourseID" />
</Key>
<Property Type="Int32" Name="CourseID" Nullable="false" />
<Property Type="String" Name="Title" Nullable="false" MaxLength="100"
FixedLength="false" Unicode="true" />
<Property Type="Int32" Name="Credits" Nullable="false" />
<NavigationProperty Name="Department"
Relationship="SchoolModel.FK_Course_Department"
FromRole="Course" ToRole="Department" />
</EntityType>
Considere también el siguiente procedimiento almacenado:
CREATE PROCEDURE [dbo].[UpdateCourse]

@CourseID int,
@Title nvarchar(50),
@Credits int,
@DepartmentID int
AS
UPDATE Course SET Title=@Title,
Credits=@Credits,
DepartmentID=@DepartmentID
WHERE CourseID=@CourseID;
Para asignar la función de actualización de la entidad Course a este procedimiento almacenado, debe proporcionar
un valor al parámetro depar tmentId . El valor para DepartmentID no corresponde a una propiedad del tipo de
entidad; está contenido en una asociación independiente cuya asignación se muestra aquí:
<AssociationSetMapping Name="FK_Course_Department"
TypeName="SchoolModel.FK_Course_Department"
StoreEntitySet="Course">
<EndProperty Name="Course">
</EndProperty>
<EndProperty Name="Department">
</EndProperty>
</AssociationSetMapping>
En el código siguiente se muestra el elemento AssociationEnd que se usa para asignar la propiedad
depar tmentId de la Asociación de FK_Course_Depar tment al procedimiento almacenado UpdateCourse (al
que se asigna la función de actualización del tipo de entidad Course ):
<EntityTypeMapping TypeName="SchoolModel.Course">
</MappingFragment>
<ModificationFunctionMapping>
<UpdateFunction FunctionName="SchoolModel.Store.UpdateCourse">
<AssociationEnd AssociationSet="FK_Course_Department"
From="Course" To="Department">
<ScalarProperty Name="DepartmentID"
ParameterName="DepartmentID"
Version="Current" />
</AssociationEnd>
<ScalarProperty Name="Credits" ParameterName="Credits"
<ScalarProperty Name="Title" ParameterName="Title"
<ScalarProperty Name="CourseID" ParameterName="CourseID"
</UpdateFunction>
</ModificationFunctionMapping>
</EntitySetMapping>
AssociationSetMapping (Elemento) (MSL)

El elemento AssociationSetMapping del lenguaje de especificación de asignaciones (MSL) define la asignación
entre una asociación en el modelo conceptual y las columnas de tabla en la base de datos subyacente.
Las asociaciones del modelo conceptual son tipos cuyas propiedades representan columnas de clave primaria y
clave externa de la base de datos subyacente. El elemento AssociationSetMapping utiliza dos elementos
EndProperty para definir las asignaciones entre las propiedades de tipo de asociación y las columnas de la base de
datos. Puede definir condiciones en estas asignaciones con el elemento Condition. Asigne las funciones de
inserción, actualización y eliminación para las asociaciones a procedimientos almacenados de la base de datos
mediante el elemento ModificationFunctionMapping. Defina las asignaciones de solo lectura entre las asociaciones
y las columnas de la tabla mediante una Entity SQL cadena en un elemento QueryView.
NOTE
Si se define una restricción referencial para una asociación en el modelo conceptual, no es necesario asignar la asociación con
un elemento AssociationSetMapping . Si hay un elemento AssociationSetMapping para una asociación que tiene una
restricción referencial, se omitirán las asignaciones definidas en el elemento AssociationSetMapping . Para obtener más
información, vea ReferentialConstraint (elemento) (CSDL).
El elemento AssociationSetMapping puede tener los siguientes elementos secundarios

QueryView (cero o uno)
EndProperty (cero o dos)
Condición (cero o más)
ModificationFunctionMapping (cero o uno)
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento AssociationSetMapping .
Nombre Sí El nombre del conjunto de asociaciones

del modelo conceptual que se está
asignando.
NombreDeTipo No El nombre completo, calificado con el

espacio de nombres, del tipo de
asociación del modelo conceptual que
se está asignando.
StoreEntitySet No El nombre de la tabla que se está

asignando.
Ejemplo
En el ejemplo siguiente se muestra un elemento AssociationSetMapping en el que el curso de FK__ Asociación
de Departamento establecida en el modelo conceptual se asigna a la tabla Course en la base de datos. Las
asignaciones entre las propiedades de tipo de asociación y las columnas de tabla se especifican en los elementos
secundarios EndProper ty .
</EndProperty>
</EndProperty>
ComplexProperty (Elemento) (MSL)

Un elemento ComplexProper ty en el lenguaje de especificación de asignaciones (MSL) define la asignación entre
una propiedad de tipo complejo en un tipo de entidad del modelo conceptual y las columnas de la tabla en la base
de datos subyacente. Las asignaciones entre columnas y propiedades se especifican en elementos secundarios
ScalarProperty.
El elemento de propiedad complexType puede tener los siguientes elementos secundarios:
ScalarProperty (cero o más)
ComplexProper ty (cero o más)
ComplextTypeMapping (cero o más)
En la tabla siguiente se describen los atributos aplicables al elemento ComplexProper ty :
Nombre Sí El nombre de la propiedad compleja de

un tipo de entidad del modelo
conceptual que se está asignando.
NombreDeTipo No El nombre completo, calificado con el

espacio de nombres, del tipo de
propiedad del modelo conceptual.
Ejemplo
El siguiente ejemplo se basa en el modelo School. El siguiente tipo complejo se ha agregado al modelo conceptual:
<ComplexType Name="FullName">
<Property Type="String" Name="LastName"
Nullable="false" MaxLength="50"
<Property Type="String" Name="FirstName"
Nullable="false" MaxLength="50"
</ComplexType>
Las propiedades LastName y FirstName del tipo de entidad Person se han reemplazado por una propiedad
compleja, Name :
<EntityType Name="Person">
<Key>
</Key>
<Property Name="Name" Type="SchoolModel.FullName" Nullable="false" />
</EntityType>
En el siguiente MSL se muestra el elemento ComplexProper ty que se usa para asignar la propiedad Name a las
columnas de la base de datos subyacente:
<EntitySetMapping Name="People">
<EntityTypeMapping TypeName="SchoolModel.Person">
<MappingFragment StoreEntitySet="Person">
<ScalarProperty Name="PersonID" ColumnName="PersonID" />
<ScalarProperty Name="HireDate" ColumnName="HireDate" />
<ScalarProperty Name="EnrollmentDate" ColumnName="EnrollmentDate" />
<ComplexProperty Name="Name" TypeName="SchoolModel.FullName">
<ScalarProperty Name="FirstName" ColumnName="FirstName" />
<ScalarProperty Name="LastName" ColumnName="LastName" />
</ComplexProperty>
</MappingFragment>
</EntitySetMapping>
ComplexTypeMapping (Elemento) (MSL)

El elemento ComplexTypeMapping del lenguaje de especificación de asignaciones (MSL) es un elemento
secundario del elemento ResultMapping y define la asignación entre una importación de función en el modelo
conceptual y un procedimiento almacenado en la base de datos subyacente cuando se cumplen las condiciones
siguientes:
La importación de función devuelve un tipo complejo conceptual.
Los nombres de las columnas devueltas por el procedimiento almacenado no coinciden exactamente con los
nombres de las propiedades en el tipo complejo.
De forma predeterminada, la asignación entre las columnas devueltas por un procedimiento almacenado y un tipo
complejo se basa en los nombres de las propiedades y de las columnas. Si los nombres de columna no coinciden
exactamente con los nombres de propiedad, debe utilizar el elemento ComplexTypeMapping para definir la
asignación. Para obtener un ejemplo de la asignación predeterminada, vea FunctionImportMapping (elemento)
(MSL).
El elemento ComplexTypeMapping puede tener los siguientes elementos secundarios:
En la tabla siguiente se describen los atributos aplicables al elemento ComplexTypeMapping .
NombreDeTipo Sí El nombre completo, incluido el espacio

de nombres, del tipo complejo que se
está asignando.
Ejemplo
Observe el siguiente procedimiento almacenado:
CREATE PROCEDURE [dbo].[GetGrades]

@student_Id int
AS
SELECT EnrollmentID as enroll_id,
Grade as grade,
CourseID as course_id,
StudentID as student_id
FROM dbo.StudentGrade
WHERE StudentID = @student_Id
Considere también el siguiente tipo complejo del modelo conceptual:
<ComplexType Name="GradeInfo">
<Property Type="Int32" Name="EnrollmentID" Nullable="false" />
<Property Type="Decimal" Name="Grade" Nullable="true"
Precision="3" Scale="2" />
<Property Type="Int32" Name="CourseID" Nullable="false" />
<Property Type="Int32" Name="StudentID" Nullable="false" />
</ComplexType>
Para crear una importación de función que devuelva instancias del tipo complejo anterior, la asignación entre las
columnas devueltas por el procedimiento almacenado y el tipo de entidad debe definirse en un elemento
ComplexTypeMapping :
<FunctionImportMapping FunctionImportName="GetGrades"
FunctionName="SchoolModel.Store.GetGrades" >
<ResultMapping>
<ComplexTypeMapping TypeName="SchoolModel.GradeInfo">
<ScalarProperty Name="EnrollmentID" ColumnName="enroll_id"/>
<ScalarProperty Name="CourseID" ColumnName="course_id"/>
<ScalarProperty Name="StudentID" ColumnName="student_id"/>
<ScalarProperty Name="Grade" ColumnName="grade"/>
</ComplexTypeMapping>
</ResultMapping>
</FunctionImportMapping>
Condition (Elemento) (MSL)

El elemento Condition del lenguaje de especificación de asignaciones (MSL) coloca condiciones en las
asignaciones entre el modelo conceptual y la base de datos subyacente. La asignación que se define dentro de un
nodo XML es válida si se cumplen todas las condiciones, como se especifica en los elementos de condición
secundarios. De lo contrario, la asignación no es válida. Por ejemplo, si un elemento MappingFragment contiene
uno o varios elementos secundarios Condition , la asignación definida dentro del nodo MappingFragment solo
será válida si se cumplen todas las condiciones de los elementos de condición secundarios.
Cada condición se puede aplicar a un nombre (el nombre de una propiedad de entidad del modelo conceptual,
especificado por el atributo de nombre ) o un columnName (el nombre de una columna de la base de datos,
especificado por el atributo columnName ). Cuando se establece el atributo Name , la condición se comprueba
con respecto a un valor de propiedad de entidad. Cuando se establece el atributo columnName , la condición se
comprueba con respecto a un valor de columna. Solo se puede especificar uno de los atributos Name o
columnName en un elemento Condition .
NOTE
Cuando el elemento Condition se usa dentro de un elemento FunctionImportMapping, solo el atributo Name no es
aplicable.
El elemento Condition puede ser un elemento secundario de los siguientes elementos:

AssociationSetMapping
ComplexProperty
EntitySetMapping
MappingFragment
EntityTypeMapping
El elemento Condition no puede tener elementos secundarios.
En la tabla siguiente se describen los atributos aplicables al elemento Condition :
ColumnName No El nombre de la columna de la tabla

cuyo valor se utiliza para evaluar la
condición.
IsNull No True o False . Si el valor es true y el

valor de la columna es null, o si el valor
es false y el valor de la columna no es
null, la condición es true. De lo
contrario, la condición es falsa.
Los atributos IsNull y Value no se
pueden usar al mismo tiempo.
Valor No El valor con el que se compara el valor

de la columna. Si los valores son los
mismos, la condición es verdadera. De
lo contrario, la condición es falsa.
Los atributos IsNull y Value no se
pueden usar al mismo tiempo.
Nombre No El nombre de la propiedad de entidad

del modelo conceptual cuyo valor se
utiliza para evaluar la condición.
Este atributo no es aplicable si el
elemento Condition se usa dentro de
un elemento FunctionImportMapping.
Ejemplo
En el ejemplo siguiente se muestran los elementos Condition como elementos secundarios de los elementos
MappingFragment . Cuando HireDate no es NULL y EnrollmentDate es null, los datos se asignan entre el tipo
SchoolModel. instructor y las columnas PersonID e HireDate de la tabla Person . Cuando EnrollmentDate
no es NULL y HireDate es null, los datos se asignan entre el tipo SchoolModel. Student y las columnas
PersonID e Enrollment de la tabla Person .
<EntityTypeMapping TypeName="IsTypeOf(SchoolModel.Person)">
</MappingFragment>
<EntityTypeMapping TypeName="IsTypeOf(SchoolModel.Instructor)">
<Condition ColumnName="HireDate" IsNull="false" />
<Condition ColumnName="EnrollmentDate" IsNull="true" />
</MappingFragment>
<EntityTypeMapping TypeName="IsTypeOf(SchoolModel.Student)">
<ScalarProperty Name="EnrollmentDate"
ColumnName="EnrollmentDate" />
<Condition ColumnName="EnrollmentDate" IsNull="false" />
<Condition ColumnName="HireDate" IsNull="true" />
</MappingFragment>
</EntitySetMapping>
DeleteFunction (Elemento) (MSL)

El elemento Inser tFunction del lenguaje de especificación de asignaciones (MSL) asigna la función de eliminación
de un tipo de entidad o asociación del modelo conceptual a un procedimiento almacenado en la base de datos
subyacente. Los procedimientos almacenados a los que están asignados las funciones de modificación se deben
declarar en el modelo de almacenamiento. Para obtener más información, vea elemento function (SSDL).
NOTE
Si no asigna las tres operaciones de inserción, actualización o eliminación de un tipo de entidad a los procedimientos
almacenados, se producirá un error en las operaciones no asignadas si se ejecutan en tiempo de ejecución y se genera un
UpdateException.
DeleteFunction aplicado a EntityTypeMapping

Cuando se aplica al elemento EntityTypeMapping, el elemento DeleteFunction asigna la función de eliminación
de un tipo de entidad del modelo conceptual a un procedimiento almacenado.
El elemento DeleteFunction puede tener los elementos secundarios siguientes cuando se aplica a un elemento
EntityTypeMapping :
AssociationEnd (cero o más)
ComplexProperty (cero o más)
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento DeleteFunction cuando se
aplica a un elemento EntityTypeMapping .
Nombrefunción Sí El nombre completo, calificado con el

espacio de nombres, del procedimiento
almacenado al que la función de
eliminación está asignada. El
procedimiento almacenado se debe
declarar en el modelo de
almacenamiento.
RowsAffectedParameter No El nombre del parámetro de salida que

devuelve el número de filas afectadas.
Ejemplo
El ejemplo siguiente se basa en el modelo School y muestra el elemento DeleteFunction que asigna la función
Delete del tipo de entidad Person al procedimiento almacenado DeletePerson . El procedimiento almacenado
DeletePerson se declara en el modelo de almacenamiento.
</MappingFragment>
<InsertFunction FunctionName="SchoolModel.Store.InsertPerson">
ParameterName="EnrollmentDate" />
<ScalarProperty Name="HireDate" ParameterName="HireDate" />
<ScalarProperty Name="FirstName" ParameterName="FirstName" />
<ScalarProperty Name="LastName" ParameterName="LastName" />
<ResultBinding Name="PersonID" ColumnName="NewPersonID" />
</InsertFunction>
<UpdateFunction FunctionName="SchoolModel.Store.UpdatePerson">
ParameterName="EnrollmentDate"
<ScalarProperty Name="HireDate" ParameterName="HireDate"
<ScalarProperty Name="FirstName" ParameterName="FirstName"
<ScalarProperty Name="LastName" ParameterName="LastName"
<ScalarProperty Name="PersonID" ParameterName="PersonID"
</UpdateFunction>
<DeleteFunction FunctionName="SchoolModel.Store.DeletePerson">
<ScalarProperty Name="PersonID" ParameterName="PersonID" />
</DeleteFunction>
</EntitySetMapping>
DeleteFunction aplicado a AssociationSetMapping

Cuando se aplica al elemento AssociationSetMapping, el elemento DeleteFunction asigna la función de
eliminación de una asociación del modelo conceptual a un procedimiento almacenado.
El elemento DeleteFunction puede tener los elementos secundarios siguientes cuando se aplica al elemento
AssociationSetMapping :
EndProperty
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento DeleteFunction cuando se
aplica al elemento AssociationSetMapping .

eliminación está asignada. El
almacenamiento.

Ejemplo
El ejemplo siguiente se basa en el modelo School y muestra el elemento DeleteFunction que se usa para asignar
la función de eliminación de la Asociación CourseInstructor al procedimiento almacenado
DeleteCourseInstructor . El procedimiento almacenado DeleteCourseInstructor se declara en el modelo de
almacenamiento.
<AssociationSetMapping Name="CourseInstructor"
TypeName="SchoolModel.CourseInstructor"
StoreEntitySet="CourseInstructor">
<EndProperty Name="Person">
</EndProperty>
</EndProperty>
<InsertFunction FunctionName="SchoolModel.Store.InsertCourseInstructor" >
<ScalarProperty Name="CourseID" ParameterName="courseId"/>
</EndProperty>
<ScalarProperty Name="PersonID" ParameterName="instructorId"/>
</EndProperty>
</InsertFunction>
<DeleteFunction FunctionName="SchoolModel.Store.DeleteCourseInstructor">
</EndProperty>
</EndProperty>
</DeleteFunction>
EndProperty (Elemento) (MSL)

El elemento EndProper ty del lenguaje de especificación de asignaciones (MSL) define la asignación entre un
extremo o una función de modificación de una asociación del modelo conceptual y la base de datos subyacente. La
asignación entre columnas y propiedades se especifica en un elemento secundario ScalarProperty.
Cuando se utiliza un elemento EndProper ty para definir la asignación para el final de una asociación del modelo
conceptual, es un elemento secundario de un elemento AssociationSetMapping. Cuando el elemento EndProper ty
se utiliza para definir la asignación para una función de modificación de una asociación del modelo conceptual, es
un elemento secundario de un elemento InsertFunction o un elemento InsertFunction.
El elemento EndProper ty puede tener los siguientes elementos secundarios:
En la tabla siguiente se describen los atributos aplicables al elemento EndProper ty :
Nombre Sí El nombre del extremo de la asociación

que se está asignando.
Ejemplo
En el ejemplo siguiente se muestra un elemento AssociationSetMapping en el que la Asociación de
FK_Course_Depar tment del modelo conceptual está asignada a la tabla Course de la base de datos. Las
asignaciones entre las propiedades de tipo de asociación y las columnas de tabla se especifican en los elementos
secundarios EndProper ty .
</EndProperty>
</EndProperty>
Ejemplo
En el ejemplo siguiente se muestra el elemento EndProper ty que asigna las funciones de inserción y eliminación
de una asociación (CourseInstructor ) a los procedimientos almacenados en la base de datos subyacente. Las
funciones asignadas se declaran en el modelo de almacenamiento.
</EndProperty>
</EndProperty>
</EndProperty>
</EndProperty>
</InsertFunction>
</EndProperty>
</EndProperty>
</DeleteFunction>
EntityContainerMapping (Elemento) (MSL)

El elemento EntityContainerMapping del lenguaje de especificación de asignaciones (MSL) asigna el contenedor
de entidades del modelo conceptual al contenedor de entidades en el modelo de almacenamiento. El elemento
EntityContainerMapping es un elemento secundario del elemento Mapping.
El elemento EntityContainerMapping puede tener los elementos secundarios siguientes (en el orden mostrado):
EntitySetMapping (cero o más)
AssociationSetMapping (cero o más)
FunctionImportMapping (cero o más)
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento EntityContainerMapping .
StorageModelContainer Sí El nombre del contenedor de entidades

del modelo de almacenamiento que se
está asignando.
CdmEntityContainer Sí El nombre del contenedor de entidades

asignando.
GenerateUpdateViews No True o False . Si es false , no se genera

ninguna vista de actualización. Este
atributo debe establecerse en false si
tiene una asignación de solo lectura que
no sería válida porque los datos no
pueden realizar una operación de ida y
vuelta correctamente.
El valor predeterminado es True .
Ejemplo
En el ejemplo siguiente se muestra un elemento EntityContainerMapping que asigna el contenedor
SchoolModelEntities (el contenedor de entidades del modelo conceptual) al contenedor
SchoolModelStoreContainer (el contenedor de entidades del modelo de almacenamiento):
</MappingFragment>
</EntitySetMapping>
</MappingFragment>
</EntitySetMapping>
EntitySetMapping (Elemento) (MSL)

El elemento EntitySetMapping del lenguaje de especificación de asignaciones (MSL) asigna todos los tipos de un
conjunto de entidades del modelo conceptual a los conjuntos de entidades del modelo de almacenamiento. Un
conjunto de entidades del modelo conceptual es un contenedor lógico para instancias de entidades del mismo tipo
(y tipos derivados). Un conjunto de entidades del modelo de almacenamiento representa una tabla o vista de la
base de datos subyacente. El conjunto de entidades del modelo conceptual se especifica mediante el valor del
atributo Name del elemento EntitySetMapping . La tabla o vista asignada a se especifica mediante el atributo
StoreEntitySet en cada elemento MappingFragment secundario o en el propio elemento EntitySetMapping .
El elemento EntitySetMapping puede tener los siguientes elementos secundarios:
EntityTypeMapping (cero o más)
QueryView (cero o uno)
MappingFragment (cero o más)
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento EntitySetMapping .
Nombre Sí El nombre del conjunto de entidades del

modelo conceptual que se está
asignando.
TypeName 1 No El nombre del tipo de entidad del

modelo conceptual que se está
asignando.
StoreEntitySet 1 No El nombre del conjunto de entidades del

modelo de almacenamiento al que se
está asignando.
MakeColumnsDistinct No True o false , dependiendo de si solo se

devuelven filas distintas.
Si este atributo se establece en true , el
atributo GenerateUpdateViews del
elemento EntityContainerMapping debe
establecerse en false .
1 los atributos TypeName y StoreEntitySet se pueden usar en lugar de los elementos secundarios
EntityTypeMapping y MappingFragment para asignar un tipo de entidad único a una sola tabla.
Ejemplo
En el ejemplo siguiente se muestra un elemento EntitySetMapping que asigna tres tipos (un tipo base y dos tipos
derivados) en el conjunto de entidades Courses del modelo conceptual a tres tablas diferentes en la base de datos
subyacente. Las tablas se especifican mediante el atributo StoreEntitySet en cada elemento MappingFragment .
<EntityTypeMapping TypeName="IsTypeOf(SchoolModel1.Course)">
</MappingFragment>
<EntityTypeMapping TypeName="IsTypeOf(SchoolModel1.OnlineCourse)">
<MappingFragment StoreEntitySet="OnlineCourse">
<ScalarProperty Name="URL" ColumnName="URL" />
</MappingFragment>
<EntityTypeMapping TypeName="IsTypeOf(SchoolModel1.OnsiteCourse)">
<MappingFragment StoreEntitySet="OnsiteCourse">
<ScalarProperty Name="Time" ColumnName="Time" />
<ScalarProperty Name="Days" ColumnName="Days" />
<ScalarProperty Name="Location" ColumnName="Location" />
</MappingFragment>
</EntitySetMapping>
EntityTypeMapping (Elemento) (MSL)

El elemento EntityTypeMapping del lenguaje de especificación de asignaciones (MSL) define la asignación entre
un tipo de entidad en el modelo conceptual y las tablas o vistas de la base de datos subyacente. Para obtener
información sobre los tipos de entidad del modelo conceptual y las tablas o vistas de la base de datos subyacente,
vea EntityType (Elemento) (CSDL) y EntitySet (Elemento) (SSDL). El tipo de entidad del modelo conceptual que se
está asignando se especifica mediante el atributo TypeName del elemento EntityTypeMapping . La tabla o vista
que se está asignando se especifica mediante el atributo StoreEntitySet del elemento MappingFragment
secundario.
El elemento secundario ModificationFunctionMapping se puede utilizar para asignar las funciones de inserción,
actualización o eliminación de tipos de entidad a procedimientos almacenados de la base de datos.
El elemento EntityTypeMapping puede tener los siguientes elementos secundarios:
MappingFragment (cero o más)
ModificationFunctionMapping (cero o uno)
ScalarProperty
Condición
NOTE
Los elementos MappingFragment y ModificationFunctionMapping no pueden ser elementos secundarios del elemento
EntityTypeMapping al mismo tiempo.
NOTE
Los elementos ScalarProper ty y Condition solo pueden ser elementos secundarios del elemento EntityTypeMapping
cuando se usa dentro de un elemento FunctionImportMapping.
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento EntityTypeMapping .
NombreDeTipo Sí El nombre completo, calificado con el

espacio de nombres, del tipo de entidad
asignando.
Si el tipo es abstracto o un tipo
derivado, el valor debe ser
IsOfType(Namespace-
qualified_type_name)
.
Ejemplo
En el ejemplo siguiente se muestra un elemento EntitySetMapping con dos elementos EntityTypeMapping
secundarios. En el primer elemento EntityTypeMapping , el tipo de entidad SchoolModel. person se asigna a la
tabla Person . En el segundo elemento EntityTypeMapping , la funcionalidad de actualización del tipo
SchoolModel. person se asigna a un procedimiento almacenado, UpdatePerson , en la base de datos.
<ScalarProperty Name="EnrollmentDate" ColumnName="EnrollmentDate" />
</MappingFragment>
<ScalarProperty Name="EnrollmentDate" ParameterName="EnrollmentDate"
</UpdateFunction>
</EntitySetMapping>
Ejemplo
En el ejemplo siguiente se muestra la asignación de una jerarquía de tipos en la que el tipo raíz es abstracto. Tenga
en cuenta el uso de la sintaxis de IsOfType para los atributos TypeName .
<EntityTypeMapping TypeName="IsTypeOf(SchoolModel.Person)">
</MappingFragment>
<EntityTypeMapping TypeName="IsTypeOf(SchoolModel.Instructor)">
<Condition ColumnName="HireDate" IsNull="false" />
<Condition ColumnName="EnrollmentDate" IsNull="true" />
</MappingFragment>
<EntityTypeMapping TypeName="IsTypeOf(SchoolModel.Student)">
<Condition ColumnName="EnrollmentDate" IsNull="false" />
<Condition ColumnName="HireDate" IsNull="true" />
</MappingFragment>
</EntitySetMapping>
FunctionImportMapping (Elemento) (MSL)

El elemento FunctionImpor tMapping del lenguaje de especificación de asignaciones (MSL) define la asignación
entre una importación de función en el modelo conceptual y un procedimiento almacenado o una función en la
base de datos subyacente. Las importaciones de función se deben declarar en el modelo conceptual, mientras que
los procedimientos almacenados se deben declarar en el modelo de almacenamiento. Para obtener más
información, vea elemento FunctionImport (CSDL) y elemento function (SSDL).
NOTE
De forma predeterminada, si una importación de función devuelve un tipo de entidad del modelo conceptual o un tipo
complejo, entonces los nombres de las columnas devueltas por el procedimiento almacenado subyacente deben coincidir
exactamente con los nombres de las propiedades del tipo del modelo conceptual. Si los nombres de columna no coinciden
exactamente con los nombres de propiedad, la asignación se debe definir en un elemento ResultMapping.
El elemento FunctionImpor tMapping puede tener los siguientes elementos secundarios:

ResultMapping (cero o más)
En la tabla siguiente se describen los atributos aplicables al elemento FunctionImpor tMapping :
FunctionImpor tName Sí El nombre de la importación de función

asignando.
Nombrefunción Sí El nombre, calificado con el espacio de

nombres, de la función del modelo de
almacenamiento que se está asignando.
Ejemplo
El siguiente ejemplo se basa en el modelo School. Considere la siguiente función en el modelo de almacenamiento:
<Function Name="GetStudentGrades" Aggregate="false"

BuiltIn="false" NiladicFunction="false"
IsComposable="false" ParameterTypeSemantics="AllowImplicitConversion"
Schema="dbo">
<Parameter Name="StudentID" Type="int" Mode="In" />
</Function>
También considere esta importación de función en el modelo conceptual:
<FunctionImport Name="GetStudentGrades" EntitySet="StudentGrades"

</FunctionImport>
En el ejemplo siguiente se muestra un elemento FunctionImpor tMapping que se usa para asignar la función y la
importación de funciones anteriores entre sí:
<FunctionImportMapping FunctionImportName="GetStudentGrades"
FunctionName="SchoolModel.Store.GetStudentGrades" />
InsertFunction (Elemento) (MSL)
El elemento Inser tFunction del lenguaje de especificación de asignaciones (MSL) asigna la función de inserción
de un tipo de entidad o asociación del modelo conceptual a un procedimiento almacenado en la base de datos
NOTE
UpdateException.
El elemento Inser tFunction puede ser un elemento secundario del elemento ModificationFunctionMapping y
aplicarse al elemento EntityTypeMapping o al elemento AssociationSetMapping.
InsertFunction aplicado a EntityTypeMapping
Cuando se aplica al elemento EntityTypeMapping, el elemento Inser tFunction asigna la función de inserción de
un tipo de entidad del modelo conceptual a un procedimiento almacenado.
El elemento Inser tFunction puede tener los elementos secundarios siguientes cuando se aplica a un elemento
EntityTypeMapping :
ResultBinding (cero o uno)
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento Inser tFunction cuando se
aplican a un elemento EntityTypeMapping .

inserción está asignada. El
almacenamiento.

Ejemplo
El ejemplo siguiente se basa en el modelo School y muestra el elemento Inser tFunction que se usa para asignar
la función de inserción del tipo de entidad person al procedimiento almacenado Inser tPerson . El procedimiento
almacenado Inser tPerson se declara en el modelo de almacenamiento.
</InsertFunction>
</UpdateFunction>
</DeleteFunction>
InsertFunction aplicado a AssociationSetMapping

Cuando se aplica al elemento AssociationSetMapping, el elemento Inser tFunction asigna la función de inserción
de una asociación del modelo conceptual a un procedimiento almacenado.
El elemento Inser tFunction puede tener los elementos secundarios siguientes cuando se aplica al elemento
AssociationSetMapping :
EndProperty
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento Inser tFunction cuando se aplica
al elemento AssociationSetMapping .

inserción está asignada. El
almacenamiento.

Ejemplo
El ejemplo siguiente se basa en el modelo School y muestra el elemento Inser tFunction que se usa para asignar
la función de inserción de la Asociación CourseInstructor al procedimiento almacenado
Inser tCourseInstructor . El procedimiento almacenado Inser tCourseInstructor se declara en el modelo de
almacenamiento.
</EndProperty>
</EndProperty>
</EndProperty>
</EndProperty>
</InsertFunction>
</EndProperty>
</EndProperty>
</DeleteFunction>
Mapping (Elemento) (MSL)

El elemento mapping del lenguaje de especificación de asignaciones (MSL) contiene información para la
asignación de objetos que se definen en un modelo conceptual a una base de datos (tal y como se describe en un
modelo de almacenamiento). Para obtener más información, vea especificación de CSDL y especificación de SSDL.
El elemento mapping es el elemento raíz de una especificación de asignación. El espacio de nombres XML para la
asignación de especificaciones es https://schemas.microsoft.com/ado/2009/11/mapping/cs.
El elemento de asignación puede tener los elementos secundarios siguientes (en el orden mostrado):
Alias (cero o más)
EntityContainerMapping (exactamente uno)
Los nombres de los tipos de modelos conceptuales y de almacenamiento a los que se hace referencia en MSL
deben estar calificados con sus respectivos nombres de espacios de nombres. Para obtener información sobre el
nombre del espacio de nombres del modelo conceptual, vea elemento Schema (CSDL). Para obtener información
sobre el nombre del espacio de nombres del modelo de almacenamiento, vea schema (elemento) (SSDL). Los alias
para los espacios de nombres que se utilizan en MSL se pueden definir con el elemento Alias.
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento de asignación .
Espacio Sí C-S. Este es un valor fijo y no se puede

cambiar.
Ejemplo
En el ejemplo siguiente se muestra un elemento de asignación basado en parte del modelo School. Para obtener
más información sobre el modelo School, consulte Inicio rápido (Entity Framework):
<Mapping Space="C-S"
xmlns="https://schemas.microsoft.com/ado/2009/11/mapping/cs">
<Alias Key="c" Value="SchoolModel"/>
</MappingFragment>
</EntitySetMapping>
</MappingFragment>
</EntitySetMapping>
</Mapping>
MappingFragment (Elemento) (MSL)

El elemento MappingFragment del lenguaje de especificación de asignaciones (MSL) define la asignación entre
las propiedades de un tipo de entidad del modelo conceptual y una tabla o vista en la base de datos. Para obtener
información sobre los tipos de entidad del modelo conceptual y las tablas o vistas de la base de datos subyacente,
vea EntityType (Elemento) (CSDL) y EntitySet (Elemento) (SSDL). El MappingFragment puede ser un elemento
secundario del elemento EntityTypeMapping o el elemento EntitySetMapping.
El elemento MappingFragment puede tener los siguientes elementos secundarios:
ComplexType (cero o más)
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento MappingFragment .
StoreEntitySet Sí El nombre de la tabla o vista que se está

asociando.
MakeColumnsDistinct No True o false , dependiendo de si solo se

devuelven filas distintas.
Si este atributo se establece en true , el
atributo GenerateUpdateViews del
elemento EntityContainerMapping debe
establecerse en false .
Ejemplo
En el ejemplo siguiente se muestra un elemento MappingFragment como elemento secundario de un elemento
EntityTypeMapping . En este ejemplo, las propiedades del tipo de curso en el modelo conceptual se asignan a las
columnas de la tabla Course en la base de datos.
</MappingFragment>
</EntitySetMapping>
Ejemplo
En el ejemplo siguiente se muestra un elemento MappingFragment como el elemento secundario de un
elemento EntitySetMapping . Como en el ejemplo anterior, las propiedades del tipo de curso en el modelo
conceptual se asignan a las columnas de la tabla Course en la base de datos.
<EntitySetMapping Name="Courses" TypeName="SchoolModel.Course">

</MappingFragment>
</EntitySetMapping>
ModificationFunctionMapping (Elemento) (MSL)

El elemento ModificationFunctionMapping del lenguaje de especificación de asignaciones (MSL) asigna las
funciones de inserción, actualización y eliminación de un tipo de entidad del modelo conceptual a los
procedimientos almacenados en la base de datos subyacente. El elemento ModificationFunctionMapping
también puede asignar las funciones de inserción y eliminación para las asociaciones de varios a varios del modelo
conceptual a los procedimientos almacenados en la base de datos subyacente. Los procedimientos almacenados a
los que están asignados las funciones de modificación se deben declarar en el modelo de almacenamiento. Para
obtener más información, vea elemento function (SSDL).
NOTE
UpdateException.
NOTE
Si las funciones de modificación para una entidad de una jerarquía de herencia están asignadas a procedimientos
almacenados, entonces las funciones de modificación para todos los tipos de la jerarquía deben estar asignadas a
El elemento ModificationFunctionMapping puede ser un elemento secundario del elemento EntityTypeMapping

o el elemento AssociationSetMapping.
El elemento ModificationFunctionMapping puede tener los siguientes elementos secundarios:
DeleteFunction (cero o uno)
InsertFunction (cero o uno)
UpdateFunction (cero o uno)
No hay atributos aplicables al elemento ModificationFunctionMapping .
Ejemplo
En el ejemplo siguiente se muestra la asignación de conjunto de entidades para el conjunto de entidades People
del modelo School. Además de la asignación de columnas para el tipo de entidad Person , se muestra la
asignación de las funciones INSERT, Update y DELETE del tipo Person . Las funciones asignadas se declaran en el
</MappingFragment>
</InsertFunction>
</UpdateFunction>
</DeleteFunction>
</EntitySetMapping>
Ejemplo
En el ejemplo siguiente se muestra la asignación del conjunto de asociaciones para el conjunto de asociaciones
CourseInstructor en el modelo School. Además de la asignación de columnas para la Asociación
CourseInstructor , se muestra la asignación de las funciones de inserción y eliminación de la Asociación
CourseInstructor . Las funciones asignadas se declaran en el modelo de almacenamiento.
</EndProperty>
</EndProperty>
</EndProperty>
</EndProperty>
</InsertFunction>
</EndProperty>
</EndProperty>
</DeleteFunction>
QueryView (Elemento) (MSL)

El elemento Quer yView del lenguaje de especificación de asignaciones (MSL) define una asignación de solo
lectura entre un tipo de entidad o una asociación en el modelo conceptual y una tabla en la base de datos
subyacente. La asignación se define con una consulta Entity SQL que se evalúa con el modelo de almacenamiento y
se expresa el conjunto de resultados en términos de una entidad o asociación en el modelo conceptual. Dado que
las vistas de consulta son de solo lectura, no puede utilizar los comandos de actualización estándar para actualizar
los tipos que se definen mediante vistas de consulta. Puede realizar las actualizaciones de estos tipos utilizando
funciones de modificación. Para obtener más información, vea cómo: asignar funciones de modificación a
NOTE
En el elemento Quer yView , no se admiten Entity SQL expresiones que contengan GroupBy , agregados de grupo o
propiedades de navegación.
El elemento Quer yView puede ser un elemento secundario del elemento EntitySetMapping o del elemento
AssociationSetMapping. En el primer caso, la vista de consulta define una asignación de solo lectura para una
entidad del modelo conceptual. En el último caso, la vista de consulta define una asignación de solo lectura para
una asociación del modelo conceptual.
NOTE
Si el elemento AssociationSetMapping es para una asociación con una restricción referencial, se omite el elemento
AssociationSetMapping . Para obtener más información, vea ReferentialConstraint (elemento) (CSDL).
El elemento Quer yView no puede tener elementos secundarios.

En la tabla siguiente se describen los atributos que se pueden aplicar al elemento Quer yView .
NombreDeTipo No El nombre del tipo de modelo

conceptual que se está asignando
mediante la vista de consulta.
Ejemplo
En el ejemplo siguiente se muestra el elemento Quer yView como elemento secundario del elemento
EntitySetMapping y se define una asignación de vista de consulta para el tipo de entidad Depar tment en el
modelo School.
<EntitySetMapping Name="Departments" >

<QueryView>
SELECT VALUE SchoolModel.Department(d.DepartmentID,
d.Name,
d.Budget,
d.StartDate)
FROM SchoolModelStoreContainer.Department AS d
WHERE d.Budget > 150000
</QueryView>
</EntitySetMapping>
Dado que la consulta solo devuelve un subconjunto de los miembros del tipo Depar tment en el modelo de
almacenamiento, el tipo Depar tment del modelo School se ha modificado según esta asignación de la manera
siguiente:
<EntityType Name="Department">
<Key>
<PropertyRef Name="DepartmentID" />
</Key>
<Property Type="Int32" Name="DepartmentID" Nullable="false" />
<Property Type="String" Name="Name" Nullable="false"
MaxLength="50" FixedLength="false" Unicode="true" />
<Property Type="Decimal" Name="Budget" Nullable="false"
Precision="19" Scale="4" />
<Property Type="DateTime" Name="StartDate" Nullable="false" />
<NavigationProperty Name="Courses"
Relationship="SchoolModel.FK_Course_Department"
FromRole="Department" ToRole="Course" />
</EntityType>
Ejemplo
En el ejemplo siguiente se muestra el elemento Quer yView como elemento secundario de un elemento
AssociationSetMapping y se define una asignación de solo lectura para la Asociación de FK_Course_Department
en el modelo School.
CdmEntityContainer="SchoolEntities">
<EntitySetMapping Name="Courses" >
<QueryView>
SELECT VALUE SchoolModel.Course(c.CourseID,
c.Title,
c.Credits)
FROM SchoolModelStoreContainer.Course AS c
</QueryView>
</EntitySetMapping>
<EntitySetMapping Name="Departments" >
<QueryView>
SELECT VALUE SchoolModel.Department(d.DepartmentID,
d.Name,
d.Budget,
d.StartDate)
FROM SchoolModelStoreContainer.Department AS d
WHERE d.Budget > 150000
</QueryView>
</EntitySetMapping>
<AssociationSetMapping Name="FK_Course_Department" >
<QueryView>
SELECT VALUE SchoolModel.FK_Course_Department(
CREATEREF(SchoolEntities.Departments, row(c.DepartmentID), SchoolModel.Department),
CREATEREF(SchoolEntities.Courses, row(c.CourseID)) )
FROM SchoolModelStoreContainer.Course AS c
</QueryView>
Comentarios
Puede definir vistas de consulta para habilitar los escenarios siguientes:
Defina una entidad en el modelo conceptual que no incluya todas las propiedades de la entidad en el modelo de
almacenamiento. Esto incluye propiedades que no tienen valores predeterminados y no admiten valores null .
Asigne las columnas calculadas del modelo de almacenamiento a las propiedades de los tipos de entidad del
modelo conceptual.
Defina una asignación en la que las condiciones utilizadas para dividir las entidades del modelo conceptual no
se basen en la igualdad. Cuando se especifica una asignación condicional mediante el elemento Condition , la
condición proporcionada debe ser igual al valor especificado. Para obtener más información, vea condition
(elemento) (MSL).
Asigne la misma columna en el modelo de almacenamiento a varios tipos en el modelo conceptual.
Asigne varios tipos a la misma tabla.
Defina asociaciones en el modelo conceptual que no se basen en claves externas en el esquema relacional.
Utilice la lógica de negocios personalizada para establecer el valor de las propiedades del modelo conceptual.
Por ejemplo, podría asignar el valor de cadena "T" en el origen de datos a un valor true , un valor booleano, en
el modelo conceptual.
Defina filtros condicionales para los resultados de la consulta.
Aplique menos restricciones en los datos del modelo conceptual que en el modelo de almacenamiento. Por
ejemplo, podría hacer que una propiedad en el modelo conceptual acepte valores NULL incluso si la columna a
la que está asignada no admite valores null .
Las consideraciones siguientes se aplican al definir las vistas de consulta para las entidades:
Las vistas de consulta son de solo lectura. Solo puede realizar las actualizaciones a las entidades utilizando las
funciones de modificación.
Al definir un tipo de entidad mediante una vista de consulta, también debe definir todas las entidades
relacionadas mediante vistas de consulta.
Al asignar una asociación varios a varios a una entidad en el modelo de almacenamiento que representa una
tabla de vínculos en el esquema relacional, debe definir un elemento Quer yView en el elemento
AssociationSetMapping para esta tabla de vínculos.
Las vistas de consulta se deben definir para todos los tipos de una jerarquía de tipos. Puede hacer esto de las
siguientes maneras:
Con un único elemento Quer yView que especifica una única Entity SQL consulta que devuelve una
Unión de todos los tipos de entidad de la jerarquía.
Con un único elemento Quer yView que especifica una única Entity SQL consulta que usa el operador
Case para devolver un tipo de entidad específico en la jerarquía basándose en una condición específica.
Con un elemento Quer yView adicional para un tipo específico en la jerarquía. En este caso, use el
atributo TypeName del elemento Quer yView para especificar el tipo de entidad para cada vista.
Cuando se define una vista de consulta, no se puede especificar el atributo StorageSetName en el elemento
EntitySetMapping .
Cuando se define una vista de consulta, el elemento EntitySetMapping no puede contener también
asignaciones de propiedades .
ResultBinding (Elemento) (MSL)

El elemento ResultBinding del lenguaje de especificación de asignaciones (MSL) asigna los valores de columna
devueltos por los procedimientos almacenados a las propiedades de entidad del modelo conceptual cuando las
funciones de modificación de tipo de entidad se asignan a los procedimientos almacenados en la base de datos
subyacente. Por ejemplo, cuando un procedimiento almacenado de inserción devuelve el valor de una columna de
identidad, el elemento ResultBinding asigna el valor devuelto a una propiedad de tipo de entidad en el modelo
conceptual.
El elemento ResultBinding puede ser secundario del elemento InsertFunction o del elemento UpdateFunction.
El elemento ResultBinding no puede tener elementos secundarios.
En la tabla siguiente se describen los atributos aplicables al elemento ResultBinding :
Nombre Sí El nombre de la propiedad de entidad

asignando.
ColumnName Sí El nombre de la columna que se está

asignando.
Ejemplo
El ejemplo siguiente se basa en el modelo School y muestra un elemento Inser tFunction que se usa para asignar
la función de inserción del tipo de entidad Person al procedimiento almacenado Inser tPerson . (El procedimiento
almacenado Inser tPerson se muestra a continuación y se declara en el modelo de almacenamiento). Se usa un
elemento ResultBinding para asignar un valor de columna devuelto por el procedimiento almacenado
(NewPersonID ) a una propiedad de tipo de entidad (PersonID ).
</InsertFunction>
</UpdateFunction>
</DeleteFunction>
En el siguiente código de Transact-SQL se describe el procedimiento almacenado Inser tPerson :
CREATE PROCEDURE [dbo].[InsertPerson]

@LastName nvarchar(50),
@FirstName nvarchar(50),
@HireDate datetime,
@EnrollmentDate datetime
AS
INSERT INTO dbo.Person (LastName,
FirstName,
HireDate,
EnrollmentDate)
VALUES (@LastName,
@FirstName,
@HireDate,
@EnrollmentDate);
SELECT SCOPE_IDENTITY() as NewPersonID;
ResultMapping (Elemento) (MSL)

El elemento ResultMapping del lenguaje de especificación de asignaciones (MSL) define la asignación entre una
importación de función en el modelo conceptual y un procedimiento almacenado en la base de datos subyacente
cuando se cumplen las condiciones siguientes:
La importación de función devuelve un tipo de entidad del modelo conceptual o un tipo complejo.
Los nombres de las columnas devueltas por el procedimiento almacenado no coinciden exactamente con los
nombres de las propiedades del tipo de entidad o el tipo complejo.
De forma predeterminada, la asignación entre las columnas devueltas por un procedimiento almacenado y un tipo
de entidad o un tipo complejo se basa en los nombres de las propiedades y de las columnas. Si los nombres de
columna no coinciden exactamente con los nombres de propiedad, debe utilizar el elemento ResultMapping para
definir la asignación. Para obtener un ejemplo de la asignación predeterminada, vea FunctionImportMapping
(elemento) (MSL).
El elemento ResultMapping es un elemento secundario del elemento FunctionImportMapping.
El elemento ResultMapping puede tener los siguientes elementos secundarios:
EntityTypeMapping (cero o más)
ComplexTypeMapping
No hay atributos aplicables al elemento ResultMapping .
Ejemplo
Observe el siguiente procedimiento almacenado:
CREATE PROCEDURE [dbo].[GetGrades]

@student_Id int
AS
SELECT EnrollmentID as enroll_id,
Grade as grade,
CourseID as course_id,
StudentID as student_id
FROM dbo.StudentGrade
WHERE StudentID = @student_Id
Considere también el siguiente tipo de entidad del modelo conceptual:
<EntityType Name="StudentGrade">
<Key>
<PropertyRef Name="EnrollmentID" />
</Key>
<Property Name="EnrollmentID" Type="Int32" Nullable="false"
<Property Name="CourseID" Type="Int32" Nullable="false" />
<Property Name="StudentID" Type="Int32" Nullable="false" />
<Property Name="Grade" Type="Decimal" Precision="3" Scale="2" />
</EntityType>
Para crear una importación de función que devuelva instancias del tipo de entidad anterior, la asignación entre las
columnas devueltas por el procedimiento almacenado y el tipo de entidad debe definirse en un elemento
ResultMapping :
<FunctionImportMapping FunctionImportName="GetGrades"
FunctionName="SchoolModel.Store.GetGrades" >
<ResultMapping>
<EntityTypeMapping TypeName="SchoolModel.StudentGrade">
<ScalarProperty Name="EnrollmentID" ColumnName="enroll_id"/>
<ScalarProperty Name="CourseID" ColumnName="course_id"/>
<ScalarProperty Name="StudentID" ColumnName="student_id"/>
<ScalarProperty Name="Grade" ColumnName="grade"/>
</ResultMapping>
ScalarProperty (Elemento) (MSL)

El elemento ScalarProper ty del lenguaje de especificación de asignaciones (MSL) asigna una propiedad en un
tipo de entidad del modelo conceptual, un tipo complejo o una asociación a una columna de tabla o a un
parámetro de procedimiento almacenado en la base de datos subyacente.
NOTE
Los procedimientos almacenados a los que están asignados las funciones de modificación se deben declarar en el modelo de
almacenamiento. Para obtener más información, vea elemento function (SSDL).
El elemento ScalarProper ty puede ser un elemento secundario de los siguientes elementos:

MappingFragment
InsertFunction
UpdateFunction
DeleteFunction
EndProperty
ComplexProperty
ResultMapping
Como elemento secundario del elemento MappingFragment , ComplexProper ty o EndProper ty , el elemento
ScalarProper ty asigna una propiedad del modelo conceptual a una columna de la base de datos. Como elemento
secundario del elemento Inser tFunction , UpdateFunction o DeleteFunction , el elemento ScalarProper ty
asigna una propiedad del modelo conceptual a un parámetro de procedimiento almacenado.
El elemento ScalarProper ty no puede tener elementos secundarios.
Los atributos que se aplican al elemento ScalarProper ty difieren en función del rol del elemento.
En la tabla siguiente se describen los atributos que se pueden aplicar cuando el elemento ScalarProper ty se
utiliza para asignar una propiedad del modelo conceptual a una columna de la base de datos:
Nombre Sí El nombre de la propiedad del modelo

ColumnName Sí El nombre de la columna de tabla que

se está asociando.
En la tabla siguiente se describen los atributos aplicables al elemento ScalarProper ty cuando se utiliza para
asignar una propiedad del modelo conceptual a un parámetro de procedimiento almacenado:
Nombre Sí El nombre de la propiedad del modelo

ParameterName Sí El nombre del parámetro que se está

asignando.
Versión No Actual o original , dependiendo de si

el valor actual o el valor original de la
propiedad se deben usar para las
comprobaciones de simultaneidad.
Ejemplo
En el ejemplo siguiente se muestra el elemento ScalarProper ty utilizado de dos maneras:
Para asignar las propiedades del tipo de entidad Person a las columnas de la tabla Person .
Para asignar las propiedades del tipo de entidad Person a los parámetros del procedimiento almacenado
UpdatePerson . Los procedimientos almacenados se declaran en el modelo de almacenamiento.
</MappingFragment>
</InsertFunction>
</UpdateFunction>
</DeleteFunction>
</EntitySetMapping>
Ejemplo
En el ejemplo siguiente se muestra el elemento ScalarProper ty que se usa para asignar las funciones de inserción
y eliminación de una asociación del modelo conceptual a los procedimientos almacenados en la base de datos. Los
procedimientos almacenados se declaran en el modelo de almacenamiento.
</EndProperty>
</EndProperty>
</EndProperty>
</EndProperty>
</InsertFunction>
</EndProperty>
</EndProperty>
</DeleteFunction>
UpdateFunction (Elemento) (MSL)

El elemento UpdateFunction del lenguaje de especificación de asignaciones (MSL) asigna la función de
actualización de un tipo de entidad del modelo conceptual a un procedimiento almacenado en la base de datos
NOTE
UpdateException.
El elemento UpdateFunction puede ser un elemento secundario del elemento ModificationFunctionMapping y

aplicarse al elemento EntityTypeMapping.
El elemento UpdateFunction puede tener los siguientes elementos secundarios:
ResultBinding (cero o uno)
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento UpdateFunction .


actualización está asignada. El
almacenamiento.

Ejemplo
El ejemplo siguiente se basa en el modelo School y muestra el elemento UpdateFunction que se usa para asignar
la función de actualización del tipo de entidad Person al procedimiento almacenado UpdatePerson . El
procedimiento almacenado UpdatePerson se declara en el modelo de almacenamiento.
</InsertFunction>
</UpdateFunction>
</DeleteFunction>
Especificación SSDL
El lenguaje de definición de esquemas de almacenamiento (SSDL) es un lenguaje basado en XML que describe el
modelo de almacenamiento de una aplicación Entity Framework.
En una aplicación Entity Framework, los metadatos del modelo de almacenamiento se cargan desde un archivo.
SSDL (escrito en SSDL) en una instancia de System. Data. Metadata. Edm. StoreItemCollection y es accesible
mediante métodos en el Clase System. Data. Metadata. Edm. MetadataWorkspace. Entity Framework usa los
metadatos del modelo de almacenamiento para traducir las consultas en el modelo conceptual para almacenar
comandos específicos.
El Entity Framework Designer (EF Designer) almacena la información del modelo de almacenamiento en un
archivo. edmx en tiempo de diseño. En tiempo de compilación, Entity Designer usa información en un archivo.
edmx para crear el archivo. SSDL que Entity Framework necesita en tiempo de ejecución.
Las versiones de SSDL se diferencian por los espacios de nombres XML.
VERSIÓ N DE SSDL ESPA C IO DE N O M B RES XM L
SSDL v1 https://schemas.microsoft.com/ado/2006/04/edm/ssdl
SSDL V2 https://schemas.microsoft.com/ado/2009/02/edm/ssdl
SSDL V3 https://schemas.microsoft.com/ado/2009/11/edm/ssdl
Association (Elemento) (SSDL)

Un elemento Association en el lenguaje de definición de esquemas de almacenamiento (SSDL) especifica las
columnas de tabla que participan en una restricción FOREIGN KEY en la base de datos subyacente. Dos elementos
End secundarios necesarios especifican las tablas de los extremos de la asociación y la multiplicidad en cada
extremo. Un elemento ReferentialConstraint opcional especifica los extremos principal y dependiente de la
asociación así como las columnas participantes. Si no hay ningún elemento ReferentialConstraint , se debe usar
un elemento AssociationSetMapping para especificar las asignaciones de columnas para la asociación.
El elemento Association puede tener los elementos secundarios siguientes (en el orden mostrado):
Documentación (cero o uno)
End (exactamente dos)
ReferentialConstraint (cero o uno)
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento Association .
Nombre Sí El nombre de la restricción de clave

externa correspondiente de la base de
datos subyacente.
NOTE
SSDL. Dos atributos personalizados cualesquiera no pueden tener nombres completos idénticos.
Ejemplo
En el ejemplo siguiente se muestra un elemento Association que utiliza un elemento ReferentialConstraint
para especificar las columnas que participan en la restricción de clave externa de FK_CustomerOrders :
<Association Name="FK_CustomerOrders">
<End Role="Customers"
Type="ExampleModel.Store.Customers" Multiplicity="1">
</End>
<End Role="Orders"
Type="ExampleModel.Store.Orders" Multiplicity="*" />
<Principal Role="Customers">
</Principal>
<Dependent Role="Orders">
</Dependent>
</Association>
AssociationSet (Elemento) (SSDL)

El elemento AssociationSet en el lenguaje de definición de esquemas de almacenamiento (SSDL) representa una
restricción de clave externa entre dos tablas en la base de datos subyacente. Las columnas de la tabla que
participan en la restricción de clave externa se especifican en un elemento Association. El elemento Association
que corresponde a un elemento AssociationSet determinado se especifica en el atributo Association del
elemento AssociationSet .
Los conjuntos de asociaciones SSDL están asignados a conjuntos de asociaciones CSDL mediante un elemento
AssociationSetMapping. Sin embargo, si la Asociación CSDL para un conjunto de asociaciones CSDL determinado
se define mediante un elemento ReferentialConstraint, no es necesario ningún elemento
AssociationSetMapping correspondiente. En este caso, si hay un elemento AssociationSetMapping , las
asignaciones que define se reemplazarán por el elemento ReferentialConstraint .
El elemento AssociationSet puede tener los elementos secundarios siguientes (en el orden mostrado):
End (cero o dos)
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento AssociationSet .
Nombre Sí El nombre de la restricción de clave

externa representada por el conjunto
de asociaciones.
Asociación Sí El nombre de la asociación que define

las columnas que participan en la
restricción de clave externa.
NOTE
Se puede aplicar cualquier número de atributos de anotación (atributos XML personalizados) al elemento AssociationSet .
Ejemplo
En el ejemplo siguiente se muestra un elemento AssociationSet que representa la restricción de clave externa
FK_CustomerOrders en la base de datos subyacente:
<AssociationSet Name="FK_CustomerOrders"
Association="ExampleModel.Store.FK_CustomerOrders">
<End Role="Customers" EntitySet="Customers" />
<End Role="Orders" EntitySet="Orders" />
</AssociationSet>
CollectionType (elemento) (SSDL)

El elemento CollectionType del lenguaje de definición de esquemas de almacenamiento (SSDL) especifica que el
tipo de valor devuelto de una función es una colección. El elemento CollectionType es un elemento secundario
del elemento ReturnType. El tipo de colección se especifica mediante el elemento secundario RowType:
NOTE
Ejemplo
En el ejemplo siguiente se muestra una función que usa un elemento CollectionType para especificar que la
función devuelve una colección de filas.
<Function Name="GetProducts" IsComposable="true" Schema="dbo">

<ReturnType>
<CollectionType>
<RowType>
<Property Name="ProductID" Type="int" Nullable="false" />
<Property Name="CategoryID" Type="bigint" Nullable="false" />
<Property Name="ProductName" Type="nvarchar" MaxLength="40" Nullable="false" />
<Property Name="UnitPrice" Type="money" />
<Property Name="Discontinued" Type="bit" />
</RowType>
</CollectionType>
</ReturnType>
</Function>
CommandText (Elemento) (SSDL)

El elemento CommandText del lenguaje de definición de esquemas de almacenamiento (SSDL) es un elemento
secundario del elemento function que permite definir una instrucción SQL que se ejecuta en la base de datos. El
elemento CommandText permite agregar funcionalidad similar a un procedimiento almacenado en la base de
datos, pero se define el elemento CommandText en el modelo de almacenamiento.
El elemento CommandText no puede tener elementos secundarios. El cuerpo del elemento CommandText debe
ser una instrucción SQL válida para la base de datos subyacente.
No hay atributos aplicables al elemento CommandText .
Ejemplo
En el ejemplo siguiente se muestra un elemento function con un elemento CommandText secundario. Exponga
la función UpdateProductInOrder como un método en el ObjectContext importándolos en el modelo
conceptual.
<Function Name="UpdateProductInOrder" IsComposable="false">

<CommandText>
UPDATE Orders
SET ProductId = @productId
WHERE OrderId = @orderId;
</CommandText>
<Parameter Name="productId"
Mode="In"
Type="int"/>
<Parameter Name="orderId"
Mode="In"
Type="int"/>
</Function>
DefiningQuery (Elemento) (SSDL)

El elemento DefiningQuer y del lenguaje de definición de esquemas de almacenamiento (SSDL) permite ejecutar
una instrucción SQL directamente en la base de datos subyacente. El elemento DefiningQuer y se utiliza
normalmente como una vista de base de datos, pero la vista se define en el modelo de almacenamiento en lugar
de en la base de datos. La vista definida en un elemento DefiningQuer y se puede asignar a un tipo de entidad en
el modelo conceptual a través de un elemento EntitySetMapping. Estas asignaciones son de solo lectura.
La sintaxis de SSDL siguiente muestra la declaración de un EntitySet seguido del elemento DefiningQuer y que
contiene una consulta utilizada para recuperar la vista.
<Schema>
<EntitySet Name="Tables" EntityType="Self.STable">
<DefiningQuery>
SELECT TABLE_CATALOG,
'test' as TABLE_SCHEMA,
TABLE_NAME
FROM INFORMATION_SCHEMA.TABLES
</DefiningQuery>
</EntitySet>
</Schema>
Puede usar procedimientos almacenados en el Entity Framework para habilitar escenarios de lectura y escritura en
las vistas. Puede usar una vista del origen de datos o una vista de Entity SQL como tabla base para recuperar datos
y para el procesamiento de cambios por parte de los procedimientos almacenados.
Puede usar el elemento DefiningQuer y para tener como destino Microsoft SQL Server Compact 3,5. Aunque
SQL Server Compact 3,5 no admite procedimientos almacenados, puede implementar una funcionalidad similar
con el elemento DefiningQuer y . Otro caso donde puede ser útil es en la creación de procedimientos
almacenados para resolver una desigualdad entre los tipos de datos utilizados en el lenguaje de programación y
los del origen de datos. Podría escribir una DefiningQuer y que toma un determinado conjunto de parámetros y,
a continuación, llama a un procedimiento almacenado con un conjunto diferente de parámetros, por ejemplo, un
procedimiento almacenado que elimina datos.
Dependent (Elemento) (SSDL)

El elemento dependiente del lenguaje de definición de esquemas de almacenamiento (SSDL) es un elemento
secundario del elemento ReferentialConstraint que define el extremo dependiente de una restricción FOREIGN KEY
(también denominada restricción referencial). El elemento dependiente especifica la columna (o columnas) de
una tabla que hace referencia a una columna de clave principal (o columnas). Los elementos Proper tyRef
especifican a qué columnas se hace referencia. El elemento principal especifica las columnas de clave principal a
las que hacen referencia las columnas que se especifican en el elemento dependiente .
El elemento dependiente puede tener los elementos secundarios siguientes (en el orden mostrado):
PropertyRef (uno o varios)
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento dependiente .
Rol Sí El mismo valor que el atributo role (si

se usa) del elemento end
correspondiente; de lo contrario, el
nombre de la tabla que contiene la
columna de referencia.
NOTE
Se puede aplicar cualquier número de atributos de anotación (atributos XML personalizados) al elemento dependiente . Sin
Ejemplo
En el ejemplo siguiente se muestra un elemento Association que utiliza un elemento ReferentialConstraint para
especificar las columnas que participan en la restricción de clave externa de FK_CustomerOrders . El elemento
dependiente especifica la columna CustomerID de la tabla Order como el extremo dependiente de la
restricción.
</End>
<End Role="Orders"
</Principal>
</Dependent>
</Association>
Documentation (Elemento) (SSDL)

El elemento Documentation del lenguaje de definición de esquemas de almacenamiento (SSDL) se puede usar
para proporcionar información sobre un objeto que se define en un elemento primario.
El elemento Documentation puede tener los elementos secundarios siguientes (en el orden mostrado):
Summar y : breve descripción del elemento primario. (cero o un elemento).
LongDescription : una descripción amplia del elemento primario. (cero o un elemento).
Documentation . Sin embargo, es posible que los atributos personalizados no pertenezcan a ningún espacio de
Ejemplo
En el ejemplo siguiente se muestra el elemento Documentation como un elemento secundario de un elemento
EntityType.
<EntityType Name="Customers">
<Documentation>
</Documentation>
<Key>
</Key>
<Property Name="CustomerId" Type="int" Nullable="false" />
<Property Name="Name" Type="nvarchar(max)" Nullable="false" />
</EntityType>
End (Elemento) (SSDL)

El elemento End en el lenguaje de definición de esquemas de almacenamiento (SSDL) especifica la tabla y el
número de filas de un extremo de una restricción FOREIGN KEY en la base de datos subyacente. El elemento End
puede ser un elemento secundario del elemento Association o del elemento AssociationSet. En cada caso, los
posibles elementos secundarios y atributos aplicables son diferentes.
Elemento End como elemento secundario del elemento Association
Un elemento End (como elemento secundario del elemento Association ) especifica la tabla y el número de filas
al final de una restricción FOREIGN KEY con los atributos Type y Multiplicity , respectivamente. Los extremos de
una restricción de clave externa se definen como parte de una asociación SSDL, la cual debe tener exactamente
dos extremos.
Aleliminar (cero o un elemento)
secundario de un elemento Association .
Tipo Sí El nombre completo del conjunto de

entidades SSDL que está en el extremo
de la restricción de clave externa.
Rol No El valor del atributo role en el elemento

principal o dependiente del elemento
ReferentialConstraint correspondiente
(si se usa).
Multiplicidad Sí 1 , 0.. 1 o * en función del número de

filas que pueden estar al final de la
restricción FOREIGN KEY.
1 indica que existe exactamente una fila
en el extremo de la restricción de clave
externa.
0.. 1 indica que hay cero o una fila en
el extremo de la restricción de clave
externa.
* indica que hay cero, una o más filas
en el extremo de la restricción de clave
externa.
NOTE
Ejemplo
En el ejemplo siguiente se muestra un elemento Association que define la restricción de clave externa de
FK_CustomerOrders . Los valores de multiplicidad especificados en cada elemento final indican que muchas
filas de la tabla Orders se pueden asociar a una fila de la tabla Customers , pero solo se puede asociar una fila de
la tabla Customers a una fila de la tabla Orders . Además, el elemento aldelete indica que todas las filas de la
tabla Orders que hacen referencia a una fila determinada de la tabla Customers se eliminarán si se elimina la fila
de la tabla Customers .
</End>
<End Role="Orders"
</Principal>
</Dependent>
</Association>
Elemento End como elemento secundario del elemento AssociationSet

El elemento End (como elemento secundario del elemento AssociationSet ) especifica una tabla en un extremo
de una restricción FOREIGN KEY en la base de datos subyacente.
secundario de un elemento AssociationSet .
#A4 Sí El nombre del conjunto de entidades

SSDL que está en el extremo de la
restricción de clave externa.
Rol No El valor de uno de los atributos de rol

especificados en un elemento final del
elemento Association correspondiente.
NOTE
Ejemplo
En el ejemplo siguiente se muestra un elemento EntityContainer con un elemento AssociationSet con dos
elementos End :
<EntityContainer Name="ExampleModelStoreContainer">
EntityType="ExampleModel.Store.Customers"
Schema="dbo" />
<EntitySet Name="Orders"
EntityType="ExampleModel.Store.Orders"
Schema="dbo" />
</AssociationSet>
</EntityContainer>
EntityContainer (Elemento) (SSDL)

Un elemento EntityContainer en el lenguaje de definición de esquemas de almacenamiento (SSDL) describe la
estructura del origen de datos subyacente en una aplicación Entity Framework: los conjuntos de entidades SSDL
(definidos en elementos EntitySet) representan las tablas de una base de datos, los tipos de entidad SSDL
(definidos en los elementos EntityType) representan las filas de una tabla, y los conjuntos de asociaciones
(definidos en los elementos AssociationSet) Un contenedor de entidades del modelo de almacenamiento se asigna
a un contenedor de entidades del modelo de conceptual a través del elemento EntityContainerMapping.
Un elemento EntityContainer puede tener cero o un elemento de documentación. Si hay un elemento de
documentación , debe preceder a todos los demás elementos secundarios.
Un elemento EntityContainer puede tener cero o más de los elementos secundarios siguientes (en el orden
mostrado):
EntitySet
AssociationSet
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento EntityContainer .
Nombre Sí Nombre del contenedor de entidades.

Este nombre no puede contener puntos
(.).
NOTE
Se puede aplicar cualquier número de atributos de anotación (atributos XML personalizados) al elemento EntityContainer .
Ejemplo
En el ejemplo siguiente se muestra un elemento EntityContainer que define dos conjuntos de entidades y un
conjunto de asociaciones. Observe que los nombres de los tipos de entidad y tipos de asociación están calificados
mediante el nombre del espacio de nombres del modelo conceptual.
Schema="dbo" />
Schema="dbo" />
</AssociationSet>
</EntityContainer>
EntitySet (Elemento) (SSDL)

Un elemento EntitySet en el lenguaje de definición de esquemas de almacenamiento (SSDL) representa una tabla
o una vista en la base de datos subyacente. Un elemento EntityType de SSDL representa una fila de la tabla o vista.
El atributo EntityType de un elemento EntitySet especifica el tipo de entidad SSDL determinado que representa
las filas de un conjunto de entidades SSDL. La asignación entre un conjunto de entidades CSDL y un conjunto de
entidades SSDL se especifica en un elemento EntitySetMapping.
El elemento EntitySet puede tener los elementos secundarios siguientes (en el orden mostrado):
DefiningQuery (cero o un elemento)
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento EntitySet .
NOTE
Algunos atributos (que no se enumeran aquí) pueden estar calificados con el alias de almacén . El Asistente para actualizar
modelo utiliza estos atributos al actualizar un modelo.
Nombre Sí El nombre del conjunto de entidades.
EntityType Sí El nombre completo del tipo de entidad

para el que el conjunto de entidades
contiene las instancias.
Esquema No El esquema de base de datos.
Table No La tabla de base de datos.
NOTE
Se puede aplicar cualquier número de atributos de anotación (atributos XML personalizados) al elemento EntitySet . Sin
Ejemplo
En el ejemplo siguiente se muestra un elemento EntityContainer que tiene dos elementos EntitySet y un
elemento AssociationSet :
Schema="dbo" />
Schema="dbo" />
</AssociationSet>
</EntityContainer>
EntityType (Elemento) (SSDL)

Un elemento EntityType en el lenguaje de definición de esquemas de almacenamiento (SSDL) representa una fila
de una tabla o vista de la base de datos subyacente. Un elemento EntitySet de SSDL representa la tabla o vista
donde están las filas. El atributo EntityType de un elemento EntitySet especifica el tipo de entidad SSDL
determinado que representa las filas de un conjunto de entidades SSDL. La asignación entre un tipo de entidad
SSDL y un tipo de entidad CSDL se especifica en un elemento EntityTypeMapping.
El elemento EntityType puede tener los elementos secundarios siguientes (en el orden mostrado):
Key (cero o un elemento)
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento EntityType .
Nombre Sí El nombre del tipo de entidad. Este

valor normalmente es igual que el
nombre de la tabla en la que el tipo de
entidad representa una fila. Este valor
no puede contener ningún punto (.).
NOTE
Se puede aplicar cualquier número de atributos de anotación (atributos XML personalizados) al elemento EntityType . Sin
Ejemplo
En el ejemplo siguiente se muestra un elemento EntityType con dos propiedades:
<Documentation>
</Documentation>
<Key>
</Key>
</EntityType>
Function (Elemento) (SSDL)

El elemento function del lenguaje de definición de esquemas de almacenamiento (SSDL) especifica un
procedimiento almacenado que existe en la base de datos subyacente.
El elemento function puede tener los elementos secundarios siguientes (en el orden mostrado):
Parámetro (cero o más)
CommandText (cero o uno)
ReturnType (cero o más)
Un tipo de valor devuelto para una función debe especificarse con el elemento ReturnType o el atributo
ReturnType (consulte a continuación), pero no ambos.
Los procedimientos almacenados que se especifican en el modelo de almacenamiento se pueden importar en el
modelo conceptual de una aplicación. Para obtener más información, vea consultar con procedimientos
almacenados. El elemento de función también se puede utilizar para definir funciones personalizadas en el
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento de función .
NOTE
Algunos atributos (que no se enumeran aquí) pueden estar calificados con el alias de almacén . El Asistente para actualizar
modelo utiliza estos atributos al actualizar un modelo.
Nombre Sí Nombre del procedimiento almacenado.
ReturnType No El tipo de valor devuelto del

procedimiento almacenado.
Agregada No True si el procedimiento almacenado

devuelve un valor agregado; en caso
contrario, false .
BuiltIn No True si la función es una función

integrada1 ; en caso contrario, false .
StoreFunctionName No Nombre del procedimiento almacenado.
NiladicFunction No True si la función es una función

niládicas2 ; De lo contrario, false .
IsComposable No True si la función es una función que

admite composición3 ; De lo contrario,
false .
ParameterTypeSemantics No La enumeración que define la semántica

de tipos que se utiliza para resolver
sobrecargas de función. La
enumeración se define en el manifiesto
del proveedor por cada definición de
función. El valor predeterminado es
AllowImplicitConversion .
Esquema No El nombre del esquema donde se define

el procedimiento almacenado.
1 una función integrada es una función que se define en la base de datos. Para obtener
información sobre las
funciones que se definen en el modelo de almacenamiento, vea CommandText (elemento) (SSDL).
2 una función niládicas es una función que no acepta parámetros y, cuando se llama, no requiere paréntesis.
3 dos funciones son comparables si la salida de una función puede ser la entrada para la otra función.
NOTE
Se puede aplicar cualquier número de atributos de anotación (atributos XML personalizados) al elemento de función . Sin
Ejemplo
En el ejemplo siguiente se muestra un elemento function que corresponde al procedimiento almacenado
UpdateOrderQuantity . El procedimiento almacenado acepta dos parámetros y no devuelve ningún valor.
<Function Name="UpdateOrderQuantity"
Aggregate="false"
BuiltIn="false"
NiladicFunction="false"
IsComposable="false"
ParameterTypeSemantics="AllowImplicitConversion"
Schema="dbo">
<Parameter Name="orderId" Type="int" Mode="In" />
<Parameter Name="newQuantity" Type="int" Mode="In" />
</Function>
Key (Elemento) (SSDL)

El elemento key del lenguaje de definición de esquemas de almacenamiento (SSDL) representa la clave principal
de una tabla en la base de datos subyacente. Key es un elemento secundario de un elemento EntityType, que
representa una fila de una tabla. La clave principal se define en el elemento key haciendo referencia a uno o varios
elementos de propiedad que se definen en el elemento EntityType .
El elemento key puede tener los elementos secundarios siguientes (en el orden mostrado):
No hay atributos aplicables al elemento key .
Ejemplo
En el ejemplo siguiente se muestra un elemento EntityType con una clave que hace referencia a una propiedad:
<Documentation>
</Documentation>
<Key>
</Key>
</EntityType>
OnDelete (Elemento) (SSDL)

El elemento aldelete del lenguaje de definición de esquemas de almacenamiento (SSDL) refleja el
comportamiento de la base de datos cuando se elimina una fila que participa en una restricción FOREIGN KEY. Si
la acción se establece en Cascade , también se eliminarán las filas que hacen referencia a una fila que se va a
eliminar. Si la acción se establece en None , las filas que hacen referencia a una fila que se va a eliminar también
no se eliminan. Un elemento aldelete es un elemento secundario de un elemento end.
Un elemento aldelete puede tener los elementos secundarios siguientes (en el orden mostrado):
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento aleliminar .
Acción Sí Cascade o None . (El valor

restringido es válido, pero tiene el
mismo comportamiento que ninguno ).
NOTE
Se puede aplicar cualquier número de atributos de anotación (atributos XML personalizados) al elemento aleliminar . Sin
Ejemplo
En el ejemplo siguiente se muestra un elemento Association que define la restricción de clave externa de
FK_CustomerOrders . El elemento aldelete indica que se eliminarán todas las filas de la tabla Orders que
hagan referencia a una fila determinada de la tabla Customers si se elimina la fila de la tabla Customers .
</End>
<End Role="Orders"
</Principal>
</Dependent>
</Association>
Parameter (Elemento) (SSDL)

El elemento Parameter del lenguaje de definición de esquemas de almacenamiento (SSDL) es un elemento
secundario del elemento function que especifica los parámetros de un procedimiento almacenado en la base de
datos.
Tipo Sí El tipo de parámetro.
Modo No In , out o INOUT dependiendo de si el

parámetro es un parámetro de entrada,
de salida o de entrada/salida.
MaxLength No Longitud máxima permitida del

parámetro.
Precisión No La precisión del parámetro.
Escala No La escala del parámetro.

espacial. Válido solo para los
parámetros de los tipos espaciales. Para
obtener más información, vea SRID y
SRID (SQL Server).
NOTE
Ejemplo
En el ejemplo siguiente se muestra un elemento function que tiene dos elementos Parameter que especifican
parámetros de entrada:
Aggregate="false"
BuiltIn="false"
Schema="dbo">
</Function>
Principal (Elemento) (SSDL)

El elemento principal del lenguaje de definición de esquemas de almacenamiento (SSDL) es un elemento
secundario del elemento ReferentialConstraint que define el extremo principal de una restricción FOREIGN KEY
(también denominada restricción referencial). El elemento principal especifica la columna (o columnas) de clave
principal de una tabla a la que hace referencia otra columna (o columnas). Los elementos Proper tyRef
especifican a qué columnas se hace referencia. El elemento dependiente especifica las columnas que hacen
referencia a las columnas de clave principal que se especifican en el elemento principal .
El elemento principal puede tener los elementos secundarios siguientes (en el orden mostrado):
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento principal .
Rol Sí El mismo valor que el atributo role (si

se usa) del elemento end
correspondiente; de lo contrario, el
nombre de la tabla que contiene la
columna a la que se hace referencia.
NOTE
Se puede aplicar cualquier número de atributos de anotación (atributos XML personalizados) al elemento principal . Sin
Ejemplo
En el ejemplo siguiente se muestra un elemento Association que utiliza un elemento ReferentialConstraint para
especificar las columnas que participan en la restricción de clave externa de FK_CustomerOrders . El elemento
principal especifica la columna CustomerID de la tabla Customer como el extremo principal de la restricción.
</End>
<End Role="Orders"
</Principal>
</Dependent>
</Association>
Property (Elemento) (SSDL)

El elemento Proper ty del lenguaje de definición de esquemas de almacenamiento (SSDL) representa una
columna de una tabla en la base de datos subyacente. Los elementos de propiedad son elementos secundarios
de elementos EntityType, que representan las filas de una tabla. Cada elemento de propiedad definido en un
elemento EntityType representa una columna.
Un elemento Proper ty no puede tener elementos secundarios.
Nombre Sí El nombre de la columna

correspondiente.
Tipo Sí El tipo de la columna correspondiente.
Admisión de valores NULL No True (valor predeterminado) o false ,

dependiendo de si la columna
correspondiente puede tener un valor
null.
DefaultValue No El valor predeterminado de la columna

correspondiente.
MaxLength No La longitud máxima de la columna

correspondiente.

valor de columna correspondiente se
almacenará como una cadena de
longitud fija.
Precisión No La precisión de la columna

correspondiente.
Escala No La escala de la columna

correspondiente.

valor de columna correspondiente se
almacenará como una cadena Unicode.

de datos.

StoreGeneratedPattern No None , Identity (si el valor de la

columna correspondiente es una
identidad que se genera en la base de
datos) o calculado (si el valor de la
columna correspondiente se calcula en
la base de datos). No es válido para las
propiedades RowType.
NOTE
Se puede aplicar cualquier número de atributos de anotación (atributos XML personalizados) al elemento de propiedad .
Ejemplo
En el ejemplo siguiente se muestra un elemento EntityType con dos elementos Proper ty secundarios:
<Documentation>
</Documentation>
<Key>
</Key>
</EntityType>
PropertyRef (Elemento) (SSDL)

El elemento Proper tyRef en el lenguaje de definición de esquemas de almacenamiento (SSDL) hace referencia a
una propiedad definida en un elemento EntityType para indicar que la propiedad realizará uno de los roles
siguientes:
Formar parte de la clave principal de la tabla que el EntityType representa. Se pueden usar uno o varios
elementos Proper tyRef para definir una clave principal. Para obtener más información, vea Key (Elemento).
Ser el extremo dependiente o principal de una restricción referencial. Para obtener más información, vea
ReferentialConstraint (Elemento).
El elemento Proper tyRef solo puede tener los siguientes elementos secundarios:
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento Proper tyRef .
Nombre Sí Nombre de la propiedad a la que se

hace referencia.
NOTE
Se puede aplicar cualquier número de atributos de anotación (atributos XML personalizados) al elemento Proper tyRef . Sin
Ejemplo
En el ejemplo siguiente se muestra un elemento Proper tyRef que se usa para definir una clave principal haciendo
referencia a una propiedad que se define en un elemento EntityType .
<Documentation>
</Documentation>
<Key>
</Key>
</EntityType>
ReferentialConstraint (Elemento) (SSDL)

El elemento ReferentialConstraint del lenguaje de definición de esquemas de almacenamiento (SSDL)
representa una restricción de clave externa (también denominada restricción de integridad referencial) en la base
de datos subyacente. Los extremos principal y dependiente de la restricción se especifican mediante los elementos
secundarios Principal y Dependent, respectivamente. La referencia a las columnas que participan en los extremos
principal y dependiente se realiza mediante elementos PropertyRef.
El elemento ReferentialConstraint es un elemento secundario opcional del elemento Association. Si no se utiliza
un elemento ReferentialConstraint para asignar la restricción FOREIGN KEY especificada en el elemento
Association , se debe usar un elemento AssociationSetMapping para hacerlo.
El elemento ReferentialConstraint puede tener los siguientes elementos secundarios:
Principal (exactamente uno)
Dependiente (exactamente uno)
ReferentialConstraint . Sin embargo, es posible que los atributos personalizados no pertenezcan a ningún
espacio de nombres XML reservado para SSDL. Dos atributos personalizados cualesquiera no pueden tener
nombres completos idénticos.
Ejemplo
En el ejemplo siguiente se muestra un elemento Association que utiliza un elemento ReferentialConstraint
para especificar las columnas que participan en la restricción de clave externa de FK_CustomerOrders :
</End>
<End Role="Orders"
</Principal>
</Dependent>
</Association>
ReturnType (elemento) (SSDL)

El elemento ReturnType del lenguaje de definición de esquemas de almacenamiento (SSDL) especifica el tipo de
valor devuelto para una función que se define en un elemento de función . Un tipo de valor devuelto de función
también se puede especificar con un atributo ReturnType .
El tipo de valor devuelto de una función se especifica con el atributo Type o el elemento ReturnType .
El elemento ReturnType puede tener los siguientes elementos secundarios:
CollectionType (uno)
NOTE
Se puede aplicar cualquier número de atributos de anotación (atributos XML personalizados) al elemento ReturnType . Sin
Ejemplo
En el ejemplo siguiente se utiliza una función que devuelve una colección de filas.
<ReturnType>
<CollectionType>
<RowType>
</RowType>
</CollectionType>
</ReturnType>
</Function>
RowType (elemento) (SSDL)

Un elemento RowType en el lenguaje de definición de esquemas de almacenamiento (SSDL) define una
estructura sin nombre como un tipo de valor devuelto para una función definida en el almacén.
Un elemento RowType es el elemento secundario del elemento CollectionType :
Un elemento RowType puede tener los siguientes elementos secundarios:
Property (uno o varios)
Ejemplo
En el ejemplo siguiente se muestra una función de almacenamiento que usa un elemento CollectionType para
especificar que la función devuelve una colección de filas (tal y como se especifica en el elemento RowType ).

<ReturnType>
<CollectionType>
<RowType>
</RowType>
</CollectionType>
</ReturnType>
</Function>
Schema (Elemento) (SSDL)

El elemento Schema en el lenguaje de definición de esquemas de almacenamiento (SSDL) es el elemento raíz de
una definición de modelo de almacenamiento. Contiene las definiciones para los objetos, las funciones y los
contenedores que conforman un modelo de almacenamiento.
El elemento Schema puede contener cero o más de los siguientes elementos secundarios:
Asociación
EntityType
EntityContainer
Función
El elemento Schema usa el atributo namespace para definir el espacio de nombres para el tipo de entidad y los
objetos de asociación en un modelo de almacenamiento. Dentro de un espacio de nombres, no puede haber dos
objetos con el mismo nombre.
Un espacio de nombres del modelo de almacenamiento es diferente del espacio de nombres XML del elemento
Schema . Un espacio de nombres del modelo de almacenamiento (tal y como se define en el atributo de espacio
de nombres ) es un contenedor lógico para tipos de entidad y tipos de asociación. El espacio de nombres XML
(indicado por el atributo xmlns ) de un elemento Schema es el espacio de nombres predeterminado para los
elementos secundarios y los atributos del elemento Schema . Los espacios de nombres XML con el formato
https://schemas.microsoft.com/ado/YYYY/MM/edm/ssdl (donde YYYY y MM representan un año y un mes
respectivamente) se reservan para SSDL. No puede haber elementos y atributos personalizados en espacios de
nombres que tengan este formato.
En la tabla siguiente se describen los atributos que se pueden aplicar al elemento Schema .
Espacio de nombres Sí El espacio de nombres del modelo de

almacenamiento. El valor del atributo
namespace se usa para formar el
nombre completo de un tipo. Por
nombres ExampleModel. Store, el
nombre completo del EntityType es
ExampleModel. Store. Customer.
Las siguientes cadenas no se pueden
usar como el valor del atributo
namespace : System , Transient o
EDM . El valor del atributo namespace
no puede ser el mismo que el valor del
atributo namespace del elemento
Schema de CSDL.
Alias No Un identificador usado en lugar del

nombre del espacio de nombres. Por
nombres ExampleModel. Store y el valor
del atributo alias es StorageModel,
puede usar StorageModel. Customer
como nombre completo del
EntityType.
Proveedor Sí Proveedor de datos.
ProviderManifestToken Sí Un token que indica al proveedor qué

manifiesto del proveedor debe devolver.
No se define ningún formato para el
token. El proveedor define los valores
para el token. Para obtener información
sobre los tokens del manifiesto del
proveedor de SQL Server, vea SqlClient
para Entity Framework.
Ejemplo
En el ejemplo siguiente se muestra un elemento Schema que contiene un elemento EntityContainer , dos
elementos EntityType y un elemento Association .
<Schema Namespace="ExampleModel.Store"
Alias="Self" Provider="System.Data.SqlClient"
ProviderManifestToken="2008"
xmlns="https://schemas.microsoft.com/ado/2009/11/edm/ssdl">
Schema="dbo" />
Schema="dbo" />
</AssociationSet>
</EntityContainer>
<Documentation>
</Documentation>
<Key>
</Key>
</EntityType>
<EntityType Name="Orders" xmlns:c="http://CustomNamespace">
<Key>
</Key>
<Property Name="OrderId" Type="int" Nullable="false"
c:CustomAttribute="someValue"/>
<Property Name="ProductId" Type="int" Nullable="false" />
<Property Name="Quantity" Type="int" Nullable="false" />
<c:CustomElement>
Custom data here.
</c:CustomElement>
</EntityType>
</End>
<End Role="Orders"
</Principal>
</Dependent>
</Association>
Aggregate="false"
BuiltIn="false"
Schema="dbo">
</Function>
<Function Name="UpdateProductInOrder" IsComposable="false">
<CommandText>
UPDATE Orders
SET ProductId = @productId
WHERE OrderId = @orderId;
</CommandText>
<Parameter Name="productId"
Mode="In"
Type="int"/>
<Parameter Name="orderId"
Mode="In"
Type="int"/>
</Function>
</Schema>
Atributos de anotación
Los atributos de anotación (Annotation) del lenguaje de definición de esquemas de almacenamiento (SSDL) son
atributos XML personalizados del modelo de almacenamiento que proporcionan metadatos adicionales sobre los
elementos del modelo de almacenamiento. Además de tener una estructura XML válida, las siguientes
restricciones se aplican a los atributos de anotación:
Los atributos de anotación no deben estar en ningún espacio de nombres XML reservado para SSDL.
Dos atributos de anotación cualesquiera no pueden tener el mismo nombre completo.
Se pueden aplicar varios atributos de anotación a un elemento SSDL determinado. Se puede tener acceso a los
metadatos contenidos en los elementos Annotation en tiempo de ejecución mediante el uso de clases en el
espacio de nombres System. Data. Metadata. Edm.
Ejemplo
En el ejemplo siguiente se muestra un elemento EntityType que tiene un atributo Annotation aplicado a la
propiedad OrderID . En el ejemplo también se muestra un elemento Annotation agregado al elemento
EntityType .

<Key>
</Key>
<c:CustomElement>
Custom data here.
</c:CustomElement>
</EntityType>
Annotation (Elementos) (SSDL)

Los elementos Annotation del lenguaje de definición de esquemas de almacenamiento (SSDL) son elementos XML
personalizados del modelo de almacenamiento que proporcionan metadatos adicionales sobre el modelo de
almacenamiento. Además de tener una estructura XML válida, las siguientes restricciones se aplican a los
elementos Annotation:
Los elementos Annotation no deben estar en un espacio de nombres de XML que esté reservado para SSDL.
Los nombres completos de dos elementos Annotation cualesquiera no deben ser los mismos.
Los elementos Annotation deben aparecer después de todos los demás elementos secundarios de un elemento
SSDL determinado.
Más de un elemento Annotation puede ser un elemento secundario de un elemento SSDL determinado. A partir
de la .NET Framework versión 4, se puede tener acceso a los metadatos contenidos en los elementos Annotation
en tiempo de ejecución mediante el uso de clases en el espacio de nombres System. Data. Metadata. Edm.
Ejemplo
En el ejemplo siguiente se muestra un elemento EntityType que tiene un elemento Annotation (CustomElement ).
En el ejemplo también se muestra un atributo de anotación aplicado a la propiedad OrderID .

<Key>
</Key>
<c:CustomElement>
Custom data here.
</c:CustomElement>
</EntityType>
Facetas (SSDL)
Las facetas del lenguaje de definición de esquema de almacenamiento (SSDL) representan restricciones sobre los
tipos de columna que se especifican en elementos Property. Las caras se implementan como atributos XML en los
elementos de propiedad .
En la tabla siguiente se describen las facetas que se admiten en SSDL:
FA C ETA DESC RIP C IÓ N
Intercalación Especifica la secuencia de intercalación (o secuencia de orden)

que se va a usar cuando se realicen las operaciones de
comparación y ordenación sobre los valores de la propiedad.
FixedLength Especifica si la longitud del valor de la columna puede variar.
MaxLength Especifica la longitud máxima del valor de la columna.
Precisión Para las propiedades de tipo decimal, especifica el número de

dígitos que puede tener un valor de propiedad. Para las
propiedades de tipo Time , DateTime y DateTimeOffset ,
especifica el número de dígitos para la parte fraccionaria de
los segundos del valor de la columna.
Escala Especifica el número de dígitos que puede haber a la derecha

del separador de decimales para el valor de la columna.
Unicode Indica si el valor de la columna está almacenado como

Unicode.
Definir el diseñador de consultas-EF
En este tutorial se muestra cómo agregar una consulta de definición y un tipo de entidad correspondiente a un
modelo mediante el diseñador de EF. Una consulta de definición se usa normalmente para proporcionar una
funcionalidad similar a la que proporciona una vista de base de datos, pero la vista se define en el modelo, no en la
base de datos. Una consulta de definición permite ejecutar una instrucción SQL que se especifica en el
elemento DefiningQuer y de un archivo. edmx. Para obtener más información, vea DefiningQuer y en la
especificación de SSDL.
Al utilizar las consultas de definición, también debe definir un tipo de entidad en el modelo. El tipo de entidad se
utiliza para exponer los datos expuestos por la consulta de definición. Tenga en cuenta que los datos que se
exponen a través de este tipo de entidad son de solo lectura.
Las consultas con parámetros no se pueden ejecutar como consultas de definición. Sin embargo, los datos se
pueden actualizar asignando las funciones de inserción, actualización y eliminación del tipo de entidad que los
muestra a los procedimientos almacenados. Para obtener más información, vea Insert, Update y DELETE con
En este tema se muestra cómo realizar las siguientes tareas.
Agregar una consulta de definición
Agregar un tipo de entidad al modelo
Asignar la consulta de definición al tipo de entidad
Prerequisites
En este tutorial se usa Visual Studio 2012 o una versión más reciente.
Abra Visual Studio.
En el panel izquierdo, haga clic en Visual C# y, a continuación, seleccione la plantilla aplicación de consola .
Escriba DefiningQuer ySample como nombre del proyecto y haga clic en Aceptar .
Creación de un modelo basado en la base de datos School

Haga clic con el botón secundario en el nombre del proyecto en Explorador de soluciones, seleccione
Escriba DefiningQuer yModel. edmx como nombre de archivo y, a continuación, haga clic en Agregar .
Haga clic en nueva conexión. En el cuadro de diálogo Propiedades de conexión, escriba el nombre del
servidor (por ejemplo, LocalDB)\mssqllocaldb ), seleccione el método de autenticación,
escriba School para el nombre de la base de datos y, a continuación, haga clic en Aceptar . El cuadro de
diálogo elegir la conexión de datos se actualiza con la configuración de conexión de la base de datos.
En el cuadro de diálogo elija los objetos de base de datos, compruebe el nodo tablas . Se agregarán todas
las tablas al modelo School .
En Explorador de soluciones, haga clic con el botón secundario en el archivo DefiningQuer yModel. edmx
y seleccione abrir con. ...
Seleccione Editor XML (texto) .
Haga clic en sí si se le solicita el mensaje siguiente:
Agregar una consulta de definición

En este paso, usaremos el editor XML para agregar una consulta de definición y un tipo de entidad a la sección
SSDL del archivo. edmx.
Agregue un elemento de EntitySet a la sección SSDL del archivo. edmx (línea 5 a 13). Especifique lo siguiente:
Solo se especifican los atributos Name y EntityType del elemento de EntitySet .
El nombre completo del tipo de entidad se usa en el atributo EntityType .
La instrucción SQL que se va a ejecutar se especifica en el elemento DefiningQuer y .

<edmx:StorageModels>
<Schema Namespace="SchoolModel.Store" Alias="Self" Provider="System.Data.SqlClient"
ProviderManifestToken="2008"
xmlns:store="http://schemas.microsoft.com/ado/2007/12/edm/EntityStoreSchemaGenerator"
xmlns="http://schemas.microsoft.com/ado/2009/11/edm/ssdl">
<EntityContainer Name="SchoolModelStoreContainer">
<EntitySet Name="GradeReport" EntityType="SchoolModel.Store.GradeReport">
<DefiningQuery>
SELECT CourseID, Grade, FirstName, LastName
FROM StudentGrade
JOIN
(SELECT * FROM Person WHERE EnrollmentDate IS NOT NULL) AS p
ON StudentID = p.PersonID
</DefiningQuery>
</EntitySet>
<EntitySet Name="Course" EntityType="SchoolModel.Store.Course" store:Type="Tables" Schema="dbo" />
Agregue el elemento EntityType a la sección SSDL del archivo. edmx. como se muestra a continuación. Tenga
en cuenta lo siguiente:
El valor del atributo Name corresponde al valor del atributo EntityType en el elemento EntitySet
anterior, aunque el nombre completo del tipo de entidad se usa en el atributo EntityType .
Los nombres de propiedad corresponden a los nombres de columna devueltos por la instrucción SQL en
el elemento DefiningQuer y (arriba).
En este ejemplo, la clave de entidad consta de tres propiedades para garantizar un valor de clave único.
<EntityType Name="GradeReport">
<Key>
<PropertyRef Name="CourseID" />
<PropertyRef Name="FirstName" />
<PropertyRef Name="LastName" />
</Key>
<Property Name="CourseID"
Type="int"
Nullable="false" />
<Property Name="Grade"
Type="decimal"
Precision="3"
Scale="2" />
<Property Name="FirstName"
Type="nvarchar"
Nullable="false"
MaxLength="50" />
<Property Name="LastName"
Type="nvarchar"
Nullable="false"
MaxLength="50" />
</EntityType>
NOTE
Si posteriormente ejecuta el cuadro de diálogo Asistente para actualizar modelo , se sobrescribirán los cambios
realizados en el modelo de almacenamiento, incluida la definición de las consultas.
Agregar un tipo de entidad al modelo

En este paso se agregará el tipo de entidad al modelo conceptual mediante el diseñador de EF. Tenga en cuenta lo
siguiente:
El nombre de la entidad corresponde al valor del atributo EntityType en el elemento EntitySet anterior.
Los nombres de propiedad corresponden a los nombres de columna devueltos por la instrucción SQL en el
elemento DefiningQuer y anterior.
En este ejemplo, la clave de entidad consta de tres propiedades para garantizar un valor de clave único.
Abra el modelo en el diseñador de EF.
Haga doble clic en DefiningQueryModel. edmx.
Por ejemplo , en el siguiente mensaje:
Haga clic con el botón secundario en la superficie del diseñador y seleccione Agregar nuevo ->entidad. .
Especifique GradeRepor t para el nombre de entidad y el CourseID para la propiedad de clave .
Haga clic con el botón secundario en la entidad GradeRepor t y seleccione agregar nuevo -> propiedad
escalar .
Cambie el nombre predeterminado de la propiedad a FirstName .
Agregue otra propiedad escalar y especifique LastName como nombre.
Agregue otra propiedad escalar y especifique grade como el nombre.
En la ventana propiedades , cambie la propiedad tipo de grado a decimal .
Seleccione las propiedades FirstName y LastName .
En la ventana propiedades , cambie el valor de la propiedad EntityKey a true .
Como resultado, se han agregado los siguientes elementos a la sección CSDL del archivo. edmx.
<EntitySet Name="GradeReport" EntityType="SchoolModel.GradeReport" />
<EntityType Name="GradeReport">
. . .
</EntityType>
Asignar la consulta de definición al tipo de entidad

En este paso, usaremos la ventana detalles de la asignación para asignar los tipos de entidad conceptual y de
almacenamiento.
Haga clic con el botón secundario en la entidad GradeRepor t en la superficie de diseño y seleccione
asignación de tabla .
Se muestra la ventana detalles de la asignación .
Seleccione GradeRepor t en la lista desplegable <agregar una tabla o vista> (que se encuentra en la
tabla s).
Aparecen las asignaciones predeterminadas entre el tipo de entidad conceptual y Storage GradeRepor t .
Asignación de
Como resultado, el elemento EntitySetMapping se agrega a la sección de asignación del archivo. edmx.
<EntitySetMapping Name="GradeReports">
<EntityTypeMapping TypeName="IsTypeOf(SchoolModel.GradeReport)">
<MappingFragment StoreEntitySet="GradeReport">
<ScalarProperty Name="Grade" ColumnName="Grade" />
</MappingFragment>
</EntitySetMapping>
Realice la compilación de la aplicación.
Llamar a la consulta de definición en el código

Ahora puede ejecutar la consulta de definición mediante el tipo de entidad GradeRepor t .

{
var report = context.GradeReports.FirstOrDefault();
Console.WriteLine("{0} {1} got {2}",
report.FirstName, report.LastName, report.Grade);
}
Procedimientos almacenados con varios conjuntos de
resultados
A veces, al utilizar procedimientos almacenados, deberá devolver más de un conjunto de resultados. Este escenario
se usa normalmente para reducir el número de recorridos de ida y vuelta de base de datos necesarios para crear
una sola pantalla. Antes de EF5, Entity Framework permitiría que se llamara al procedimiento almacenado, pero
solo devolvería el primer conjunto de resultados al código de llamada.
En este artículo se muestran dos formas de usar para tener acceso a más de un conjunto de resultados de un
procedimiento almacenado en Entity Framework. Una que usa solo código y funciona con Code First y el diseñador
de EF y otro que solo funciona con EF Designer. Las herramientas y la compatibilidad con API para esto deberían
mejorar en versiones futuras de Entity Framework.
Modelo
En los ejemplos de este artículo se usa un blog básico y un modelo de publicaciones en el que un blog tiene
muchas publicaciones y una publicación pertenece a un solo blog. Usaremos un procedimiento almacenado en la
base de datos que devuelva todos los blogs y publicaciones, algo parecido a esto:
CREATE PROCEDURE [dbo].[GetAllBlogsAndPosts]

AS
SELECT * FROM dbo.Blogs
SELECT * FROM dbo.Posts
Obtener acceso a varios conjuntos de resultados con código

Podemos ejecutar usar código para emitir un comando SQL sin formato para ejecutar nuestro procedimiento
almacenado. La ventaja de este enfoque es que funciona tanto con Code First como con el diseñador EF.
Para conseguir que funcionen varios conjuntos de resultados, es necesario colocarlos en la API de ObjectContext
mediante la interfaz IObjectContextAdapter.
Una vez que tenemos un ObjectContext, podemos usar el método translate para traducir los resultados de nuestro
procedimiento almacenado en entidades que se pueden seguir y usar en EF como normal. En el ejemplo de código
siguiente se muestra esto en acción.
{
// If using Code First we need to make sure the model is built before we open the connection
// This isn't required for models created with the EF Designer
db.Database.Initialize(force: false);
// Create a SQL command to execute the sproc

var cmd = db.Database.Connection.CreateCommand();
cmd.CommandText = "[dbo].[GetAllBlogsAndPosts]";
try
{
db.Database.Connection.Open();
// Run the sproc
var reader = cmd.ExecuteReader();
// Read Blogs from the first result set

var blogs = ((IObjectContextAdapter)db)
.ObjectContext
.Translate<Blog>(reader, "Blogs", MergeOption.AppendOnly);
foreach (var item in blogs)

{
}
// Move to second result set and read Posts

reader.NextResult();
var posts = ((IObjectContextAdapter)db)
.ObjectContext
.Translate<Post>(reader, "Posts", MergeOption.AppendOnly);
foreach (var item in posts)

{
Console.WriteLine(item.Title);
}
}
finally
{
db.Database.Connection.Close();
}
}
El método translate acepta el lector que se ha recibido cuando se ejecuta el procedimiento, un nombre de EntitySet
y un MergeOption. El nombre de EntitySet será el mismo que el de la propiedad DbSet en el contexto derivado. La
enumeración MergeOption controla cómo se administran los resultados si la misma entidad ya existe en la
memoria.
Aquí se recorre en iteración la colección de blogs antes de que se llame a NextResult, lo que es importante con el
código anterior, ya que se debe consumir el primer conjunto de resultados antes de pasar al siguiente conjunto de
resultados.
Una vez que se llama a los dos métodos de traducción, EF realiza el seguimiento de las entidades blog y post de la
misma manera que cualquier otra entidad, por lo que se puede modificar o eliminar y guardar como normal.
NOTE
EF no tiene en cuenta ninguna asignación al crear entidades mediante el método translate. Simplemente coincidentes con los
nombres de columna del conjunto de resultados con los nombres de propiedad de las clases.
NOTE
Si tiene habilitada la carga diferida, el acceso a la propiedad postes en una de las entidades del blog, EF se conectará a la base
de datos para cargar de forma diferida todas las publicaciones, aunque ya se hayan cargado todas. Esto se debe a que EF no
puede saber si ha cargado o no todas las publicaciones o si hay más en la base de datos. Si desea evitar esto, tendrá que
deshabilitar la carga diferida.
Varios conjuntos de resultados con configurado en EDMX

NOTE
Debe tener como destino .NET Framework 4,5 para poder configurar varios conjuntos de resultados en EDMX. Si el destino
es .NET 4,0, puede usar el método basado en código que se muestra en la sección anterior.
Si usa el diseñador de EF, también puede modificar el modelo para que conozca los diferentes conjuntos de
resultados que se devolverán. Lo que hay que saber antes de la mano es que las herramientas no tienen un
conjunto de resultados múltiple, por lo que tendrá que editar manualmente el archivo edmx. La edición del archivo
edmx como este funcionará, pero también interrumpirá la validación del modelo en VS. Por lo tanto, si valida el
modelo, siempre se producirán errores.
Para ello, debe agregar el procedimiento almacenado al modelo como lo haría para una sola consulta de
conjunto de resultados.
Una vez hecho esto, debe hacer clic con el botón derecho en el modelo y seleccionar abrir con. a
continuación, XML
Una vez que tenga el modelo abierto como XML, debe realizar los siguientes pasos:
Busque el tipo complejo y la importación de función en el modelo:

<edmx:ConceptualModels>
...
<FunctionImport Name="GetAllBlogsAndPosts" ReturnType="Collection(BlogModel.GetAllBlogsAndPosts_Result)"

/>
...
<ComplexType Name="GetAllBlogsAndPosts_Result">
<Property Type="Int32" Name="BlogId" Nullable="false" />
<Property Type="String" Name="Name" Nullable="false" MaxLength="255" />
<Property Type="String" Name="Description" Nullable="true" />
</ComplexType>
...
</edmx:ConceptualModels>
Quitar el tipo complejo

Actualice la importación de la función para que se asigne a las entidades; en nuestro caso, tendrá un aspecto
similar al siguiente:
<FunctionImport Name="GetAllBlogsAndPosts">
<ReturnType EntitySet="Blogs" Type="Collection(BlogModel.Blog)" />
<ReturnType EntitySet="Posts" Type="Collection(BlogModel.Post)" />
</FunctionImport>
Esto indica al modelo que el procedimiento almacenado devolverá dos colecciones, una de las entradas del blog y
una de las entradas post.
Busque el elemento de asignación de función:


<edmx:Mappings>
...
<FunctionImportMapping FunctionImportName="GetAllBlogsAndPosts"
FunctionName="BlogModel.Store.GetAllBlogsAndPosts">
<ResultMapping>
<ComplexTypeMapping TypeName="BlogModel.GetAllBlogsAndPosts_Result">
<ScalarProperty Name="BlogId" ColumnName="BlogId" />
<ScalarProperty Name="Description" ColumnName="Description" />
</ComplexTypeMapping>
</ResultMapping>
...
</edmx:Mappings>
Reemplace la asignación de resultados por una para cada entidad que se va a devolver, como la siguiente:
<ResultMapping>
<EntityTypeMapping TypeName ="BlogModel.Blog">
<ScalarProperty Name="Description" ColumnName="Description" />
</ResultMapping>
<ResultMapping>
<EntityTypeMapping TypeName="BlogModel.Post">
<ScalarProperty Name="PostId" ColumnName="PostId"/>
<ScalarProperty Name="Text" ColumnName="Text" />
</ResultMapping>
También es posible asignar los conjuntos de resultados a tipos complejos, como el que se crea de forma
predeterminada. Para ello, cree un nuevo tipo complejo, en lugar de quitarlos, y use los tipos complejos en todos
los lugares en los que haya usado los nombres de entidad en los ejemplos anteriores.
Una vez que se hayan cambiado estas asignaciones, puede guardar el modelo y ejecutar el código siguiente para
usar el procedimiento almacenado:
using (var db = new BlogEntities())

{
var results = db.GetAllBlogsAndPosts();
foreach (var result in results)

{
Console.WriteLine("Blog: " + result.Name);
}
var posts = results.GetNextResult<Post>();
foreach (var result in posts)

{
Console.WriteLine("Post: " + result.Title);
}
Console.ReadLine();
}
NOTE
Si edita manualmente el archivo edmx para el modelo, se sobrescribirá si alguna vez vuelve a generar el modelo desde la base
de datos.
Resumen
Aquí hemos mostrado dos métodos diferentes para tener acceso a varios conjuntos de resultados mediante Entity
Framework. Ambos son igualmente válidos en función de su situación y preferencias, y debe elegir el que mejor se
adapte a sus circunstancias. Se prevé que la compatibilidad con varios conjuntos de resultados se mejorará en
versiones futuras de Entity Framework y que ya no será necesario realizar los pasos descritos en este documento.
Funciones con valores de tabla (TVF)
NOTE
En el tutorial de vídeo y paso a paso se muestra cómo asignar funciones con valores de tabla (TVF) mediante el
Entity Framework Designer. También se muestra cómo llamar a una TVF desde una consulta LINQ.
TVF actualmente solo se admiten en el flujo de trabajo Database First.
La compatibilidad con TVF se presentó en Entity Framework versión 5. Tenga en cuenta que para usar las nuevas
características, como las funciones con valores de tabla, las enumeraciones y los tipos espaciales, debe tener como
TVF son muy similares a los procedimientos almacenados con una diferencia clave: el resultado de una TVF es
ajustable. Esto significa que los resultados de una TVF se pueden usar en una consulta LINQ mientras que los
resultados de un procedimiento almacenado no pueden.

Wmv | MP4 | WMV (zip)
Requisitos previos
Instale la base de datos School.
Tener una versión reciente de Visual Studio
1. Abra Visual Studio.
4. Escriba TVF como el nombre del proyecto y haga clic en Aceptar .
Agregar una función TVF a la base de datos

Seleccione vista> explorador de objetos de SQL Ser ver
Si LocalDB no está en la lista de servidores: haga clic con el botón derecho en SQL Ser ver y seleccione
Agregar SQL Ser ver usar la autenticación de Windows predeterminada para conectarse al servidor de
LocalDB.
Expandir el nodo LocalDB
En el nodo bases de datos, haga clic con el botón secundario en el nodo de base de datos School y
seleccione nueva consulta.
En el editor de T-SQL, pegue la siguiente definición de TVF
CREATE FUNCTION [dbo].[GetStudentGradesForCourse]
(@CourseID INT)
RETURNS TABLE
RETURN
SELECT [EnrollmentID],
[CourseID],
[StudentID],
[Grade]
FROM [dbo].[StudentGrade]
WHERE CourseID = @CourseID
Haga clic con el botón secundario del mouse en el editor de T-SQL y seleccione Ejecutar .
La función GetStudentGradesForCourse se agrega a la base de datos School
1. Haga clic con el botón secundario en el nombre del proyecto en Explorador de soluciones, seleccione
panel plantillas .
3. Escriba TVFModel. edmx como nombre de archivo y, a continuación, haga clic en Agregar .
4. En el cuadro de diálogo elegir contenido del modelo, seleccione generar desde la base de datos y, a
5. Haga clic en nueva conexión entrar (LocalDB)\mssqllocaldb en el cuadro de texto nombre de servidor,
escriba School para el nombre de la base de datos, haga clic en Aceptar .
6. En el cuadro de diálogo elija los objetos de base de datos, en el nodo tablas , seleccione las
tablas Person , StudentGrade y Course
7. Seleccione la función GetStudentGradesForCourse que se encuentra en los procedimientos
almacenados y las funciones tenga en cuenta que, a partir de Visual Studio 2012, Entity Designer le permite
importar por lotes los procedimientos almacenados y las funciones.
8. Haga clic en Finalizar
9. Se muestra el diseñador de entidades, que proporciona una superficie de diseño para editar el modelo. Todos
los objetos que seleccionó en el cuadro de diálogo Elija los objetos de base de datos se agregan al modelo.
10. De forma predeterminada, la forma de resultado de cada procedimiento almacenado importado o función se
convertirá automáticamente en un nuevo tipo complejo en el modelo de entidad. Pero queremos asignar los
resultados de la función GetStudentGradesForCourse a la entidad StudentGrade: haga clic con el botón derecho
en la superficie de diseño y seleccione Explorador de modelos en el explorador de modelos,
seleccione impor taciones de función y, a continuación, haga doble clic en la
función GetStudentGradesForCourse en el cuadro de diálogo Editar importación de función,
seleccione entidades y elija StudentGrade

Abra el archivo donde se define el método Main. Agregue el código siguiente a la función main.
En el código siguiente se muestra cómo crear una consulta que utiliza una función con valores de tabla. La
consulta proyecta los resultados en un tipo anónimo que contiene el título del curso relacionado y los estudiantes
relacionados con un grado mayor o igual que 3,5.

{
var CourseID = 4022;
var Grade = 3.5M;
// Return all the best students in the Microeconomics class.

var students = from s in context.GetStudentGradesForCourse(CourseID)
where s.Grade >= Grade
select new
{
s.Person,
s.Course.Title
};
foreach (var result in students)

{
Console.WriteLine(
"Couse: {0}, Student: {1} {2}",
result.Title,
result.Person.FirstName,
result.Person.LastName);
}
}
Couse: Microeconomics, Student: Arturo Anand

Couse: Microeconomics, Student: Carson Bryant
Resumen
En este tutorial, hemos visto cómo asignar funciones con valores de tabla (TVF) mediante el Entity Framework
Designer. También se muestra cómo llamar a una función TVF desde una consulta LINQ.
Métodos abreviados de teclado Entity Framework
Designer
Esta página proporciona una lista de shorcuts de teclado disponibles en las distintas pantallas de la Entity
Framework Tools para Visual Studio.
Asistente para Entity Data Model de ADO.NET

Paso 1: elegir el contenido del modelo
M ÉTO DO A B REVIA DO A C C IÓ N N OTA S
Alt + n Pasar a la siguiente pantalla No está disponible para todas las

selecciones del contenido del modelo.
Alt + f Finalice el asistente. No está disponible para todas las

selecciones del contenido del modelo.
Alt + w Cambiar el foco a "¿Qué debe contener

el modelo?" Corregir.
Paso dos: elegir la conexión

Alt + n Pasar a la siguiente pantalla
ALT + p Pasar a la pantalla anterior
Alt + w Cambiar el foco a "¿Qué debe contener

el modelo?" Corregir.
Alt + c Abra la ventana "propiedades de Permite la definición de una nueva

conexión". conexión de base de datos.
Alt + e Excluir datos confidenciales de la cadena

de conexión
ALT + i Incluir datos confidenciales en la cadena

de conexión
Alt + s Activar o desactivar la opción "Guardar

configuración de conexión en App.
config"
Paso tres: elegir la versión

Alt + n Pasar a la siguiente pantalla
Alt + w Cambiar el foco a la selección de la Permite especificar una versión diferente

versión de Entity Framework de Entity Framework para su uso en el
proyecto.
Paso cuatro: elegir los objetos y la configuración de la base de datos

Alt + f Finalice el asistente.
Alt + w Cambiar el foco al panel de selección de Permite especificar los objetos de base
objetos de base de datos de datos a los que se va a aplicar
ingeniería inversa.
Alt + s Alternar la opción "pluralización o

singularización de los nombres de
objeto generados"
Alt + k Alternar la opción "incluir columnas de No está disponible para todas las
clave externa en el modelo" selecciones del contenido del modelo.
ALT + i Alternar la opción "importar funciones y No está disponible para todas las
procedimientos almacenados selecciones del contenido del modelo.
seleccionados en el modelo de entidad"
Alt + m Cambia el foco al campo de texto No está disponible para todas las
"espacio de nombres del modelo". selecciones del contenido del modelo.
Espacio Alternar selección en elemento Si el elemento tiene elementos

secundarios, todos los elementos
secundarios también se alternarán
Left Contraer árbol secundario

Right Expandir árbol secundario
Up (Arriba) Navegar al elemento anterior en el árbol
Bajar Navegar al siguiente elemento en el

árbol
Superficie del diseñador de EF
Espacio/entrar Alternar selección Alterna la selección en el objeto que

tiene el foco.
Esc Cancelar selección Cancela la selección actual.
Ctrl + A Seleccionar todo Selecciona todas las formas en la

superficie de diseño.
Flecha arriba Subir Sube la entidad seleccionada un

incremento de la cuadrícula.
Si está en una lista, se desplaza al
subcampo relacionado anterior.
Flecha abajo Bajar Baja una entidad seleccionada un

incremento de la cuadrícula.
Si se encuentra en una lista, se desplaza
al siguiente subcampo relacionado.
Flecha izquierda Moverse a la izquierda Mueve la entidad seleccionada a la

izquierda un incremento de la
cuadrícula.
Si está en una lista, se desplaza al
subcampo relacionado anterior.
Flecha derecha Moverse a la derecha Mueve la entidad seleccionada a la

derecha un incremento de la cuadrícula.
Si se encuentra en una lista, se desplaza
al siguiente subcampo relacionado.
Mayús + Flecha izquierda Tamaño de la forma izquierda Reduce el ancho de la entidad

seleccionada en un incremento de la
cuadrícula.
Mayús + Flecha derecha Tamaño de la forma derecha Aumenta el ancho de la entidad

seleccionada en un incremento de la
cuadrícula.
Inicio Primer elemento del mismo nivel Mueve el foco y la selección al primer
objeto en la superficie de diseño en el
mismo nivel del mismo nivel.
Finalizar Último elemento del mismo nivel Mueve el foco y la selección al último
Ctrl + Inicio Primer elemento del mismo nivel (foco) Igual que el primer elemento del mismo
nivel, pero mueve el foco en lugar de
mover el foco y la selección.
Ctrl + fin Último elemento del mismo nivel (foco) Igual que el último elemento del mismo
nivel, pero mueve el foco en lugar de
mover el foco y la selección.
Tabulación Siguiente elemento del mismo nivel Mueve el foco y la selección al siguiente
Mayús+Tab Anterior del mismo nivel Mueve el foco y la selección al objeto

anterior en la superficie de diseño en el
Alt + Ctrl + Tab Siguiente elemento del mismo nivel Igual que el siguiente elemento del
(foco) mismo nivel, pero mueve el foco en
lugar de mover el foco y la selección.
Alt + Ctrl + Mayús + Tab Anterior del mismo nivel (enfoque) Igual que el elemento anterior del
mismo nivel, pero mueve el foco en
lugar de mover el foco y la selección.
< Ascende Se desplaza al siguiente objeto en la

superficie de diseño un nivel superior de
la jerarquía. Si no hay formas por
encima de esta forma en la jerarquía (es
decir, el objeto se coloca directamente
en la superficie de diseño), se selecciona
el diagrama.
> Descendientes Se desplaza al siguiente objeto

contenido en la superficie de diseño un
nivel por debajo de este en la jerarquía.
Si no hay ningún objeto contenido, se
trata de una operación no operativa.
Ctrl + < Ascend (Focus) Igual que el comando Ascend, pero

mueve el foco sin selección.
Ctrl + > Descendente (foco) Igual que el comando descendente,

pero mueve el foco sin selección.
Mayús + fin Seguir a conectado Desde una entidad, se mueve a una

entidad a la que está conectada esta
entidad.
Supr Eliminar Elimine un objeto o un conector del

diagrama.
Complemento Insertar Agrega una nueva propiedad a una

entidad cuando se selecciona el
encabezado de compartimiento
"propiedades escalares" o una
propiedad en sí.
AvPág Desplazar diagrama hacia arriba Desplaza la superficie de diseño hacia

arriba, en incrementos iguales al 75%
del alto de la superficie de diseño
actualmente visible.
Av Pág Desplazar diagrama hacia abajo Desplaza la superficie de diseño hacia

abajo.
Mayús + Av Pág Desplazar diagrama a la derecha Desplaza la superficie de diseño a la

derecha.
Mayús + re pág Desplazar diagrama a la izquierda Desplaza la superficie de diseño a la

izquierda.
F2 Entrar en el modo de edición Método abreviado de teclado estándar

para entrar en el modo de edición de un
control de texto.
Mayús + F10 Mostrar menú contextual Método abreviado de teclado estándar

para mostrar el menú contextual de un
elemento seleccionado.
Control + Mayús + clic con el Zoom semántico Acerca el área de la vista de diagrama
botón primario del mouse debajo del puntero del mouse.
Control + Mayús + MouseWheel
hacia delante
Control + Mayús + clic con el Alejar semántica Aleja el área de la vista de diagrama
botón secundario del mouse debajo del puntero del mouse. Vuelve a
Control + Mayús + MouseWheel centrar el diagrama cuando aleja el
hacia atrás centro del diagrama actual.
Control + Mayús + ' + ' Acercar Acerca el centro de la vista de diagrama.

Control + MouseWheel For ward
Control + Mayús + '-' Alejar Aleja el área en la que se hace clic en la

Control + MouseWheel hacia atrás vista de diagrama. Vuelve a centrar el
diagrama cuando aleja el centro del
diagrama actual.
Control + Mayús + dibujar un Área de zoom Acerca centrada en el área que ha

rectángulo con el botón primario seleccionado. Cuando mantenga
del mouse hacia abajo presionadas las teclas Control + Mayús,
verá que el cursor cambia a una lupa, lo
que le permite definir el área de zoom.
Tecla del menú contextual + m ' Abrir la ventana detalles de la Abre la ventana detalles de la
asignación asignación para editar las asignaciones
de la entidad seleccionada
Detalles de la asignación (ventana)
Tabulación Cambiar contexto Cambia entre el área de la ventana

principal y la barra de herramientas de
la izquierda.
Teclas de dirección Navegación Subir y bajar filas, o de derecha a

izquierda entre las columnas del área de
la ventana principal. Desplácese entre
los botones de la barra de herramientas
de la izquierda.
Entrar Seleccionar Selecciona un botón de la barra de

Espacio herramientas de la izquierda.
Alt + flecha abajo Abrir lista Desplegar una lista si se selecciona una
celda que tenga una lista desplegable.
Entrar Seleccionar lista Selecciona un elemento de una lista

desplegable.
Esc Cerrar lista Cierra una lista desplegable.
Navegación de Visual Studio

Entity Framework también proporciona una serie de acciones que pueden tener los métodos abreviados de teclado
personalizados asignados (no se asignan accesos directos de forma predeterminada). Para crear estos métodos
abreviados personalizados, haga clic en el menú herramientas y, a continuación, en opciones. En entorno, elija
teclado. Desplácese hacia abajo en la lista en el centro hasta que pueda seleccionar el comando que desee, escriba
el acceso directo en el cuadro de texto "presionar teclas de método abreviado" y haga clic en asignar. Los métodos
abreviados posibles son los siguientes:
M ÉTO DO A B REVIA DO
OtherContextMenus. MicrosoftDataEntityDesignContext. Add. ComplexProper ty. ComplexTypes
OtherContextMenus.MicrosoftDataEntityDesignContext.AddCodeGenerationItem
OtherContextMenus.MicrosoftDataEntityDesignContext.AddFunctionImpor t
OtherContextMenus. MicrosoftDataEntityDesignContext. AddNew. AddEnumType
OtherContextMenus. MicrosoftDataEntityDesignContext. AddNew. Association
OtherContextMenus. MicrosoftDataEntityDesignContext. AddNew. ComplexProper ty
OtherContextMenus. MicrosoftDataEntityDesignContext. AddNew. ComplexType
OtherContextMenus. MicrosoftDataEntityDesignContext. AddNew. Entity
OtherContextMenus. MicrosoftDataEntityDesignContext. AddNew. FunctionImpor t
OtherContextMenus. MicrosoftDataEntityDesignContext. AddNew. inheritance
OtherContextMenus. MicrosoftDataEntityDesignContext. AddNew. NavigationProper ty
OtherContextMenus. MicrosoftDataEntityDesignContext. AddNew. ScalarProper ty

OtherContextMenus.MicrosoftDataEntityDesignContext.AddNewDiagram
OtherContextMenus.MicrosoftDataEntityDesignContext.AddtoDiagram
OtherContextMenus. MicrosoftDataEntityDesignContext. Close
OtherContextMenus. MicrosoftDataEntityDesignContext. Collapse
OtherContextMenus.MicrosoftDataEntityDesignContext.Conver ttoEnum
OtherContextMenus. MicrosoftDataEntityDesignContext. diagram. CollapseAll
OtherContextMenus. MicrosoftDataEntityDesignContext. diagram. ExpandAll
OtherContextMenus. MicrosoftDataEntityDesignContext. diagram. Expor tasImage
OtherContextMenus. MicrosoftDataEntityDesignContext. diagram. LayoutDiagram
OtherContextMenus. MicrosoftDataEntityDesignContext. Edit
OtherContextMenus. MicrosoftDataEntityDesignContext. EntityKey
OtherContextMenus. MicrosoftDataEntityDesignContext. Expand
OtherContextMenus. MicrosoftDataEntityDesignContext. FunctionImpor tMapping
OtherContextMenus.MicrosoftDataEntityDesignContext.GenerateDatabasefromModel
OtherContextMenus.MicrosoftDataEntityDesignContext.GoToDefinition
OtherContextMenus. MicrosoftDataEntityDesignContext. Grid. ShowGrid
OtherContextMenus. MicrosoftDataEntityDesignContext. Grid. SnaptoGrid
OtherContextMenus.MicrosoftDataEntityDesignContext.IncludeRelated
OtherContextMenus.MicrosoftDataEntityDesignContext.MappingDetails
OtherContextMenus. MicrosoftDataEntityDesignContext. ModelBrowser
OtherContextMenus.MicrosoftDataEntityDesignContext.MoveDiagramstoSeparateFile
OtherContextMenus. MicrosoftDataEntityDesignContext. MoveProper ties. Down
OtherContextMenus.MicrosoftDataEntityDesignContext.MoveProper ties.Down5
OtherContextMenus.MicrosoftDataEntityDesignContext.MoveProper ties.ToBottom
OtherContextMenus.MicrosoftDataEntityDesignContext.MoveProper ties.ToTop
OtherContextMenus. MicrosoftDataEntityDesignContext. MoveProper ties. up
OtherContextMenus.MicrosoftDataEntityDesignContext.MoveProper ties.Up5
OtherContextMenus.MicrosoftDataEntityDesignContext.MovetonewDiagram
OtherContextMenus. MicrosoftDataEntityDesignContext. Open
OtherContextMenus. MicrosoftDataEntityDesignContext. refactorizar. MovetoNewComplexType
OtherContextMenus. MicrosoftDataEntityDesignContext. refactorizar. Rename
OtherContextMenus.MicrosoftDataEntityDesignContext.RemovefromDiagram
OtherContextMenus. MicrosoftDataEntityDesignContext. Rename
OtherContextMenus. MicrosoftDataEntityDesignContext. ScalarProper tyFormat. DisplayName
OtherContextMenus.MicrosoftDataEntityDesignContext.ScalarProper tyFormat.DisplayNameandType
OtherContextMenus. MicrosoftDataEntityDesignContext. Select. BaseType
OtherContextMenus. MicrosoftDataEntityDesignContext. Select. Entity
OtherContextMenus. MicrosoftDataEntityDesignContext. Select. Proper ty
OtherContextMenus. MicrosoftDataEntityDesignContext. Select. SubType
OtherContextMenus. MicrosoftDataEntityDesignContext. SelectAll
OtherContextMenus.MicrosoftDataEntityDesignContext.SelectAssociation
OtherContextMenus.MicrosoftDataEntityDesignContext.ShowinDiagram
OtherContextMenus.MicrosoftDataEntityDesignContext.ShowinModelBrowser
OtherContextMenus.MicrosoftDataEntityDesignContext.StoredProcedureMapping
OtherContextMenus. MicrosoftDataEntityDesignContext. TableMapping
OtherContextMenus.MicrosoftDataEntityDesignContext.UpdateModelfromDatabase
OtherContextMenus. MicrosoftDataEntityDesignContext. Validate
OtherContextMenus. MicrosoftDataEntityDesignContext. zoom. 10

OtherContextMenus. MicrosoftDataEntityDesignContext. zoom. Custom
OtherContextMenus. MicrosoftDataEntityDesignContext. zoom. zoom
OtherContextMenus. MicrosoftDataEntityDesignContext. zoom. ZoomOut
OtherContextMenus. MicrosoftDataEntityDesignContext. zoom. ZoomtoFit
Ver. EntityDataModelBrowser
Ver. EntityDataModelMappingDetails
Consulta y búsqueda de entidades
En este tema se tratan las distintas formas de consultar datos mediante Entity Framework, incluidos LINQ y el
método Find. Las técnicas que se muestran en este tema se aplican igualmente a los modelos creados con Code
First y EF Designer.
Búsqueda de entidades mediante una consulta

DbSet e IDbSet implementan IQueryable, por lo que pueden usarse como punto de partida para escribir una
consulta LINQ en la base de datos. Este no es el lugar adecuado para una explicación detallada sobre LINQ, pero
aquí tiene un par de ejemplos sencillos:

{
// Query for all blogs with names starting with B
var blogs = from b in context.Blogs
where b.Name.StartsWith("B")
select b;
// Query for the Blog named ADO.NET Blog

.Where(b => b.Name == "ADO.NET Blog")
.FirstOrDefault();
}
Tenga en cuenta que DbSet e IDbSet siempre crean las consultas en la base de datos, lo que siempre conlleva un
viaje de ida y vuelta a la base de datos, aun cuando las entidades devueltas ya existan en el contexto. Una consulta
se ejecuta en la base de datos cuando:
Se enumera mediante una instrucción foreach (C#) o For Each (Visual Basic).
Se enumera mediante una operación de recopilación como ToArray, ToDictionary o ToList.
Los operadores LINQ, como First o Any, se especifican en la parte más externa de la consulta.
Se llama a los métodos siguientes: el método de extensión Load en DbSet, DbEntityEntry.Reload y
Database.ExecuteSqlCommand.
Cuando se devuelven los resultados de la base de datos, los objetos que no existen en el contexto se adjuntan a él.
Si un objeto ya está en el contexto, se devuelve el objeto existente (los valores actual y original de las propiedades
del objeto en la entrada no se sobrescriben con valores de la base de datos).
Cuando se realiza una consulta, las entidades que se han agregado al contexto pero aún no se han guardado en la
base de datos no se devuelven como parte del conjunto de resultados. Para obtener los datos que se encuentran en
el contexto, vea Datos locales.
Si una consulta no devuelve filas de la base de datos, el resultado será una colección vacía, en lugar de null .
Búsqueda de entidades mediante claves principales

El método Find de DbSet usa el valor de clave principal para intentar buscar una entidad cuyo seguimiento realiza
el contexto. Si la entidad no se encuentra en el contexto, se envía una consulta a la base de datos para buscar la
entidad allí. Si la entidad no se encuentra en el contexto ni en la base de datos, se devuelve null.
Find se diferencia del uso de una consulta en dos aspectos importantes:
Solo se realiza un viaje de ida y vuelta a la base de datos si la entidad con la clave especificada no se encuentra
en el contexto.
Find devuelve entidades que están en estado Added. Es decir, Find devuelve entidades que se han agregado al
contexto pero que aún no se han guardado en la base de datos.
Búsqueda de una entidad por clave principal
En el código siguiente se muestran algunos usos de Find:

{
// Will hit the database
// Will return the same instance without hitting the database

var blogAgain = context.Blogs.Find(3);
context.Blogs.Add(new Blog { Id = -1 });
// Will find the new blog even though it does not exist in the database
var newBlog = context.Blogs.Find(-1);
// Will find a User which has a string primary key

var user = context.Users.Find("johndoe1987");
}
Búsqueda de una entidad por clave principal compuesta

Entity Framework permite que las entidades tengan claves compuestas, que son claves que se componen de más
de una propiedad. Por ejemplo, podría tener una entidad BlogSettings que representara la configuración de un
usuario para un blog determinado. Dado que un usuario solo tendría una entidad BlogSettings para cada blog,
podría optar por convertir la clave principal de BlogSettings en una combinación de BlogId y Username. El código
siguiente intenta encontrar la entidad BlogSettings con BlogId = 3 y Username = "johndoe1987":

{
var settings = context.BlogSettings.Find(3, "johndoe1987");
}
Observe que con las claves compuestas hay que usar ColumnAttribute o la API fluida para especificar un orden de
las propiedades de la clave compuesta. La llamada a Find debe usar este orden al especificar los valores que
forman la clave.
El método de carga
Hay varios escenarios en los que puede que desee cargar entidades de la base de datos en el contexto sin hacer
nada inmediatamente con esas entidades. Un buen ejemplo es la carga de entidades para el enlace de datos como
se describe en datos locales. Una forma habitual de hacerlo es escribir una consulta LINQ y, a continuación, llamar
a ToList en ella, solo para descartar inmediatamente la lista creada. El método de extensión de carga funciona igual
que ToList, salvo que evita la creación de la lista por completo.
Las técnicas que se muestran en este tema se aplican igualmente a los modelos creados con Code First y EF
Designer.
A continuación se muestran dos ejemplos del uso de load. La primera se toma de un Windows Forms aplicación de
enlace de datos donde la carga se utiliza para consultar las entidades antes de enlazarse a la colección local, como
se describe en datos locales:
protected override void OnLoad(EventArgs e)

{
base.OnLoad(e);
_context = new ProductContext();
categoryBindingSource.DataSource = _context.Categories.Local.ToBindingList();
}
En el segundo ejemplo se muestra el uso de LOAD para cargar una colección filtrada de entidades relacionadas,
como se describe en carga de entidades relacionadas:

{
// Load the posts with the 'entity-framework' tag related to a given blog
context.Entry(blog)
.Query()
.Where(p => p.Tags.Contains("entity-framework"))
.Load();
}
Datos locales
La ejecución de una consulta LINQ directamente en una DbSet siempre enviará una consulta a la base de datos,
pero se puede tener acceso a los datos que están actualmente en memoria mediante la propiedad DbSet. local.
También puede acceder a la información adicional EF realiza el seguimiento de las entidades mediante los
métodos DbContext. entry y DbContext. ChangeTracker. entrys. Las técnicas que se muestran en este tema se
aplican igualmente a los modelos creados con Code First y EF Designer.
Usar local para examinar datos locales

La propiedad local de DbSet proporciona acceso sencillo a las entidades del conjunto cuyo seguimiento realiza
actualmente el contexto y que no se han marcado como eliminados. El acceso a la propiedad local nunca hace
que se envíe una consulta a la base de datos. Esto significa que normalmente se utiliza después de que ya se haya
realizado una consulta. El método de extensión de carga se puede usar para ejecutar una consulta de modo que el
contexto realice un seguimiento de los resultados. Por ejemplo:

{
// Load all blogs from the database into the context
context.Blogs.Load();
// Add a new blog to the context

context.Blogs.Add(new Blog { Name = "My New Blog" });
// Mark one of the existing blogs as Deleted

context.Blogs.Remove(context.Blogs.Find(1));
// Loop over the blogs in the context.

Console.WriteLine("In Local: ");
foreach (var blog in context.Blogs.Local)
{
Console.WriteLine(
"Found {0}: {1} with state {2}",
blog.BlogId,
blog.Name,
context.Entry(blog).State);
}
// Perform a query against the database.

Console.WriteLine("\nIn DbSet query: ");
foreach (var blog in context.Blogs)
{
Console.WriteLine(
blog.BlogId,
blog.Name,
context.Entry(blog).State);
}
}
Si teníamos dos blogs en la base de datos: ' ADO.NET blog ' con BlogId de 1 y ' el blog de Visual Studio ' con un
BlogId de 2-podríamos esperar el siguiente resultado:
In Local:
Found 0: My New Blog with state Added
Found 2: The Visual Studio Blog with state Unchanged
In DbSet query:
Found 1: ADO.NET Blog with state Deleted
Found 2: The Visual Studio Blog with state Unchanged
Esto ilustra tres puntos:

El nuevo blog ' mi nuevo blog ' está incluido en la colección local aunque aún no se ha guardado en la base de
datos. Este blog tiene una clave principal de cero porque la base de datos aún no ha generado una clave real
para la entidad.
El "blog de ADO.NET" no se incluye en la colección local aunque el contexto siga realizando el seguimiento.
Esto se debe a que se ha quitado de DbSet y, por tanto, se ha marcado como eliminado.
Cuando se usa DbSet para realizar una consulta, el blog marcado para su eliminación (ADO.NET blog) se
incluye en los resultados y el nuevo blog (mi nuevo blog) que todavía no se ha guardado en la base de datos
no se incluye en los resultados. Esto se debe a que DbSet está realizando una consulta en la base de datos y
los resultados devueltos siempre reflejan lo que hay en la base de datos.
Usar local para agregar y quitar entidades del contexto

La propiedad local en DbSet devuelve un ObservableCollection con eventos enlazados de modo que permanece
sincronizado con el contenido del contexto. Esto significa que se pueden agregar o quitar entidades de la
colección local o de DbSet. También significa que las consultas que incorporan nuevas entidades al contexto
darán lugar a que la colección local se actualice con esas entidades. Por ejemplo:
{
// Load some posts from the database into the context
context.Posts.Where(p => p.Tags.Contains("entity-framework")).Load();
// Get the local collection and make some changes to it

var localPosts = context.Posts.Local;
localPosts.Add(new Post { Name = "What's New in EF" });
localPosts.Remove(context.Posts.Find(1));
// Loop over the posts in the context.

Console.WriteLine("In Local after entity-framework query: ");
foreach (var post in context.Posts.Local)
{
Console.WriteLine(
post.Id,
post.Title,
context.Entry(post).State);
}
var post1 = context.Posts.Find(1);

Console.WriteLine(
"State of post 1: {0} is {1}",
post1.Name,
context.Entry(post1).State);
// Query some more posts from the database

context.Posts.Where(p => p.Tags.Contains("asp.net").Load();
// Loop over the posts in the context again.

Console.WriteLine("\nIn Local after asp.net query: ");
foreach (var post in context.Posts.Local)
{
Console.WriteLine(
post.Id,
post.Title,
context.Entry(post).State);
}
}
Suponiendo que tenemos algunas entradas etiquetadas con "Entity-Framework" y "asp.net", la salida puede tener
un aspecto similar al siguiente:
In Local after entity-framework query:

Found 3: EF Designer Basics with state Unchanged
Found 5: EF Code First Basics with state Unchanged
Found 0: What's New in EF with state Added
State of post 1: EF Beginners Guide is Deleted
In Local after asp.net query:

Found 3: EF Designer Basics with state Unchanged
Found 5: EF Code First Basics with state Unchanged
Found 0: What's New in EF with state Added
Found 4: ASP.NET Beginners Guide with state Unchanged
Esto ilustra tres puntos:

La nueva publicación ' What's New in EF ' que se agregó a la colección local se hace seguimiento por el
contexto en el estado Added. Por lo tanto, se insertará en la base de datos cuando se llame a SaveChanges.
La publicación que se quitó de la colección local (guía para principiantes de EF) ahora está marcada como
eliminada en el contexto. Por lo tanto, se eliminará de la base de datos cuando se llame a SaveChanges.
La publicación adicional (guía para principiantes de ASP.NET) cargada en el contexto con la segunda consulta
se agrega automáticamente a la colección local.
Una cuestión final que hay que tener en cuenta sobre local es que, dado que es un rendimiento de
ObservableCollection no es excelente para un gran número de entidades. Por lo tanto, si está tratando con miles
de entidades en el contexto, puede que no sea aconsejable usar local.
Usar local para el enlace de datos de WPF

La propiedad local en DbSet se puede usar directamente para el enlace de datos en una aplicación WPF porque es
una instancia de ObservableCollection. Tal como se describe en las secciones anteriores, esto significa que
permanecerá sincronizada automáticamente con el contenido del contexto y el contenido del contexto
permanecerá sincronizado automáticamente con él. Tenga en cuenta que debe rellenar previamente la colección
local con datos para que sea todo lo que se va a enlazar a, ya que local nunca genera una consulta de base de
datos.
No es un lugar adecuado para un ejemplo de enlace de datos de WPF completo, pero los elementos clave son:
Configuración de un origen de enlace
Enlazarlo a la propiedad local del conjunto
Rellene el local mediante una consulta a la base de datos.
Enlace de WPF a propiedades de navegación

Si está realizando el enlace de datos principal/detalle, puede enlazar la vista de detalle a una propiedad de
navegación de una de las entidades. Una manera fácil de realizar este trabajo es usar ObservableCollection para
la propiedad de navegación. Por ejemplo:
public class Blog

{
private readonly ObservableCollection<Post> _posts =
new ObservableCollection<Post>();

public virtual ObservableCollection<Post> Posts

{
get { return _posts; }
}
}
Usar local para limpiar entidades en SaveChanges

En la mayoría de los casos, las entidades quitadas de una propiedad de navegación no se marcarán
automáticamente como eliminadas en el contexto. Por ejemplo, si quita un objeto post de la colección blog. posts,
esa publicación no se eliminará automáticamente cuando se llame a SaveChanges. Si necesita que se elimine,
puede que necesite encontrar estas entidades pendientes y marcarlas como eliminadas antes de llamar a
SaveChanges o como parte de un SaveChanges invalidado. Por ejemplo:
public override int SaveChanges()
{
foreach (var post in this.Posts.Local.ToList())
{
if (post.Blog == null)
{
this.Posts.Remove(post);
}
}
return base.SaveChanges();
}
El código anterior usa la colección local para buscar todas las publicaciones y marca cualquier que no tenga una
referencia de blog como eliminada. La llamada a ToList es necesaria porque, de lo contrario, se modificará la
colección mediante la llamada a Remove mientras se está enumerando. En la mayoría de las demás situaciones,
puede realizar consultas directamente en la propiedad local sin usar ToList primero.
Usar local y ToBindingList para el enlace de datos Windows Forms

Windows Forms no admite el enlace de datos de plena fidelidad mediante ObservableCollection directamente.
Sin embargo, todavía puede usar la propiedad local DbSet para el enlace de datos con el fin de obtener todas las
ventajas descritas en las secciones anteriores. Esto se logra mediante el método de extensión ToBindingList, que
crea una implementación de IBindingList respaldada por el ObservableCollection local.
No es un lugar adecuado para un ejemplo de enlace de datos completo Windows Forms pero los elementos clave
son:
Configuración de un origen de enlace de objeto
Enlácelo a la propiedad local del conjunto mediante local. ToBindingList ()
Rellenar local mediante una consulta a la base de datos
Obtención de información detallada sobre las entidades sometidas a

seguimiento
Muchos de los ejemplos de esta serie usan el método entry para devolver una instancia de DbEntityEntry para
una entidad. Este objeto de entrada actúa como punto de partida para recopilar información sobre la entidad,
como su estado actual, así como para realizar operaciones en la entidad, como cargar explícitamente una entidad
relacionada.
Los métodos de entrada devuelven objetos DbEntityEntry para muchas o todas las entidades de las que el
contexto realiza un seguimiento. Esto le permite recopilar información o realizar operaciones en muchas
entidades en lugar de en una sola entrada. Por ejemplo:
{
// Load some entities into the context
context.Blogs.Load();
context.Authors.Load();
context.Readers.Load();
// Make some changes

context.Blogs.Find(1).Title = "The New ADO.NET Blog";
context.Blogs.Remove(context.Blogs.Find(2));
context.Authors.Add(new Author { Name = "Jane Doe" });
context.Readers.Find(1).Username = "johndoe1987";
// Look at the state of all entities in the context

Console.WriteLine("All tracked entities: ");
foreach (var entry in context.ChangeTracker.Entries())
{
Console.WriteLine(
"Found entity of type {0} with state {1}",
ObjectContext.GetObjectType(entry.Entity.GetType()).Name,
entry.State);
}
// Find modified entities of any type

Console.WriteLine("\nAll modified entities: ");
foreach (var entry in context.ChangeTracker.Entries()
.Where(e => e.State == EntityState.Modified))
{
Console.WriteLine(
"Found entity of type {0} with state {1}",
ObjectContext.GetObjectType(entry.Entity.GetType()).Name,
entry.State);
}
// Get some information about just the tracked blogs

Console.WriteLine("\nTracked blogs: ");
foreach (var entry in context.ChangeTracker.Entries<Blog>())
{
Console.WriteLine(
"Found Blog {0}: {1} with original Name {2}",
entry.Entity.BlogId,
entry.Entity.Name,
entry.Property(p => p.Name).OriginalValue);
}
// Find all people (author or reader)

Console.WriteLine("\nPeople: ");
foreach (var entry in context.ChangeTracker.Entries<IPerson>())
{
Console.WriteLine("Found Person {0}", entry.Entity.Name);
}
}
Observamos que estamos introduciendo una clase Author y Reader en el ejemplo. ambas clases implementan la
interfaz IPerson.
public class Author : IPerson
{
public int AuthorId { get; set; }
public string Biography { get; set; }
}
public class Reader : IPerson

{
public int ReaderId { get; set; }
}
public interface IPerson

{
string Name { get; }
}
Supongamos que tenemos los siguientes datos en la base de datos:

Blog con BlogId = 1 y name = ' ADO.NET blog '
Blog con BlogId = 2 y name = "blog de Visual Studio"
Blog con BlogId = 3 y name = ' .NET Framework blog '
Autor con AuthorId = 1 y name = ' Joe Bloggs '
Lector con ReaderId = 1 y name = ' John Doe '
La salida de la ejecución del código sería:
All tracked entities:

Found entity of type Blog with state Modified
Found entity of type Blog with state Deleted
Found entity of type Blog with state Unchanged
Found entity of type Author with state Unchanged
Found entity of type Author with state Added
Found entity of type Reader with state Modified
All modified entities:

Found entity of type Blog with state Modified
Found entity of type Reader with state Modified
Tracked blogs:
Found Blog 1: The New ADO.NET Blog with original Name ADO.NET Blog
Found Blog 2: The Visual Studio Blog with original Name The Visual Studio Blog
Found Blog 3: .NET Framework Blog with original Name .NET Framework Blog
People:
Found Person John Doe
Found Person Joe Bloggs
Found Person Jane Doe
En estos ejemplos se muestran varios puntos:

Los métodos de entrada devuelven entradas para entidades en todos los Estados, incluido Deleted. Compare
esto con el local, que excluye las entidades eliminadas.
Se devuelven las entradas de todos los tipos de entidad cuando se usa el método de entradas no genéricas.
Cuando se usa el método de entradas genéricas, las entradas solo se devuelven para las entidades que son
instancias del tipo genérico. Se usó anteriormente para obtener entradas de todos los blogs. También se usaba
para obtener entradas para todas las entidades que implementan IPerson. Esto demuestra que el tipo genérico
no tiene que ser un tipo de entidad real.
LINQ to Objects se puede utilizar para filtrar los resultados devueltos. Se usó anteriormente para buscar
entidades de cualquier tipo, siempre y cuando se modifiquen.
Tenga en cuenta que las instancias de DbEntityEntry siempre contienen una entidad que no es NULL. Las entradas
de relación y las entradas de código auxiliar no se representan como instancias de DbEntityEntry, por lo que no es
necesario filtrarlas.
consultas de no seguimiento
En ocasiones, es posible que desee obtener las entidades de una consulta, pero el contexto no puede realizar el
seguimiento de esas entidades. Esto puede dar lugar a un mejor rendimiento cuando se consulta un gran número
de entidades en escenarios de solo lectura. Las técnicas que se muestran en este tema se aplican igualmente a los
modelos creados con Code First y EF Designer.
Un nuevo método de extensión AsNoTracking permite ejecutar cualquier consulta de esta manera. Por ejemplo:

{
// Query for all blogs without tracking them
var blogs1 = context.Blogs.AsNoTracking();
// Query for some blogs without tracking them

var blogs2 = context.Blogs
.Where(b => b.Name.Contains(".NET"))
.AsNoTracking()
.ToList();
}
Entity Framework permite realizar consultas con LINQ con las clases de entidad. Sin embargo, puede haber
ocasiones en las que desee ejecutar consultas utilizando SQL sin formato directamente en la base de datos. Esto
incluye llamar a procedimientos almacenados, que pueden ser útiles para Code First modelos que actualmente no
admiten la asignación a procedimientos almacenados. Las técnicas que se muestran en este tema se aplican
igualmente a los modelos creados con Code First y EF Designer.
Escribir consultas SQL para entidades

El método SqlQuery en DbSet permite escribir una consulta SQL sin formato que devolverá las instancias de la
entidad. El contexto realizará un seguimiento de los objetos devueltos tal como lo haría si se devolvieran mediante
una consulta LINQ. Por ejemplo:

{
var blogs = context.Blogs.SqlQuery("SELECT * FROM dbo.Blogs").ToList();
}
Tenga en cuenta que, al igual que para las consultas LINQ, la consulta no se ejecuta hasta que se enumeran los
resultados; en el ejemplo anterior, esto se realiza con la llamada a ToList.
Se debe tener cuidado cuando las consultas SQL sin procesar se escriben por dos motivos. En primer lugar, se debe
escribir la consulta para asegurarse de que solo devuelve entidades que son realmente del tipo solicitado. Por
ejemplo, al usar características como la herencia, es fácil escribir una consulta que creará entidades que son del
tipo CLR incorrecto.
En segundo lugar, algunos tipos de consultas SQL sin procesar exponen posibles riesgos de seguridad,
especialmente en torno a ataques por inyección de SQL. Asegúrese de usar los parámetros de la consulta de la
manera correcta para protegerse frente a estos ataques.
Cargar entidades desde procedimientos almacenados
Puede usar DbSet. SqlQuery para cargar entidades de los resultados de un procedimiento almacenado. Por
ejemplo, el código siguiente llama a DBO. Procedimiento GetBlogs en la base de datos:

{
var blogs = context.Blogs.SqlQuery("dbo.GetBlogs").ToList();
}
También puede pasar parámetros a un procedimiento almacenado con la sintaxis siguiente:

{
var blogId = 1;
var blogs = context.Blogs.SqlQuery("dbo.GetBlogById @p0", blogId).Single();

}
Escribir consultas SQL para tipos que no son de entidad
Una consulta SQL que devuelve instancias de cualquier tipo, incluidos los tipos primitivos, se puede crear con el
método SqlQuery en la clase de base de datos. Por ejemplo:

{
var blogNames = context.Database.SqlQuery<string>(
"SELECT Name FROM dbo.Blogs").ToList();
}
Nunca se realizará el seguimiento de los resultados devueltos de SqlQuery en la base de datos en el contexto,
incluso si los objetos son instancias de un tipo de entidad.
Enviar comandos sin formato a la base de datos

Los comandos que no son de consulta se pueden enviar a la base de datos mediante el método
ExecuteSqlCommand en la base de datos. Por ejemplo:

{
context.Database.ExecuteSqlCommand(
"UPDATE dbo.Blogs SET Name = 'Another Name' WHERE BlogId = 1");
}
Tenga en cuenta que los cambios realizados en los datos de la base de datos mediante ExecuteSqlCommand son
opacos en el contexto hasta que las entidades se cargan o se vuelven a cargar desde la base de datos.
Parámetros de salida
Si se utilizan parámetros de salida, sus valores no estarán disponibles hasta que los resultados se hayan leído por
completo. Esto se debe al comportamiento subyacente de DbDataReader, consulte recuperación de datos mediante
un DataReader para obtener más detalles.
Carga de entidades relacionadas
Entity Framework admite tres maneras de cargar datos relacionados: carga diligente, carga diferida y carga
explícita. Las técnicas que se muestran en este tema se aplican igualmente a los modelos creados con Code First y
EF Designer.
Cargando diligentemente
La carga diligente es el proceso por el cual una consulta para un tipo de entidad también carga las entidades
relacionadas como parte de la consulta. La carga diligente se logra mediante el uso del método include. Por
ejemplo, las consultas siguientes cargarán blogs y todas las entradas relacionadas con cada blog.

{
// Load all blogs and related posts.
.ToList();
// Load one blog and its related posts.

var blog1 = context.Blogs
.FirstOrDefault();
// Load all blogs and related posts

// using a string to specify the relationship.
.Include("Posts")
.ToList();
// Load one blog and its related posts

var blog2 = context.Blogs
.Include("Posts")
.FirstOrDefault();
}
NOTE
Include es un método de extensión en el espacio de nombres System. Data. Entity, por lo que debe asegurarse de que está
usando ese espacio de nombres.
Carga de varios niveles diligentemente

También es posible cargar diligentemente varios niveles de entidades relacionadas. En las consultas siguientes se
muestran ejemplos de cómo hacerlo para las propiedades de navegación de colección y de referencia.
{
// Load all blogs, all related posts, and all related comments.
.Include(b => b.Posts.Select(p => p.Comments))
.ToList();
// Load all users, their related profiles, and related avatar.

var users1 = context.Users
.Include(u => u.Profile.Avatar)
.ToList();
// Load all blogs, all related posts, and all related comments
// using a string to specify the relationships.
.Include("Posts.Comments")
.ToList();
// Load all users, their related profiles, and related avatar

// using a string to specify the relationships.
var users2 = context.Users
.Include("Profile.Avatar")
.ToList();
}
NOTE
Actualmente no es posible filtrar las entidades relacionadas que se cargan. Incluir siempre incluirá todas las entidades
relacionadas.
Carga diferida
La carga diferida es el proceso por el que una entidad o colección de entidades se carga automáticamente desde
la base de datos la primera vez que se tiene acceso a una propiedad que hace referencia a la entidad o entidades.
Al usar tipos de entidad POCO, la carga diferida se consigue creando instancias de tipos de proxy derivados y, a
continuación, reemplazando las propiedades virtuales para agregar el enlace de carga. Por ejemplo, al usar la
clase de entidad de blog que se define a continuación, se cargarán las publicaciones relacionadas la primera vez
que se tenga acceso a la propiedad de navegación posts:
public class Blog

{
public string Tags { get; set; }

}
Desactivación de la carga diferida para la serialización

La carga diferida y la serialización no se combinan bien y, si no tiene cuidado, puede finalizar la consulta de toda la
base de datos, solo porque está habilitada la carga diferida. La mayoría de los serializadores funcionan mediante
el acceso a cada propiedad en una instancia de un tipo. El acceso de propiedad desencadena la carga diferida, por
lo que se serializan más entidades. En esas entidades se tiene acceso a las propiedades de, e incluso se cargan más
entidades. Se recomienda desactivar la carga diferida antes de serializar una entidad. Se muestra cómo hacerlo en
las secciones siguientes.
Desactivar la carga diferida para propiedades de navegación específicas
La carga diferida de la colección de publicaciones se puede desactivar haciendo que la propiedad postes no sea
virtual:
public class Blog

{
public string Tags { get; set; }

}
La carga de la colección de publicaciones se puede seguir usando la carga diligente (consulte la carga rápida
anterior) o el método Load (vea carga explícita a continuación).
Desactivar la carga diferida para todas las entidades
La carga diferida se puede desactivar para todas las entidades en el contexto estableciendo una marca en la
propiedad de configuración. Por ejemplo:

{
{
this.Configuration.LazyLoadingEnabled = false;
}
}
La carga de entidades relacionadas todavía se puede lograr mediante la carga diligente (consulte la carga rápida
anterior) o el método Load (vea carga explícita a continuación).
Cargar explícitamente
Incluso con la carga diferida deshabilitada, todavía es posible cargar de forma diferida las entidades relacionadas,
pero debe realizarse con una llamada explícita. Para ello, use el método Load en la entrada de la entidad
relacionada. Por ejemplo:

{
var post = context.Posts.Find(2);
// Load the blog related to a given post.

context.Entry(post).Reference(p => p.Blog).Load();
// Load the blog related to a given post using a string.

context.Entry(post).Reference("Blog").Load();
// Load the posts related to a given blog.

context.Entry(blog).Collection(p => p.Posts).Load();
// Load the posts related to a given blog

context.Entry(blog).Collection("Posts").Load();
}
NOTE
El método de referencia debe usarse cuando una entidad tiene una propiedad de navegación a otra entidad única. Por otro
lado, el método de colección debe usarse cuando una entidad tiene una propiedad de navegación a una colección de otras
entidades.
Aplicar filtros al cargar explícitamente entidades relacionadas

El método de consulta proporciona acceso a la consulta subyacente que utilizará Entity Framework al cargar las
entidades relacionadas. Después, puede usar LINQ para aplicar filtros a la consulta antes de ejecutarlo con una
llamada a un método de extensión LINQ como ToList, Load, etc. El método de consulta se puede utilizar con
propiedades de navegación de referencia y de colección, pero es muy útil para las colecciones en las que se puede
usar para cargar solo parte de la colección. Por ejemplo:

{
// Load the posts with the 'entity-framework' tag related to a given blog.
context.Entry(blog)
.Query()
.Load();
// Load the posts with the 'entity-framework' tag related to a given blog
context.Entry(blog)
.Collection("Posts")
.Query()
.Load();
}
Cuando se usa el método de consulta, suele ser mejor desactivar la carga diferida para la propiedad de
navegación. Esto se debe a que, de lo contrario, es posible que el mecanismo de carga diferida cargue
automáticamente toda la colección antes o después de que se haya ejecutado la consulta filtrada.
NOTE
Aunque la relación se puede especificar como una cadena en lugar de una expresión lambda, el IQueryable devuelto no es
genérico cuando se usa una cadena y, por lo tanto, el método Cast suele ser necesario antes de que se pueda hacer nada
útil con él.
Usar Query para contar entidades relacionadas sin cargarlas

A veces resulta útil saber el número de entidades relacionadas con otra entidad de la base de datos sin incurrir
realmente en el costo de cargar todas esas entidades. Se puede utilizar el método de consulta con el método
Count de LINQ para hacerlo. Por ejemplo:
{
// Count how many posts the blog has.

var postCount = context.Entry(blog)
.Query()
.Count();
}
Guardado de datos con Entity Framework 6
En esta sección puede encontrar información sobre las capacidades de seguimiento de cambios de EF y lo que
sucede cuando se llama a SaveChanges para almacenar los cambios realizados en los objetos en la base de datos.
Detección automática de cambios
Al usar la mayoría de las entidades POCO, la determinación de cómo ha cambiado una entidad (y, por lo tanto, las
actualizaciones que se deben enviar a la base de datos) se controla mediante el algoritmo de detección de cambios.
Detectar cambios funciona detectando las diferencias entre los valores de propiedad actuales de la entidad y los
valores de propiedad originales que se almacenan en una instantánea cuando se consulta o se adjunta la entidad.
Las técnicas que se muestran en este tema se aplican igualmente a los modelos creados con Code First y EF
Designer.
De forma predeterminada, Entity Framework realiza la detección automática de cambios cuando se llama a los
métodos siguientes:
DbSet.Find
DbSet. local
DbSet. Add
DbSet. AddRange
DbSet. Remove
DbSet. RemoveRange
DbSet. Attach
DbContext.SaveChanges
DbContext. GetValidationErrors
DbContext.Entry
DbChangeTracker. entradas
Deshabilitación de la detección automática de cambios

Si está realizando un seguimiento de muchas entidades en el contexto y llama a uno de estos métodos muchas
veces en un bucle, puede obtener mejoras de rendimiento significativas desactivando la detección de cambios
durante el bucle. Por ejemplo:

{
try
{
// Make many calls in a loop

foreach (var blog in aLotOfBlogs)
{
}
}
finally
{
}
}
No olvide volver a habilitar la detección de cambios después del bucle: hemos usado try/finally para asegurarse de
que siempre se vuelve a habilitar aunque el código del bucle produzca una excepción.
Una alternativa a deshabilitar y volver a habilitar consiste en dejar la detección automática de los cambios
desactivados en todo momento y en el contexto de llamada. ChangeTracker. DetectChanges explícitamente o usar
los proxies de seguimiento de cambios diligentemente. Ambas opciones están avanzadas y pueden introducir
fácilmente errores sutiles en la aplicación, por lo que deben usarse con cuidado.
Si necesita agregar o quitar muchos objetos de un contexto, considere la posibilidad de usar DbSet. AddRange y
DbSet. RemoveRange. Estos métodos detectan automáticamente los cambios solo una vez después de que se
completen las operaciones de agregar o quitar.
Trabajar con Estados de entidad
En este tema se explica cómo agregar y adjuntar entidades a un contexto y cómo Entity Framework procesa estas
durante el SaveChanges. Entity Framework se encarga del seguimiento del estado de las entidades mientras están
conectadas a un contexto, pero en escenarios desconectados o de N niveles, puede permitir que EF sepa en qué
estado deben estar las entidades. Las técnicas que se muestran en este tema se aplican igualmente a los modelos
creados con Code First y EF Designer.
Estados de la entidad y SaveChanges

Una entidad puede estar en uno de cinco Estados, tal y como se define en la enumeración EntityState. Estos
estados son:
Agregado: el contexto está realizando el seguimiento de la entidad, pero aún no existe en la base de datos
Unchanged: el contexto realiza un seguimiento de la entidad y existe en la base de datos, y sus valores de
propiedad no han cambiado con respecto a los valores de la base de datos.
Modificado: el contexto está realizando el seguimiento de la entidad y existe en la base de datos, y se han
modificado algunos o todos sus valores de propiedad.
Eliminado: el contexto realiza un seguimiento de la entidad y existe en la base de datos, pero se ha marcado
para su eliminación de la base de datos la próxima vez que se llame a SaveChanges.
Detached: el contexto no está realizando el seguimiento de la entidad
SaveChanges realiza diferentes acciones para entidades en diferentes Estados:
SaveChanges no toca las entidades sin modificar. Las actualizaciones no se envían a la base de datos para
entidades en el estado sin cambios.
Las entidades agregadas se insertan en la base de datos y, a continuación, se vuelven sin cambios cuando se
devuelve SaveChanges.
Las entidades modificadas se actualizan en la base de datos y, a continuación, se vuelven sin cambios cuando se
devuelve SaveChanges.
Las entidades eliminadas se eliminan de la base de datos y, a continuación, se desasocian del contexto.
En los ejemplos siguientes se muestran las maneras en las que se puede cambiar el estado de una entidad o un
gráfico de entidades.
Agregar una nueva entidad al contexto

Se puede Agregar una nueva entidad al contexto llamando al método Add en DbSet. Esto coloca la entidad en el
estado agregado, lo que significa que se insertará en la base de datos la próxima vez que se llame a SaveChanges.
Por ejemplo:

{
var blog = new Blog { Name = "ADO.NET Blog" };
}
Otra manera de agregar una nueva entidad al contexto es cambiar su estado a agregado. Por ejemplo:
{
context.Entry(blog).State = EntityState.Added;
}
Por último, puede Agregar una nueva entidad al contexto al enlazarla a otra entidad de la que ya se está realizando
el seguimiento. Esto podría ser agregando la nueva entidad a la propiedad de navegación de colección de otra
entidad o estableciendo una propiedad de navegación de referencia de otra entidad para que apunte a la nueva
entidad. Por ejemplo:

{
// Add a new User by setting a reference from a tracked Blog
blog.Owner = new User { UserName = "johndoe1987" };
// Add a new Post by adding to the collection of a tracked Blog

blog.Posts.Add(new Post { Name = "How to Add Entities" });
}
Tenga en cuenta que, para todos estos ejemplos, si la entidad que se va a agregar tiene referencias a otras
entidades de las que todavía no se ha realizado un seguimiento, estas nuevas entidades también se agregarán al
contexto y se insertarán en la base de datos la próxima vez que se llame a SaveChanges.
Asociar una entidad existente al contexto

Si tiene una entidad que sabe que ya existe en la base de datos pero en la que no se realiza el seguimiento
actualmente por el contexto, puede indicar al contexto que realice el seguimiento de la entidad mediante el
método Attach en DbSet. La entidad estará en el estado Unchanged en el contexto. Por ejemplo:
var existingBlog = new Blog { BlogId = 1, Name = "ADO.NET Blog" };

{
context.Blogs.Attach(existingBlog);
// Do some more work...
}
Tenga en cuenta que no se realizarán cambios en la base de datos si se llama a SaveChanges sin realizar ninguna
otra manipulación de la entidad adjunta. Esto se debe a que la entidad está en el estado Unchanged.
Otra manera de asociar una entidad existente al contexto es cambiar su estado a sin cambios. Por ejemplo:

{
context.Entry(existingBlog).State = EntityState.Unchanged;
}
Tenga en cuenta que para ambos ejemplos, si la entidad que se va a asociar tiene referencias a otras entidades de
las que todavía no se ha realizado un seguimiento, estas nuevas entidades también se adjuntarán al contexto en el
estado sin cambios.
Adjuntar una entidad existente pero modificada al contexto

Si tiene una entidad que sabe que ya existe en la base de datos, pero en la que se pueden realizar cambios, puede
indicar al contexto que adjunte la entidad y establezca su estado en modificado. Por ejemplo:

{
context.Entry(existingBlog).State = EntityState.Modified;
}
Al cambiar el estado a modificado, todas las propiedades de la entidad se marcarán como modificadas y todos los
valores de propiedad se enviarán a la base de datos cuando se llame a SaveChanges.
Tenga en cuenta que si la entidad que se va a asociar tiene referencias a otras entidades de las que todavía no se
ha realizado un seguimiento, estas nuevas entidades se adjuntarán al contexto en el estado Unchanged (no se
modificarán automáticamente). Si tiene varias entidades que deben marcarse como modificadas, debe establecer
el estado de cada una de estas entidades de forma individual.
Cambiar el estado de una entidad de la que se ha realizado un

seguimiento
Puede cambiar el estado de una entidad de la que ya se realiza el seguimiento estableciendo la propiedad State en
su entrada. Por ejemplo:

{
context.Blogs.Attach(existingBlog);
context.Entry(existingBlog).State = EntityState.Unchanged;
}
Tenga en cuenta que la llamada a Add o attach para una entidad de la que ya se ha realizado un seguimiento
también se puede usar para cambiar el estado de la entidad. Por ejemplo, al llamar a attach para una entidad que
está actualmente en el estado agregado, se cambiará su estado a sin cambios.
Insertar o actualizar patrón

Un patrón común para algunas aplicaciones es agregar una entidad como nueva (lo que da como resultado una
inserción de base de datos) o adjuntar una entidad como existente y marcarla como modificada (lo que da como
resultado una actualización de la base de datos) en función del valor de la clave principal. Por ejemplo, al utilizar
las claves principales de enteros generados por la base de datos, es habitual tratar una entidad con una clave cero
como nueva y una entidad con una clave distinta de cero como existente. Este patrón se puede lograr
estableciendo el estado de la entidad en función de una comprobación del valor de la clave principal. Por ejemplo:
public void InsertOrUpdate(Blog blog)

{
{
context.Entry(blog).State = blog.BlogId == 0 ?
EntityState.Added :
EntityState.Modified;
}
}
Tenga en cuenta que al cambiar el estado a modificado, todas las propiedades de la entidad se marcarán como
modificadas y todos los valores de propiedad se enviarán a la base de datos cuando se llame a SaveChanges.
Trabajar con valores de propiedad
En la mayoría de los casos, Entity Framework se encargará del seguimiento del estado, los valores originales y los
valores actuales de las propiedades de las instancias de la entidad. Sin embargo, puede haber algunos casos, como
escenarios desconectados, donde desea ver o manipular la información que EF tiene sobre las propiedades. Las
técnicas que se muestran en este tema se aplican igualmente a los modelos creados con Code First y EF Designer.
Entity Framework realiza un seguimiento de dos valores para cada propiedad de una entidad de la que se ha
realizado un seguimiento. El valor actual es, como el nombre indica, el valor actual de la propiedad en la entidad. El
valor original es el valor que tenía la propiedad cuando la entidad se consultaba desde la base de datos o se
adjuntó al contexto.
Hay dos mecanismos generales para trabajar con valores de propiedad:
El valor de una propiedad única se puede obtener de una manera fuertemente tipada mediante el método de
propiedad.
Los valores de todas las propiedades de una entidad se pueden leer en un objeto DbPropertyValues. A
continuación, DbPropertyValues actúa como un objeto similar a un diccionario para permitir la lectura y el
establecimiento de los valores de propiedad. Los valores de un objeto DbPropertyValues se pueden establecer
a partir de los valores de otro objeto DbPropertyValues o de los valores de otro objeto, como otra copia de la
entidad o un objeto de transferencia de datos simple (DTO).
En las secciones siguientes se muestran ejemplos del uso de los dos mecanismos anteriores.
Obtener y establecer el valor actual o original de una propiedad

individual
En el ejemplo siguiente se muestra cómo se puede leer el valor actual de una propiedad y establecerla en un
nuevo valor:

{
// Read the current value of the Name property

string currentName1 = context.Entry(blog).Property(u => u.Name).CurrentValue;
// Set the Name property to a new value

context.Entry(blog).Property(u => u.Name).CurrentValue = "My Fancy Blog";
// Read the current value of the Name property using a string for the property name
object currentName2 = context.Entry(blog).Property("Name").CurrentValue;
// Set the Name property to a new value using a string for the property name
context.Entry(blog).Property("Name").CurrentValue = "My Boring Blog";
}
Use la propiedad OriginalValue en lugar de la propiedad CurrentValue para leer o establecer el valor original.
Tenga en cuenta que el valor devuelto se escribe como "objeto" cuando se utiliza una cadena para especificar el
nombre de la propiedad. Por otro lado, el valor devuelto está fuertemente tipado si se utiliza una expresión
lambda.
Al establecer el valor de la propiedad de este modo, solo se marcará la propiedad como modificada si el nuevo
valor es diferente del valor anterior.
Cuando se establece un valor de propiedad de esta manera, el cambio se detecta automáticamente aunque
AutoDetectChanges esté desactivado.
Obtener y establecer el valor actual de una propiedad no asignada

También se puede leer el valor actual de una propiedad que no está asignada a la base de datos. Un ejemplo de
una propiedad no asignada podría ser una propiedad RssLink en el blog. Este valor se puede calcular en función
de BlogId y, por tanto, no es necesario almacenarlo en la base de datos. Por ejemplo:

{
// Read the current value of an unmapped property
var rssLink = context.Entry(blog).Property(p => p.RssLink).CurrentValue;
// Use a string to specify the property name

var rssLinkAgain = context.Entry(blog).Property("RssLink").CurrentValue;
}
También se puede establecer el valor actual si la propiedad expone un establecedor.

Leer los valores de las propiedades sin asignar es útil al realizar Entity Framework la validación de las propiedades
no asignadas. Por el mismo motivo, los valores actuales se pueden leer y establecer para las propiedades de
entidades a las que el contexto no realiza un seguimiento actualmente. Por ejemplo:

{
// Create an entity that is not being tracked
// Read and set the current value of Name as before

var currentName1 = context.Entry(blog).Property(u => u.Name).CurrentValue;
context.Entry(blog).Property(u => u.Name).CurrentValue = "My Fancy Blog";
var currentName2 = context.Entry(blog).Property("Name").CurrentValue;
context.Entry(blog).Property("Name").CurrentValue = "My Boring Blog";
}
Tenga en cuenta que los valores originales no están disponibles para las propiedades no asignadas o para las
propiedades de entidades de las que el contexto no realiza un seguimiento.
Comprobar si una propiedad está marcada como modificada

En el ejemplo siguiente se muestra cómo comprobar si una propiedad individual está marcada como modificada:

{
var nameIsModified1 = context.Entry(blog).Property(u => u.Name).IsModified;
// Use a string for the property name

var nameIsModified2 = context.Entry(blog).Property("Name").IsModified;
}
Los valores de las propiedades modificadas se envían como actualizaciones a la base de datos cuando se llama a
SaveChanges.
Marcar una propiedad como modificada

En el ejemplo siguiente se muestra cómo forzar que una propiedad individual se marque como modificada:

{
context.Entry(blog).Property(u => u.Name).IsModified = true;
// Use a string for the property name

context.Entry(blog).Property("Name").IsModified = true;
}
Marcar una propiedad como modificada obliga a que se envíe una actualización a la base de datos para la
propiedad cuando se llama a SaveChanges incluso si el valor actual de la propiedad es el mismo que el valor
original.
Actualmente no es posible restablecer una propiedad individual para que no se modifique una vez que se ha
marcado como modificada. Esto es algo que tenemos previsto admitir en una versión futura.
Leer los valores actuales, originales y de base de datos para todas las
propiedades de una entidad
En el ejemplo siguiente se muestra cómo leer los valores actuales, los valores originales y los valores reales de la
base de datos para todas las propiedades asignadas de una entidad.

{
// Make a modification to Name in the tracked entity

blog.Name = "My Cool Blog";
// Make a modification to Name in the database

context.Database.SqlCommand("update dbo.Blogs set Name = 'My Boring Blog' where Id = 1");
// Print out current, original, and database values

Console.WriteLine("Current values:");
PrintValues(context.Entry(blog).CurrentValues);
Console.WriteLine("\nOriginal values:");
PrintValues(context.Entry(blog).OriginalValues);
Console.WriteLine("\nDatabase values:");
PrintValues(context.Entry(blog).GetDatabaseValues());
}
public static void PrintValues(DbPropertyValues values)

{
foreach (var propertyName in values.PropertyNames)
{
Console.WriteLine("Property {0} has value {1}",
propertyName, values[propertyName]);
}
}
Los valores actuales son los valores que las propiedades de la entidad contienen actualmente. Los valores
originales son los valores que se leyeron de la base de datos cuando se realizó la consulta de la entidad. Los
valores de la base de datos son los valores que están almacenados actualmente en la base de datos. Obtener los
valores de la base de datos es útil cuando los valores de la base de datos pueden haber cambiado desde la
consulta de la entidad, por ejemplo, cuando otro usuario ha realizado una edición simultánea en la base de datos.
Establecer valores actuales o originales de otro objeto

Los valores actuales o originales de una entidad de la que se ha realizado un seguimiento se pueden actualizar
mediante la copia de los valores de otro objeto. Por ejemplo:

{
var coolBlog = new Blog { Id = 1, Name = "My Cool Blog" };
var boringBlog = new BlogDto { Id = 1, Name = "My Boring Blog" };
// Change the current and original values by copying the values from other objects
var entry = context.Entry(blog);
entry.CurrentValues.SetValues(coolBlog);
entry.OriginalValues.SetValues(boringBlog);
// Print out current and original values

Console.WriteLine("Current values:");
PrintValues(entry.CurrentValues);
Console.WriteLine("\nOriginal values:");
PrintValues(entry.OriginalValues);
}
public class BlogDto

{
}
La ejecución del código anterior se imprimirá:
Current values:
Property Id has value 1
Property Name has value My Cool Blog
Original values:
Property Id has value 1
Property Name has value My Boring Blog
Esta técnica se usa a veces al actualizar una entidad con valores obtenidos de una llamada de servicio o un cliente
en una aplicación de n niveles. Tenga en cuenta que el objeto utilizado no tiene que ser del mismo tipo que la
entidad, siempre y cuando tenga propiedades cuyos nombres coincidan con los de la entidad. En el ejemplo
anterior, se usa una instancia de BlogDTO para actualizar los valores originales.
Tenga en cuenta que solo las propiedades que se establecen en valores diferentes cuando se copian del otro objeto
se marcan como modificadas.
Establecer los valores actuales o originales de un diccionario

Los valores actuales o originales de una entidad de la que se ha realizado un seguimiento se pueden actualizar
mediante la copia de los valores de un diccionario u otra estructura de datos. Por ejemplo:
{
var newValues = new Dictionary\<string, object>

{
{ "Name", "The New ADO.NET Blog" },
{ "Url", "blogs.msdn.com/adonet" },
};
var currentValues = context.Entry(blog).CurrentValues;
foreach (var propertyName in newValues.Keys)

{
currentValues[propertyName] = newValues[propertyName];
}
PrintValues(currentValues);
}
Use la propiedad OriginalValues en lugar de la propiedad CurrentValues para establecer los valores originales.
Establecer valores actuales o originales de un diccionario mediante la

propiedad
Una alternativa al uso de CurrentValues o OriginalValues, como se muestra arriba, es usar el método de propiedad
para establecer el valor de cada propiedad. Esto puede ser preferible cuando es necesario establecer los valores de
las propiedades complejas. Por ejemplo:

{
var newValues = new Dictionary\<string, object>

{
{ "Name", "John Doe" },
{ "Location.City", "Redmond" },
{ "Location.State.Name", "Washington" },
{ "Location.State.Code", "WA" },
};
var entry = context.Entry(user);
foreach (var propertyName in newValues.Keys)

{
entry.Property(propertyName).CurrentValue = newValues[propertyName];
}
}
En el ejemplo anterior se tiene acceso a las propiedades complejas mediante nombres con puntos. Para conocer
otras formas de obtener acceso a propiedades complejas, vea las dos secciones más adelante en este tema
específicamente sobre las propiedades complejas.
Crear un objeto clonado que contenga valores actual, original o de

base de datos
El objeto DbPropertyValues devuelto de CurrentValues, OriginalValues o GetDatabaseValues se puede usar para
crear un clon de la entidad. Este clon contendrá los valores de propiedad del objeto DbPropertyValues que se usa
para crearlo. Por ejemplo:
{
var clonedBlog = context.Entry(blog).GetDatabaseValues().ToObject();

}
Tenga en cuenta que el objeto devuelto no es la entidad y el contexto no realiza su seguimiento. El objeto devuelto
tampoco tiene ninguna relación establecida en otros objetos.
El objeto clonado puede ser útil para resolver problemas relacionados con las actualizaciones simultáneas en la
base de datos, especialmente cuando se usa una interfaz de usuario que implique el enlace de datos a objetos de
un tipo determinado.
Obtener y establecer los valores actuales o originales de propiedades

complejas
El valor de un objeto complejo completo se puede leer y establecer mediante el método de propiedad, tal como
puede ser para una propiedad primitiva. Además, puede explorar en profundidad el objeto complejo y leer o
establecer las propiedades de ese objeto, o incluso un objeto anidado. Estos son algunos ejemplos:
{
// Get the Location complex object

var location = context.Entry(user)
.Property(u => u.Location)
.CurrentValue;
// Get the nested State complex object using chained calls

var state1 = context.Entry(user)
.ComplexProperty(u => u.Location)
.Property(l => l.State)
.CurrentValue;
// Get the nested State complex object using a single lambda expression
.Property(u => u.Location.State)
.CurrentValue;
// Get the nested State complex object using a dotted string

.Property("Location.State")
.CurrentValue;
// Get the value of the Name property on the nested State complex object using chained calls
var name1 = context.Entry(user)
.ComplexProperty(u => u.Location)
.ComplexProperty(l => l.State)
.Property(s => s.Name)
.CurrentValue;
// Get the value of the Name property on the nested State complex object using a single lambda expression
.Property(u => u.Location.State.Name)
.CurrentValue;
// Get the value of the Name property on the nested State complex object using a dotted string
.Property("Location.State.Name")
.CurrentValue;
}
Use la propiedad OriginalValue en lugar de la propiedad CurrentValue para obtener o establecer un valor original.
Tenga en cuenta que se puede utilizar la propiedad o el método ComplexProperty para tener acceso a una
propiedad compleja. Sin embargo, se debe usar el método ComplexProperty si desea explorar en profundidad el
objeto complejo con llamadas adicionales a propiedades o ComplexProperty.
Usar DbPropertyValues para tener acceso a propiedades complejas

Cuando se usa CurrentValues, OriginalValues o GetDatabaseValues para obtener todos los valores actuales,
originales o de la base de datos de una entidad, los valores de las propiedades complejas se devuelven como
objetos DbPropertyValues anidados. Estos objetos anidados se pueden usar para obtener valores del objeto
complejo. Por ejemplo, el método siguiente imprimirá los valores de todas las propiedades, incluidos los valores
de las propiedades complejas y las propiedades complejas anidadas.
public static void WritePropertyValues(string parentPropertyName, DbPropertyValues propertyValues)
{
foreach (var propertyName in propertyValues.PropertyNames)
{
var nestedValues = propertyValues[propertyName] as DbPropertyValues;
if (nestedValues != null)
{
WritePropertyValues(parentPropertyName + propertyName + ".", nestedValues);
}
else
{
Console.WriteLine("Property {0}{1} has value {2}",
parentPropertyName, propertyName,
propertyValues[propertyName]);
}
}
}
Para imprimir todos los valores de propiedad actuales, se llamaría al método de la siguiente manera:

{
WritePropertyValues("", context.Entry(user).CurrentValues);
}
Administrar los conflictos de simultaneidad
La simultaneidad optimista implica un intento optimista de guardar la entidad en la base de datos, con la
esperanza de que los datos no hayan cambiado desde que se cargó la entidad. Si se da cuenta de que los datos
han cambiado, se produce una excepción y debe resolver el conflicto antes de intentar volver a guardar. En este
tema se explica cómo controlar dichas excepciones en Entity Framework. Las técnicas que se muestran en este
tema se aplican igualmente a los modelos creados con Code First y EF Designer.
Esta publicación no es el lugar adecuado para una descripción completa de la simultaneidad optimista. En las
secciones siguientes se presupone cierto conocimiento de la resolución de simultaneidad y se muestran patrones
para tareas comunes.
Muchos de estos patrones hacen uso de los temas que se describen en trabajar con valores de propiedad.
La resolución de problemas de simultaneidad cuando se usan asociaciones independientes (donde la clave externa
no está asignada a una propiedad de la entidad) es mucho más difícil que cuando se usan asociaciones de clave
externa. Por lo tanto, si va a realizar la resolución de simultaneidad en la aplicación, se recomienda que asigne
siempre las claves externas a las entidades. Todos los ejemplos siguientes suponen que está usando asociaciones
de clave externa.
SaveChanges genera una DbUpdateConcurrencyException cuando se detecta una excepción de simultaneidad
optimista al intentar guardar una entidad que utiliza asociaciones de clave externa.
Resolver excepciones de simultaneidad optimista con Reload (base de

datos gana)
El método Reload se puede usar para sobrescribir los valores actuales de la entidad con los valores ahora en la
base de datos. La entidad se suele devolver al usuario de alguna forma y debe intentar realizar de nuevo los
cambios y volver a guardar. Por ejemplo:

{
blog.Name = "The New ADO.NET Blog";
bool saveFailed;
do
{
saveFailed = false;
try
{
}
{
saveFailed = true;
// Update the values of the entity that failed to save from the store
ex.Entries.Single().Reload();
}
} while (saveFailed);
}
Una buena forma de simular una excepción de simultaneidad es establecer un punto de interrupción en la llamada
a SaveChanges y, a continuación, modificar una entidad que se guarda en la base de datos mediante otra
herramienta como SQL Management Studio. También puede insertar una línea antes de SaveChanges para
actualizar la base de datos directamente mediante SqlCommand. Por ejemplo:
context.Database.SqlCommand(
"UPDATE dbo.Blogs SET Name = 'Another Name' WHERE BlogId = 1");
El método de entradas de DbUpdateConcurrencyException devuelve las instancias de DbEntityEntry para las

entidades que no se pudieron actualizar. (Actualmente, esta propiedad siempre devuelve un valor único para los
problemas de simultaneidad. Puede devolver varios valores para las excepciones de actualización generales). Una
alternativa para algunas situaciones podría ser obtener entradas para todas las entidades que pueden tener que
volver a cargarse desde la base de datos y llamar a recargar para cada una de ellas.
Resolver excepciones de simultaneidad optimista como cliente WINS

El ejemplo anterior que usa la recarga se denomina a veces Database WINS o Store WINS porque los valores de la
entidad se sobrescriben con los valores de la base de datos. En ocasiones, es posible que desee hacer lo contrario y
sobrescribir los valores de la base de datos con los valores actualmente en la entidad. Esto se denomina a veces
cliente WINS y se puede hacer obteniendo los valores de la base de datos actual y estableciéndolo como valores
originales de la entidad. (Vea trabajar con valores de propiedad para obtener información sobre los valores
actuales y originales). Por ejemplo:

{
bool saveFailed;
do
{
saveFailed = false;
try
{
}
{
saveFailed = true;
// Update original values from the database

var entry = ex.Entries.Single();
entry.OriginalValues.SetValues(entry.GetDatabaseValues());
}
}
Resolución personalizada de excepciones de simultaneidad optimista

En ocasiones, es posible que desee combinar los valores que hay actualmente en la base de datos con los valores
de la entidad. Normalmente, esto requiere una lógica personalizada o una interacción del usuario. Por ejemplo,
puede presentar un formulario al usuario que contiene los valores actuales, los valores de la base de datos y un
conjunto predeterminado de valores resueltos. El usuario modificara los valores resueltos según sea necesario y
estos valores resueltos son los que se guardan en la base de datos. Esto se puede hacer mediante los objetos
DbPropertyValues devueltos desde CurrentValues y GetDatabaseValues en la entrada de la entidad. Por ejemplo:
{
bool saveFailed;
do
{
saveFailed = false;
try
{
}
{
saveFailed = true;
// Get the current entity values and the values in the database
var currentValues = entry.CurrentValues;
// Choose an initial set of resolved values. In this case we

// make the default be the values currently in the database.
var resolvedValues = databaseValues.Clone();
// Have the user choose what the resolved values should be

HaveUserResolveConcurrency(currentValues, databaseValues, resolvedValues);
// Update the original values with the database values and

// the current values with whatever the user choose.
entry.CurrentValues.SetValues(resolvedValues);
}
}
public void HaveUserResolveConcurrency(DbPropertyValues currentValues,

DbPropertyValues databaseValues,
DbPropertyValues resolvedValues)
{
// Show the current, database, and resolved values to the user and have
// them edit the resolved values to get the correct resolution.
}
Resolución personalizada de excepciones de simultaneidad optimista

mediante objetos
El código anterior usa instancias de DbPropertyValues para pasar los valores actuales, de base de datos y
resueltos. A veces puede ser más fácil usar instancias de su tipo de entidad para esto. Esto se puede hacer
mediante los métodos ToObject y SetValues de DbPropertyValues. Por ejemplo:
{
bool saveFailed;
do
{
saveFailed = false;
try
{
}
{
saveFailed = true;
// Get the current entity values and the values in the database
// as instances of the entity type
var databaseValuesAsBlog = (Blog)databaseValues.ToObject();
// Choose an initial set of resolved values. In this case we

// make the default be the values currently in the database.
var resolvedValuesAsBlog = (Blog)databaseValues.ToObject();
// Have the user choose what the resolved values should be

HaveUserResolveConcurrency((Blog)entry.Entity,
databaseValuesAsBlog,
resolvedValuesAsBlog);
// Update the original values with the database values and

// the current values with whatever the user choose.
entry.CurrentValues.SetValues(resolvedValuesAsBlog);
}
}
public void HaveUserResolveConcurrency(Blog entity,

Blog databaseValues,
Blog resolvedValues)
{
// Show the current, database, and resolved values to the user and have
// them update the resolved values to get the correct resolution.
}
Trabajar con transacciones
NOTE
En este documento se describe el uso de transacciones en EF6, incluidas las mejoras que hemos agregado desde
EF5 para facilitar el trabajo con transacciones.
Qué hace EF de forma predeterminada

En todas las versiones de Entity Framework, siempre que ejecute SaveChanges () para insertar, actualizar o
eliminar en la base de datos, el marco de trabajo encapsulará esa operación en una transacción. Esta transacción
dura solo el tiempo suficiente para ejecutar la operación y, a continuación, se completa. Al ejecutar otra operación
de este tipo, se inicia una nueva transacción.
A partir de la base de datos EF6. ExecuteSqlCommand () , de forma predeterminada, ajustará el comando en
una transacción si aún no está presente. Hay sobrecargas de este método que le permiten invalidar este
comportamiento si lo desea. Además, en la ejecución EF6 de procedimientos almacenados incluidos en el modelo
a través de API como ObjectContext. ExecuteFunction () hace lo mismo (salvo que no se puede reemplazar el
comportamiento predeterminado en ese momento).
En cualquier caso, el nivel de aislamiento de la transacción es cualquier nivel de aislamiento en el que el
proveedor de base de datos considere su configuración predeterminada. De forma predeterminada, por ejemplo,
en SQL Server este es READ COMMITTED.
Entity Framework no encapsula las consultas en una transacción.
Esta funcionalidad predeterminada es adecuada para muchos usuarios y, si es así, no es necesario hacer nada
diferente en EF6; solo tiene que escribir el código como lo hizo siempre.
Sin embargo, algunos usuarios requieren un mayor control sobre sus transacciones; esto se trata en las secciones
siguientes.
Cómo funcionan las API

Antes de EF6 Entity Framework insista en abrir la propia conexión de base de datos (se produjo una excepción si
se pasa una conexión que ya estaba abierta). Puesto que una transacción solo se puede iniciar en una conexión
abierta, esto significaba que la única forma en que un usuario podía encapsular varias operaciones en una
transacción era usar TransactionScope o usar la propiedad ObjectContext. Connection y comenzar a llamar a
Open () y BeginTransaction () directamente en el objeto EntityConnection devuelto. Además, las llamadas
API que contacten con la base de datos generarán un error si hubiera iniciado una transacción en la conexión de
base de datos subyacente por su cuenta.
NOTE
La limitación de aceptar solo conexiones cerradas se quitó en Entity Framework 6. Para obtener más información, consulte
Administración de conexiones.
A partir de EF6, el marco de trabajo ahora proporciona:
1. Database. BeginTransaction () : método más sencillo para que un usuario inicie y complete transacciones
en un DbContext existente, lo que permite combinar varias operaciones dentro de la misma transacción y, por
lo tanto, todas confirmadas o revertidas como una. También permite al usuario especificar más fácilmente el
nivel de aislamiento para la transacción.
2. Database. UseTransaction () : permite que DbContext use una transacción que se inició fuera del Entity
Framework.
Combinar varias operaciones en una transacción dentro del mismo contexto
Database. BeginTransaction () tiene dos invalidaciones: una que toma un IsolationLevel explícito y otra que no
toma ningún argumento y usa el valor de IsolationLevel predeterminado del proveedor de base de datos
subyacente. Ambas invalidaciones devuelven un objeto DbContextTransaction que proporciona los métodos
Commit () y Rollback () que realizan la confirmación y reversión en la transacción del almacén subyacente.
La DbContextTransaction está pensada para ser eliminada una vez que se ha confirmado o revertido. Una
manera fácil de lograrlo es usar (...) {. ..} sintaxis que llamará automáticamente a Dispose () cuando se complete
el bloque Using:
using System;
using System.Linq;
namespace TransactionsExamples
{
class TransactionsExample
{
static void StartOwnTransactionWithinContext()
{
{
using (var dbContextTransaction = context.Database.BeginTransaction())
{
context.Database.ExecuteSqlCommand(
" WHERE Name LIKE '%Entity Framework%'"
);
var query = context.Posts.Where(p => p.Blog.Rating >= 5);

{
}
dbContextTransaction.Commit();
}
}
}
}
}
NOTE
Iniciar una transacción requiere que la conexión del almacén subyacente esté abierta. Por tanto, si se llama a Database.
BeginTransaction (), se abrirá la conexión si aún no está abierta. Si DbContextTransaction abrió la conexión, se cerrará
cuando se llame a Dispose ().
Pasar una transacción existente al contexto

A veces, desea una transacción que es incluso más amplia en el ámbito y que incluye operaciones en la misma
base de datos pero fuera de EF completamente. Para ello, debe abrir la conexión e iniciar la transacción usted
mismo y, a continuación, indicar a EF a) que use la conexión de base de datos ya abierta y b) para usar la
transacción existente en esa conexión.
Para ello, debe definir y usar un constructor en la clase de contexto que herede de uno de los constructores
DbContext que llevan i) un parámetro de conexión existente y II) el valor booleano contextOwnsConnection.
NOTE
La marca contextOwnsConnection debe establecerse en false cuando se llama en este escenario. Esto es importante a
medida que informa Entity Framework que no debería cerrar la conexión cuando se realiza con ella (por ejemplo, vea la línea
4 a continuación):
using (var conn = new SqlConnection("..."))

{
conn.Open();
{
}
}
Además, debe iniciar la transacción usted mismo (incluido el valor de IsolationLevel si desea evitar la
configuración predeterminada) y dejar que Entity Framework sepa que hay una transacción existente ya iniciada
en la conexión (consulte la línea 33 a continuación).
Después, puede ejecutar operaciones de base de datos directamente en el SqlConnection o en DbContext. Todas
estas operaciones se ejecutan dentro de una transacción. Usted asume la responsabilidad de confirmar o revertir
la transacción y de llamar a Dispose () en ella, así como para cerrar y eliminar la conexión a la base de datos. Por
ejemplo:
using System;
using System.Linq;
{
{
static void UsingExternalTransaction()
{
{
conn.Open();
using (var sqlTxn = conn.BeginTransaction(System.Data.IsolationLevel.Snapshot))

{
sqlCommand.Transaction = sqlTxn;
using (var context =

new BloggingContext(conn, contextOwnsConnection: false))
{
context.Database.UseTransaction(sqlTxn);
var query = context.Posts.Where(p => p.Blog.Rating >= 5);

{
}
}
sqlTxn.Commit();
}
}
}
}
}
Borrar la transacción
Puede pasar null a Database. UseTransaction () para borrar el conocimiento de Entity Framework de la transacción
actual. Entity Framework no confirmará ni revertirá la transacción existente al hacerlo, por lo que debe usar con
cuidado y solo si está seguro de que es lo que desea hacer.
Errores en UseTransaction
Verá una excepción de Database. UseTransaction () si pasa una transacción cuando:
Entity Framework ya tiene una transacción existente
Entity Framework ya está funcionando en TransactionScope
El objeto de conexión en la transacción pasada es NULL. Es decir, la transacción no está asociada a una
conexión; normalmente es un signo de que ya se ha completado la transacción.
El objeto de conexión de la transacción pasada no coincide con la conexión del Entity Framework.
Usar transacciones con otras características
En esta sección se describe cómo interactúan las transacciones anteriores con:
Métodos asincrónicos
Transacciones TransactionScope
Resistencia de conexión
La nueva característica de resistencia de conexión no funciona con las transacciones iniciadas por el usuario. Para
obtener más información, consulte reintento de estrategias de ejecución.
Programación asincrónica
El enfoque descrito en las secciones anteriores no necesita más opciones ni valores de configuración para trabajar
con los métodos de consulta y guardado asíncronos. Pero tenga en cuenta que, en función de lo que haga dentro
de los métodos asincrónicos, esto puede dar lugar a transacciones de ejecución prolongada, lo que a su vez puede
provocar interbloqueos o bloqueos que son incorrectos para el rendimiento de la aplicación global.
Transacciones TransactionScope
Antes de EF6, la manera recomendada de proporcionar transacciones de ámbito mayor era usar un objeto
TransactionScope:
using System.Linq;
{
{
static void UsingTransactionScope()
{
using (var scope = new TransactionScope(TransactionScopeOption.Required))
{
{
conn.Open();

using (var context =

new BloggingContext(conn, contextOwnsConnection: false))
{
{
}
}
}
scope.Complete();
}
}
}
}
SqlConnection y Entity Framework usarían ambas transacciones ambiente TransactionScope y, por tanto, se
confirmarán juntas.
A partir de .NET 4.5.1 TransactionScope, se ha actualizado para que también funcione con métodos asincrónicos
mediante el uso de la enumeración TransactionScopeAsyncFlowOption :
using System.Linq;
{
{
public static void AsyncTransactionScope()
{
using (var scope = new TransactionScope(TransactionScopeAsyncFlowOption.Enabled))
{
{
await conn.OpenAsync();

await sqlCommand.ExecuteNonQueryAsync();

{
{
}
}
}
}
}
}
}
Todavía existen algunas limitaciones en el enfoque de TransactionScope:

Requiere .NET 4.5.1 o superior para trabajar con métodos asincrónicos.
No se puede usar en escenarios en la nube a menos que esté seguro de que tiene una sola conexión (los
escenarios en la nube no admiten transacciones distribuidas).
No se puede combinar con el enfoque Database. UseTransaction () de las secciones anteriores.
Se producirán excepciones si se emite cualquier DDL y no se han habilitado las transacciones distribuidas a
través del servicio MSDTC.
Ventajas del enfoque de TransactionScope:
Actualizará automáticamente una transacción local a una transacción distribuida si realiza más de una
conexión a una base de datos determinada o combina una conexión con una base de datos con una conexión a
una base de datos diferente dentro de la misma transacción (Nota: debe tener el servicio MSDTC configurado
para permitir que funcionen las transacciones distribuidas.
Facilidad de codificación. Si prefiere que la transacción sea ambiente y se trate implícitamente en segundo
plano en lugar de hacerlo explícitamente bajo el control, el enfoque de TransactionScope puede adaptarse
mejor.
En Resumen, con las nuevas API Database. BeginTransaction () y Database. UseTransaction () anteriores, el enfoque
de TransactionScope ya no es necesario para la mayoría de los usuarios. Si sigue usando TransactionScope, tenga
en cuenta las limitaciones anteriores. Se recomienda usar el enfoque descrito en las secciones anteriores, siempre
que sea posible.
Validación de datos
NOTE
Framework 4,1. Si usa una versión anterior, parte o toda la información no se aplica.
El contenido de esta página se adapta a un artículo escrito originalmente por Julia Lerman
(https://thedatafarm.com).
Entity Framework proporciona una gran variedad de características de validación que se pueden transmitir a través
de una interfaz de usuario para la validación del lado cliente o se pueden usar para la validación del lado servidor.
Cuando se usa Code First, se pueden especificar validaciones mediante las configuraciones de anotación o de API
fluida. Las validaciones adicionales, y más complejas, se pueden especificar en el código y funcionarán si el modelo
es el primero de Code, Model First o Database.
El modelo
Mostraré las validaciones con un par sencillo de clases: blog y post.
public class Blog

{
}
public class Post

{
}
Code First usa anotaciones del ensamblado de System.ComponentModel.DataAnnotations como un medio para
configurar clases Code First. Entre estas anotaciones se encuentran las que proporcionan reglas como Required ,
MaxLength y MinLength . Varias aplicaciones cliente de .NET también reconocen estas anotaciones, por ejemplo,
ASP.NET MVC. Puede lograr la validación del lado cliente y del lado servidor con estas anotaciones. Por ejemplo,
puede forzar que la propiedad título del blog sea una propiedad necesaria.
[Required]
Sin ningún cambio de código o marcado adicional en la aplicación, una aplicación MVC existente realizará la
validación del lado cliente, incluso generando dinámicamente un mensaje usando los nombres de la propiedad y
de las anotaciones.
En el método posterior de esta vista de creación, Entity Framework se usa para guardar el nuevo blog en la base de
datos, pero la validación del lado cliente de MVC se desencadena antes de que la aplicación llegue a ese código.
Sin embargo, la validación del lado cliente no es una prueba de viñetas. Los usuarios pueden afectar a las
características de su explorador o peor aún, un pirata informático podría usar algún truco para evitar las
validaciones de la interfaz de usuario. Sin embargo, Entity Framework también reconocerá la anotación Required y
la validará.
Una manera sencilla de probarlo es deshabilitar la característica de validación del lado cliente de MVC. Puede
hacerlo en el archivo Web. config de la aplicación MVC. La sección appSettings tiene una clave para
ClientValidationEnabled. Si se establece esta clave en false, impedirá que la interfaz de usuario realice validaciones.
<appSettings>
<add key="ClientValidationEnabled"value="false"/>
...
</appSettings>
Incluso con la validación del lado cliente deshabilitada, obtendrá la misma respuesta en la aplicación. El mensaje de
error "el campo título es obligatorio" se mostrará como antes. A excepción de ahora, será el resultado de la
validación del lado servidor. Entity Framework realizará la validación en la anotación de Required (antes que los
dos para crear un comando de INSERT para enviarlo a la base de datos) y devolverá el error a MVC, que mostrará
el mensaje.
API fluida
Puede usar la API fluida de Code First en lugar de anotaciones para obtener el mismo cliente & la validación del
lado servidor. En lugar de usar Required , lo mostraré con una validación de MaxLength.
Las configuraciones de la API fluida se aplican como Code First está compilando el modelo a partir de las clases.
Puede insertar las configuraciones invalidando el método OnModelCreating de la clase DbContext. A continuación
se muestra una configuración que especifica que la propiedad BloggerName no puede tener más de 10 caracteres.
{

{
modelBuilder.Entity<Blog>().Property(p => p.BloggerName).HasMaxLength(10);
}
}
Los errores de validación que se produzcan en función de las configuraciones de la API fluida no llegarán
automáticamente a la interfaz de usuario, pero puede capturarlos en el código y, a continuación, responder a ellos
en consecuencia.
Este es un código de error de control de excepciones en la clase BlogController de la aplicación que captura ese
error de validación cuando Entity Framework intenta guardar un blog con un BloggerName que supere el máximo
de 10 caracteres.
[HttpPost]
public ActionResult Edit(int id, Blog blog)
{
try
{
db.Entry(blog).State = EntityState.Modified;
db.SaveChanges();
return RedirectToAction("Index");
}
catch (DbEntityValidationException ex)
{
var error = ex.EntityValidationErrors.First().ValidationErrors.First();
this.ModelState.AddModelError(error.PropertyName, error.ErrorMessage);
return View();
}
}
La validación no se vuelve a pasar automáticamente a la vista, que es el motivo por el que se usa el código
adicional que usa ModelState.AddModelError . Esto garantiza que los detalles del error lo convierten en la vista que
utilizará el ValidationMessageFor HtmlHelper para mostrar el error.
@Html.ValidationMessageFor(model => model.BloggerName)
IValidatableObject
IValidatableObject es una interfaz que reside en System.ComponentModel.DataAnnotations . Aunque no forma parte
de la API de Entity Framework, todavía puede aprovecharla para la validación del lado servidor en las clases de
Entity Framework. IValidatableObject proporciona un método de Validate que Entity Framework llamará
durante SaveChanges o se puede llamar a sí mismo en cualquier momento en el que desee validar las clases.
Las configuraciones como Required y MaxLength realizan la validación en un único campo. En el método Validate
puede tener una lógica aún más compleja, por ejemplo, comparando dos campos.
En el ejemplo siguiente, se ha extendido la clase Blog para implementar IValidatableObject y, a continuación,
proporcionar una regla que el Title y el BloggerName no coincidan.
public class Blog : IValidatableObject
{
[Required]

public IEnumerable<ValidationResult> Validate(ValidationContext validationContext)

{
if (Title == BloggerName)
{
yield return new ValidationResult(
"Blog Title cannot match Blogger Name",
new[] { nameof(Title), nameof(BloggerName) });
}
}
}
El constructor ValidationResult toma un string que representa el mensaje de error y una matriz de string s que
representan los nombres de miembro que están asociados a la validación. Dado que esta validación comprueba el
Title y el BloggerName , se devuelven ambos nombres de propiedad.
A diferencia de la validación proporcionada por la API fluida, el resultado de la validación lo reconocerá en la vista y
el controlador de excepción que se usó anteriormente para agregar el error a ModelState no es necesario. Dado
que he establecido ambos nombres de propiedad en el ValidationResult , MVC HtmlHelpers muestra el mensaje
de error de ambas propiedades.
DbContext.ValidateEntity
DbContext tiene un método reemplazable denominado ValidateEntity . Cuando llame a SaveChanges , Entity
Framework llamará a este método para cada entidad de su caché cuyo estado no sea Unchanged . Puede colocar la
lógica de validación directamente aquí o incluso usar este método para llamar a, por ejemplo, el método
Blog.Validate agregado en la sección anterior.
A continuación se muestra un ejemplo de una invalidación ValidateEntity que valida las nuevas Post para
asegurarse de que el título de la publicación no se ha usado ya. Primero se comprueba si la entidad es una
publicación y se agrega su estado. Si ese es el caso, busca en la base de datos para ver si ya existe una publicación
con el mismo título. Si ya hay una publicación existente, se crea un nuevo DbEntityValidationResult .
DbEntityValidationResult aloja un DbEntityEntry y un ICollection<DbValidationErrors> para una sola entidad. Al
principio de este método, se crea una instancia de DbEntityValidationResult y, a continuación, se agregan los
errores detectados a su colección de ValidationErrors .
protected override DbEntityValidationResult ValidateEntity (

System.Data.Entity.Infrastructure.DbEntityEntry entityEntry,
IDictionary<object, object> items)
{
var result = new DbEntityValidationResult(entityEntry, new List<DbValidationError>());
if (entityEntry.Entity is Post post && entityEntry.State == EntityState.Added)

{
// Check for uniqueness of post title
if (Posts.Where(p => p.Title == post.Title).Any())
{
result.ValidationErrors.Add(
new System.Data.Entity.Validation.DbValidationError(
nameof(Title),
"Post title must be unique."));
}
}
if (result.ValidationErrors.Count > 0)
{
return result;
}
else
{
return base.ValidateEntity(entityEntry, items);
}
}
Desencadenar explícitamente la validación

Una llamada a SaveChanges desencadena todas las validaciones que se describen en este artículo. Pero no es
necesario depender de SaveChanges . Puede que prefiera validar cualquier otro lugar de la aplicación.
DbContext.GetValidationErrors desencadenará todas las validaciones, las definidas por las anotaciones o la API
fluida, la validación creada en IValidatableObject (por ejemplo, Blog.Validate ) y las validaciones realizadas en el
método de DbContext.ValidateEntity .
El código siguiente llamará GetValidationErrors en la instancia actual de un DbContext . ValidationErrors se
agrupan por tipo de entidad en DbEntityValidationResult . El código recorre en iteración los
DbEntityValidationResult s devueltos por el método y, a continuación, a través de cada DbValidationError dentro
de.
foreach (var validationResult in db.GetValidationErrors())

{
foreach (var error in validationResult.ValidationErrors)
{
Debug.WriteLine(
"Entity Property: {0}, Error {1}",
error.PropertyName,
error.ErrorMessage);
}
}
Otras consideraciones al usar la validación

Estos son algunos aspectos que se deben tener en cuenta al usar la validación de Entity Framework:
La carga diferida está deshabilitada durante la validación
EF validará las anotaciones de datos en propiedades no asignadas (propiedades que no están asignadas a una
columna en la base de datos)
La validación se realiza después de que se detecten los cambios durante la SaveChanges . Si realiza cambios
durante la validación, es su responsabilidad notificar al seguimiento de cambios
se produce DbUnexpectedValidationException si se producen errores durante la validación
Las caras que Entity Framework incluye en el modelo (longitud máxima, requerida, etc.) provocarán la
validación, incluso si no hay ninguna anotación de datos en las clases o si se usó el diseñador de EF para crear el
modelo.
Reglas de prioridad:
Las llamadas a la API fluida invalidan las anotaciones de datos correspondientes
Orden de ejecución:
La validación de la propiedad tiene lugar antes de la validación de tipos
La validación de tipos solo se produce si la validación de la propiedad se realiza correctamente
Si una propiedad es compleja, su validación también incluirá:
Validación de nivel de propiedad en las propiedades de tipo complejo
Validación del nivel de tipo en el tipo complejo, incluida la validación de IValidatableObject en el tipo
complejo
Resumen
La API de validación en Entity Framework se reproduce muy bien con la validación del lado cliente en MVC, pero no
tiene que depender de la validación del lado cliente. Entity Framework se encargará de la validación en el lado del
servidor para las anotaciones o configuraciones que haya aplicado con la API fluida de Code First.
También ha visto una serie de puntos de extensibilidad para personalizar el comportamiento si usa la interfaz
IValidatableObject o si va al método DbContext.ValidateEntity . Y estos dos últimos métodos de validación están
disponibles a través del DbContext , independientemente de que use el flujo de trabajo Code First, Model First o
Database First para describir el modelo conceptual.
Entity Framework blogs
Además de la documentación del producto, estos blogs pueden ser una fuente de información útil sobre Entity
Framework:
Blogs del equipo de EF

Blog de .NET: etiqueta Entity Framework
Blog de ADO.NET (ya no está en uso)
Blog de diseño de EF (ya no está en uso)
Bloggers del equipo de EF actuales y anteriores

Arthur Vickers
Brice Lambson
Diego Vega
Rowan Miller
Pawel Kadluczka
Alex James
Zlatko Michailov
Bloggers de la comunidad EF
Julia Lerman
Shawn Wildermuth
Casos prácticos de Microsoft para Entity Framework
En los casos prácticos de esta página se resaltan algunos proyectos de producción reales que han empleado Entity
Framework.
NOTE
En el sitio web de Microsoft ya no están disponibles las versiones detalladas de estos casos de estudio. Por lo tanto, se han
quitado los vínculos.
Epopeya
La epopeya es una empresa de software global de gran tamaño (con más de 400 desarrolladores) que desarrolla
soluciones de planeamiento de recursos empresariales (ERP) para empresas de más de 150 países. Su producto
insignia, Epicr 9, se basa en una arquitectura orientada a servicios (SOA) mediante el .NET Framework. Se enfrenta
a numerosas solicitudes de clientes para proporcionar compatibilidad con Language Integrated Query (LINQ) y
también para reducir la carga en sus servidores de SQL back-end, el equipo decidió actualizar a Visual Studio 2010
y el .NET Framework 4,0. Con el Entity Framework 4,0, pudieron alcanzar estos objetivos y simplificar enormemente
el desarrollo y el mantenimiento. En concreto, la compatibilidad con T4 enriquecida del Entity Framework les
permitió tomar el control completo de su código generado y compilar automáticamente características de ahorro
de rendimiento como las consultas precompiladas y el almacenamiento en caché.
"Hemos realizado algunas pruebas de rendimiento recientemente con el código existente y pudimos reducir las
solicitudes a SQL Server por un 90 por ciento. Esto se debe a ADO.NET Entity Framework 4. " – Erik Johnson,
Vicepresidente, investigación del producto
Soluciones de veracidad
Habiendo adquirido un sistema de software de planeación de eventos que iba a ser difícil de mantener y extenderse
a través de las soluciones de veracidad a largo plazo que usaba Visual Studio 2010 para volver a escribirlo como
una aplicación de Internet eficaz y fácil de usar basada en Silverlight 4. Con .NET RIA Services, podían crear
rápidamente una capa de servicio sobre el Entity Framework que evitaba la duplicación de código y permitía la
validación común y la lógica de autenticación en los niveles.
"Se vendió en el Entity Framework la primera vez que se presentó y el Entity Framework 4 ha demostrado ser
aún mejor. Se han mejorado las herramientas y es más fácil manipular los archivos. edmx que definen el
modelo conceptual, el modelo de almacenamiento y la asignación entre esos modelos... Con el Entity
Framework, puedo conseguir que el nivel de acceso a datos funcione en un día y compilarlo a medida que
avance. La Entity Framework es nuestra capa de acceso a datos de facto; No sé por qué nadie lo usaría ". – Joe
McBride, Desarrollador Senior
NEC muestra soluciones de América

NEC deseaba entrar en el mercado de publicidad basada en el lugar digital con una solución para beneficiar a los
anunciantes y propietarios de la red, así como para aumentar sus ingresos. Para ello, inició un par de aplicaciones
web que automatizan los procesos manuales necesarios en una campaña de ad tradicional. Los sitios se crearon
con ASP.NET, Silverlight 3, AJAX y WCF, junto con los Entity Framework en la capa de acceso a datos para
comunicarse con SQL Server 2008.
"Con SQL Server, pensamos que podríamos obtener el rendimiento que necesitábamos para servir a los
anunciantes y redes con información en tiempo real y la confiabilidad para garantizar que la información de
nuestras aplicaciones críticas siempre estuviera disponible"-Mike Corcoran, Director de ti
Dimensiones de Darwin
Gracias a una amplia gama de tecnologías de Microsoft, el equipo de Darwin ha establecido la creación de un
portal de Avatar en línea para que los consumidores puedan utilizarla con el fin de crear atractivas avatares reales
para su uso en juegos, animaciones y páginas de redes sociales. Con las ventajas de productividad del Entity
Framework y la extracción de componentes como Windows Workflow Foundation (WF) y Windows Server
AppFabric (una memoria caché de aplicaciones en memoria altamente escalable), el equipo pudo ofrecer un
producto sorprendente en un 35% menos tiempo de desarrollo. A pesar de que los miembros del equipo se dividen
en varios países, el equipo sigue un proceso de desarrollo ágil con versiones semanales.
"Intentamos no crear tecnología para la tecnología. Como inicio, es fundamental que se aproveche la tecnología
que ahorra tiempo y dinero. .NET era la elección para el desarrollo rápido y rentable ". – Zachary Olsen,
arquitecto
Silverware
Con más de 15 años de experiencia en el desarrollo de soluciones de punto de venta (POS) para grupos de
restaurante pequeños y de tamaño mediano, el equipo de desarrollo de silverware se ha establecido para mejorar
su producto con características de nivel empresarial más grandes con el fin de atraer más cadenas de restaurante.
Con la versión más reciente de las herramientas de desarrollo de Microsoft, podían crear la nueva solución cuatro
veces más rápido que antes. Las nuevas características clave como LINQ y el Entity Framework facilitan el traslado
de Crystal Reports a SQL Server 2008 y SQL Server Reporting Services (SSRS) para sus necesidades de informes y
almacenamiento de datos.
"La administración eficaz de los datos es fundamental para el éxito de SilverWare, y por eso se decidió adoptar
SQL Reporting". -Nicholas Romanidis, Director de ingeniería de ti/software
Contribuir a Entity Framework 6
Entity Framework 6 se desarrolla con un modelo de código abierto en GitHub. Aunque el enfoque principal del
equipo de Entity Framework en Microsoft es agregar nuevas características a Entity Framework Core y no
esperamos que se agreguen características principales a Entity Framework 6, seguimos aceptando contribuciones.
En el caso de las contribuciones del producto, comience en la página wiki de colaboración en nuestro repositorio de
github.
Para obtener información sobre las contribuciones de documentación, empiece a leer la Guía de contribución en
nuestro repositorio de documentación.
Obtener ayuda con Entity Framework
Preguntas sobre el uso de EF

La mejor manera de obtener ayuda sobre el uso de Entity Framework es publicar una pregunta en Stack Overflow
mediante la etiqueta Entity-Framework .
Si no está familiarizado con Stack Overflow, asegúrese de leer las directricespara realizar preguntas. En concreto,
no utilice Stack Overflow para informar de errores, formular preguntas de la hoja de ruta o sugerir nuevas
características.
Informes de errores y solicitudes de características

Si ha encontrado un error que cree que debería corregirse, que tiene una característica que le gustaría ver
implementada, o una pregunta a la que no encontró una respuesta, cree un problema en el repositorio de github
de EF6.
Entity Framework Glosario
Code First
Crear un modelo de Entity Framework mediante código. El modelo puede tener como destino una base de datos
existente o una nueva.
Context
Una clase que representa una sesión con la base de datos, lo que permite consultar y guardar datos. Un contexto se
deriva de la clase DbContext o ObjectContext.
Convención (Code First)

Una regla que Entity Framework usa para inferir la forma de su modelo a partir de las clases.
Database First
Crear un modelo de Entity Framework, mediante el diseñador de EF, que tiene como destino una base de datos
existente.
Carga diligente
Patrón de carga de datos relacionados donde una consulta para un tipo de entidad también carga las entidades
relacionadas como parte de la consulta.
EF Designer
Diseñador visual de Visual Studio que permite crear un modelo de Entity Framework mediante cuadros y líneas.
Entidad
Clase u objeto que representa datos de aplicación como clientes, productos y pedidos.
Entity Data Model

Modelo que describe las entidades y las relaciones entre ellas. EF usa EDM para describir el modelo conceptual en
el que los programas de desarrollador. EDM se basa en el modelo de relación de entidades introducido por Dr.
Peter Chen. El EDM se desarrolló originalmente con el objetivo principal de convertirse en el modelo de datos
común en un conjunto de tecnologías de desarrollador y de servidor de Microsoft. EDM también se usa como
parte del protocolo OData.
Carga explícita
Patrón de carga de datos relacionados en los que los objetos relacionados se cargan llamando a una API.
API fluida
Una API que se puede usar para configurar un modelo de Code First.
Asociación de clave externa
Asociación entre entidades donde una propiedad que representa la clave externa se incluye en la clase de la
entidad dependiente. Por ejemplo, Product contiene una propiedad CategoryId.
Relación de identificación
Relación donde la clave principal de la entidad principal también forma parte de la clave principal de la entidad
dependiente. En este tipo de relación, la entidad dependiente no puede existir sin la entidad principal.
Asociación independiente
Asociación entre entidades en las que no hay ninguna propiedad que represente la clave externa en la clase de la
entidad dependiente. Por ejemplo, una clase de producto contiene una relación con la categoría pero no tiene la
propiedad CategoryId. Entity Framework realiza un seguimiento del estado de la Asociación independientemente
del estado de las entidades en los dos extremos de la asociación.
Carga diferida
Patrón de carga de datos relacionados en los que los objetos relacionados se cargan automáticamente cuando se
tiene acceso a una propiedad de navegación.
Model First
Crear un modelo de Entity Framework, mediante el diseñador de EF, que se utiliza para crear una nueva base de
datos.
Propiedad de navegación
Propiedad de una entidad que hace referencia a otra entidad. Por ejemplo, el producto contiene una propiedad de
navegación categoría y la categoría contiene una propiedad de navegación productos.
POCO
Acrónimo para el objeto CLR antiguo. Una clase de usuario simple que no tiene dependencias con ningún marco
de trabajo. En el contexto de EF, una clase de entidad que no se deriva de EntityObject, implementa las interfaces o
incluye cualquier atributo definido en EF. Estas clases de entidad que se desacoplan del marco de persistencia
también se consideran "que ignoran la persistencia".
Inverso de relación
Extremo opuesto de una relación, por ejemplo, product. Categoría y categoría. Manuales.
Entidad de seguimiento propio

Una entidad creada a partir de una plantilla de generación de código que ayuda con el desarrollo de N niveles.
Tabla por tipo concreto (TPC)

Método de asignación de la herencia en la que cada tipo no abstracto de la jerarquía se asigna a una tabla
independiente en la base de datos.
Tabla por jerarquía (TPH)

Método de asignación de la herencia en la que todos los tipos de la jerarquía se asignan a la misma tabla de la base
de datos. Se utiliza una o varias columnas de discriminador para identificar a qué tipo está asociada cada fila.
Tabla por tipo (TPT)

Método de asignación de la herencia en la que las propiedades comunes de todos los tipos de la jerarquía se
asignan a la misma tabla de la base de datos, pero las propiedades exclusivas de cada tipo se asignan a una tabla
independiente.
Detección de tipos
El proceso de identificar los tipos que deben formar parte de un modelo de Entity Framework.
Base de datos de ejemplo School
Este tema contiene el esquema y los datos de la base de datos School. La base de datos School de ejemplo se
usa en varios lugares de la documentación Entity Framework.
NOTE
El servidor de base de datos que se instala con Visual Studio es diferente en función de la versión de Visual Studio que
use. Vea las versiones de Visual Studio para obtener más información sobre lo que se debe usar.
Estos son los pasos para crear la base de datos:

Abra Visual Studio.
Ver -> Explorador de ser vidores
Haga clic con el botón derecho en conexiones de datos -> Agregar conexión...
seleccionar Microsoft SQL Ser ver como origen de datos
Escriba School como nombre de la base de datos
Si usa Visual Studio 2012 o una versión más reciente
consulta .
Seleccionar datos -> el Editor de Transact SQL -> nueva conexión de consulta...
Escriba .\SQLEXPRESS como el nombre del servidor y haga clic en Aceptar .
Seleccione la base de datos STESample en la lista desplegable de la parte superior del editor de
consultas.
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
-- Create the Department table.

IF NOT EXISTS (SELECT * FROM sys.objects
WHERE object_id = OBJECT_ID(N'[dbo].[Department]')
AND type in (N'U'))
BEGIN
CREATE TABLE [dbo].[Department]([DepartmentID] [int] NOT NULL,
[Name] [nvarchar](50) NOT NULL,
[Budget] [money] NOT NULL,
[StartDate] [datetime] NOT NULL,
[Administrator] [int] NULL,
CONSTRAINT [PK_Department] PRIMARY KEY CLUSTERED
CONSTRAINT [PK_Department] PRIMARY KEY CLUSTERED
(
[DepartmentID] ASC
)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]) ON [PRIMARY]
END
GO
-- Create the Person table.

WHERE object_id = OBJECT_ID(N'[dbo].[Person]')
AND type in (N'U'))
BEGIN
CREATE TABLE [dbo].[Person]([PersonID] [int] IDENTITY(1,1) NOT NULL,
[LastName] [nvarchar](50) NOT NULL,
[FirstName] [nvarchar](50) NOT NULL,
[HireDate] [datetime] NULL,
[EnrollmentDate] [datetime] NULL,
[Discriminator] [nvarchar](50) NOT NULL,
CONSTRAINT [PK_School.Student] PRIMARY KEY CLUSTERED
(
[PersonID] ASC
END
GO
-- Create the OnsiteCourse table.

WHERE object_id = OBJECT_ID(N'[dbo].[OnsiteCourse]')
AND type in (N'U'))
BEGIN
CREATE TABLE [dbo].[OnsiteCourse]([CourseID] [int] NOT NULL,
[Location] [nvarchar](50) NOT NULL,
[Days] [nvarchar](50) NOT NULL,
[Time] [smalldatetime] NOT NULL,
CONSTRAINT [PK_OnsiteCourse] PRIMARY KEY CLUSTERED
(
[CourseID] ASC
END
GO
-- Create the OnlineCourse table.

WHERE object_id = OBJECT_ID(N'[dbo].[OnlineCourse]')
AND type in (N'U'))
BEGIN
CREATE TABLE [dbo].[OnlineCourse]([CourseID] [int] NOT NULL,
[URL] [nvarchar](100) NOT NULL,
CONSTRAINT [PK_OnlineCourse] PRIMARY KEY CLUSTERED
(
[CourseID] ASC
END
GO
--Create the StudentGrade table.

WHERE object_id = OBJECT_ID(N'[dbo].[StudentGrade]')
AND type in (N'U'))
BEGIN
CREATE TABLE [dbo].[StudentGrade]([EnrollmentID] [int] IDENTITY(1,1) NOT NULL,
[CourseID] [int] NOT NULL,
[StudentID] [int] NOT NULL,
[Grade] [decimal](3, 2) NULL,
CONSTRAINT [PK_StudentGrade] PRIMARY KEY CLUSTERED
(
[EnrollmentID] ASC
END
GO
GO
-- Create the CourseInstructor table.

WHERE object_id = OBJECT_ID(N'[dbo].[CourseInstructor]')
AND type in (N'U'))
BEGIN
CREATE TABLE [dbo].[CourseInstructor]([CourseID] [int] NOT NULL,
[PersonID] [int] NOT NULL,
CONSTRAINT [PK_CourseInstructor] PRIMARY KEY CLUSTERED
(
[CourseID] ASC,
[PersonID] ASC
END
GO
-- Create the Course table.

WHERE object_id = OBJECT_ID(N'[dbo].[Course]')
AND type in (N'U'))
BEGIN
CREATE TABLE [dbo].[Course]([CourseID] [int] NOT NULL,
[Title] [nvarchar](100) NOT NULL,
[Credits] [int] NOT NULL,
[DepartmentID] [int] NOT NULL,
CONSTRAINT [PK_School.Course] PRIMARY KEY CLUSTERED
(
[CourseID] ASC
END
GO
-- Create the OfficeAssignment table.

WHERE object_id = OBJECT_ID(N'[dbo].[OfficeAssignment]')
AND type in (N'U'))
BEGIN
CREATE TABLE [dbo].[OfficeAssignment]([InstructorID] [int] NOT NULL,
[Location] [nvarchar](50) NOT NULL,
[Timestamp] [timestamp] NOT NULL,
CONSTRAINT [PK_OfficeAssignment] PRIMARY KEY CLUSTERED
(
[InstructorID] ASC
END
GO
-- Define the relationship between OnsiteCourse and Course.

IF NOT EXISTS (SELECT * FROM sys.foreign_keys
WHERE object_id = OBJECT_ID(N'[dbo].[FK_OnsiteCourse_Course]')
AND parent_object_id = OBJECT_ID(N'[dbo].[OnsiteCourse]'))
ALTER TABLE [dbo].[OnsiteCourse] WITH CHECK ADD
CONSTRAINT [FK_OnsiteCourse_Course] FOREIGN KEY([CourseID])
REFERENCES [dbo].[Course] ([CourseID])
GO
ALTER TABLE [dbo].[OnsiteCourse] CHECK
CONSTRAINT [FK_OnsiteCourse_Course]
GO
-- Define the relationship between OnlineCourse and Course.

WHERE object_id = OBJECT_ID(N'[dbo].[FK_OnlineCourse_Course]')
AND parent_object_id = OBJECT_ID(N'[dbo].[OnlineCourse]'))
ALTER TABLE [dbo].[OnlineCourse] WITH CHECK ADD
CONSTRAINT [FK_OnlineCourse_Course] FOREIGN KEY([CourseID])
GO
ALTER TABLE [dbo].[OnlineCourse] CHECK
CONSTRAINT [FK_OnlineCourse_Course]
CONSTRAINT [FK_OnlineCourse_Course]
GO
-- Define the relationship between StudentGrade and Course.

WHERE object_id = OBJECT_ID(N'[dbo].[FK_StudentGrade_Course]')
AND parent_object_id = OBJECT_ID(N'[dbo].[StudentGrade]'))
ALTER TABLE [dbo].[StudentGrade] WITH CHECK ADD
CONSTRAINT [FK_StudentGrade_Course] FOREIGN KEY([CourseID])
GO
ALTER TABLE [dbo].[StudentGrade] CHECK
CONSTRAINT [FK_StudentGrade_Course]
GO
--Define the relationship between StudentGrade and Student.

WHERE object_id = OBJECT_ID(N'[dbo].[FK_StudentGrade_Student]')
AND parent_object_id = OBJECT_ID(N'[dbo].[StudentGrade]'))
ALTER TABLE [dbo].[StudentGrade] WITH CHECK ADD
CONSTRAINT [FK_StudentGrade_Student] FOREIGN KEY([StudentID])
REFERENCES [dbo].[Person] ([PersonID])
GO
ALTER TABLE [dbo].[StudentGrade] CHECK
CONSTRAINT [FK_StudentGrade_Student]
GO
-- Define the relationship between CourseInstructor and Course.

WHERE object_id = OBJECT_ID(N'[dbo].[FK_CourseInstructor_Course]')
AND parent_object_id = OBJECT_ID(N'[dbo].[CourseInstructor]'))
ALTER TABLE [dbo].[CourseInstructor] WITH CHECK ADD
CONSTRAINT [FK_CourseInstructor_Course] FOREIGN KEY([CourseID])
GO
ALTER TABLE [dbo].[CourseInstructor] CHECK
CONSTRAINT [FK_CourseInstructor_Course]
GO
-- Define the relationship between CourseInstructor and Person.

WHERE object_id = OBJECT_ID(N'[dbo].[FK_CourseInstructor_Person]')
AND parent_object_id = OBJECT_ID(N'[dbo].[CourseInstructor]'))
ALTER TABLE [dbo].[CourseInstructor] WITH CHECK ADD
CONSTRAINT [FK_CourseInstructor_Person] FOREIGN KEY([PersonID])
GO
ALTER TABLE [dbo].[CourseInstructor] CHECK
CONSTRAINT [FK_CourseInstructor_Person]
GO
-- Define the relationship between Course and Department.

WHERE object_id = OBJECT_ID(N'[dbo].[FK_Course_Department]')
AND parent_object_id = OBJECT_ID(N'[dbo].[Course]'))
ALTER TABLE [dbo].[Course] WITH CHECK ADD
CONSTRAINT [FK_Course_Department] FOREIGN KEY([DepartmentID])
REFERENCES [dbo].[Department] ([DepartmentID])
GO
ALTER TABLE [dbo].[Course] CHECK CONSTRAINT [FK_Course_Department]
GO
--Define the relationship between OfficeAssignment and Person.

WHERE object_id = OBJECT_ID(N'[dbo].[FK_OfficeAssignment_Person]')
AND parent_object_id = OBJECT_ID(N'[dbo].[OfficeAssignment]'))
ALTER TABLE [dbo].[OfficeAssignment] WITH CHECK ADD
CONSTRAINT [FK_OfficeAssignment_Person] FOREIGN KEY([InstructorID])
GO
GO
ALTER TABLE [dbo].[OfficeAssignment] CHECK
CONSTRAINT [FK_OfficeAssignment_Person]
GO
-- Create InsertOfficeAssignment stored procedure.

WHERE object_id = OBJECT_ID(N'[dbo].[InsertOfficeAssignment]')
AND type in (N'P', N'PC'))
BEGIN
EXEC dbo.sp_executesql @statement = N'
CREATE PROCEDURE [dbo].[InsertOfficeAssignment]
@InstructorID int,
@Location nvarchar(50)
AS
INSERT INTO dbo.OfficeAssignment (InstructorID, Location)
VALUES (@InstructorID, @Location);
IF @@ROWCOUNT > 0
BEGIN
SELECT [Timestamp] FROM OfficeAssignment
WHERE InstructorID=@InstructorID;
END
'
END
GO
--Create the UpdateOfficeAssignment stored procedure.

WHERE object_id = OBJECT_ID(N'[dbo].[UpdateOfficeAssignment]')
BEGIN
CREATE PROCEDURE [dbo].[UpdateOfficeAssignment]
@InstructorID int,
@Location nvarchar(50),
@OrigTimestamp timestamp
AS
UPDATE OfficeAssignment SET Location=@Location
WHERE InstructorID=@InstructorID AND [Timestamp]=@OrigTimestamp;
IF @@ROWCOUNT > 0
BEGIN
SELECT [Timestamp] FROM OfficeAssignment
END
'
END
GO
-- Create the DeleteOfficeAssignment stored procedure.

WHERE object_id = OBJECT_ID(N'[dbo].[DeleteOfficeAssignment]')
BEGIN
CREATE PROCEDURE [dbo].[DeleteOfficeAssignment]
@InstructorID int
AS
DELETE FROM OfficeAssignment
'
END
GO
-- Create the DeletePerson stored procedure.

WHERE object_id = OBJECT_ID(N'[dbo].[DeletePerson]')
BEGIN
CREATE PROCEDURE [dbo].[DeletePerson]
@PersonID int
AS
DELETE FROM Person WHERE PersonID = @PersonID;
'
END
GO
-- Create the UpdatePerson stored procedure.

WHERE object_id = OBJECT_ID(N'[dbo].[UpdatePerson]')
BEGIN
CREATE PROCEDURE [dbo].[UpdatePerson]
@PersonID int,
@HireDate datetime,
@EnrollmentDate datetime,
@Discriminator nvarchar(50)
AS
UPDATE Person SET LastName=@LastName,
FirstName=@FirstName,
HireDate=@HireDate,
EnrollmentDate=@EnrollmentDate,
Discriminator=@Discriminator
WHERE PersonID=@PersonID;
'
END
GO
-- Create the InsertPerson stored procedure.

WHERE object_id = OBJECT_ID(N'[dbo].[InsertPerson]')
BEGIN
CREATE PROCEDURE [dbo].[InsertPerson]
@HireDate datetime,
@EnrollmentDate datetime,
@Discriminator nvarchar(50)
AS
INSERT INTO dbo.Person (LastName,
FirstName,
HireDate,
EnrollmentDate,
Discriminator)
VALUES (@LastName,
@FirstName,
@HireDate,
@EnrollmentDate,
@Discriminator);
SELECT SCOPE_IDENTITY() as NewPersonID;
'
END
GO
-- Create GetStudentGrades stored procedure.

WHERE object_id = OBJECT_ID(N'[dbo].[GetStudentGrades]')
BEGIN
CREATE PROCEDURE [dbo].[GetStudentGrades]
@StudentID int
AS
SELECT EnrollmentID, Grade, CourseID, StudentID FROM dbo.StudentGrade
WHERE StudentID = @StudentID
'
END
GO
-- Create GetDepartmentName stored procedure.

WHERE object_id = OBJECT_ID(N'[dbo].[GetDepartmentName]')
BEGIN
CREATE PROCEDURE [dbo].[GetDepartmentName]
@ID int,
@Name nvarchar(50) OUTPUT
AS
SELECT @Name = Name FROM Department
WHERE DepartmentID = @ID
'
END
GO
-- Insert data into the Person table.

USE School
GO
SET IDENTITY_INSERT dbo.Person ON
GO
INSERT INTO dbo.Person (PersonID, LastName, FirstName, HireDate, EnrollmentDate, Discriminator)
VALUES (1, 'Abercrombie', 'Kim', '1995-03-11', null, 'Instructor');
VALUES (2, 'Barzdukas', 'Gytis', null, '2005-09-01', 'Student');
VALUES (3, 'Justice', 'Peggy', null, '2001-09-01', 'Student');
VALUES (4, 'Fakhouri', 'Fadi', '2002-08-06', null, 'Instructor');
VALUES (5, 'Harui', 'Roger', '1998-07-01', null, 'Instructor');
VALUES (6, 'Li', 'Yan', null, '2002-09-01', 'Student');
VALUES (7, 'Norman', 'Laura', null, '2003-09-01', 'Student');
VALUES (8, 'Olivotto', 'Nino', null, '2005-09-01', 'Student');
VALUES (9, 'Tang', 'Wayne', null, '2005-09-01', 'Student');
VALUES (10, 'Alonso', 'Meredith', null, '2002-09-01', 'Student');
VALUES (11, 'Lopez', 'Sophia', null, '2004-09-01', 'Student');
VALUES (12, 'Browning', 'Meredith', null, '2000-09-01', 'Student');
VALUES (13, 'Anand', 'Arturo', null, '2003-09-01', 'Student');
VALUES (14, 'Walker', 'Alexandra', null, '2000-09-01', 'Student');
VALUES (15, 'Powell', 'Carson', null, '2004-09-01', 'Student');
VALUES (16, 'Jai', 'Damien', null, '2001-09-01', 'Student');
VALUES (17, 'Carlson', 'Robyn', null, '2005-09-01', 'Student');
VALUES (18, 'Zheng', 'Roger', '2004-02-12', null, 'Instructor');
VALUES (19, 'Bryant', 'Carson', null, '2001-09-01', 'Student');
VALUES (20, 'Suarez', 'Robyn', null, '2004-09-01', 'Student');
VALUES (21, 'Holt', 'Roger', null, '2004-09-01', 'Student');
VALUES (21, 'Holt', 'Roger', null, '2004-09-01', 'Student');
VALUES (22, 'Alexander', 'Carson', null, '2005-09-01', 'Student');
VALUES (23, 'Morgan', 'Isaiah', null, '2001-09-01', 'Student');
VALUES (24, 'Martin', 'Randall', null, '2005-09-01', 'Student');
VALUES (25, 'Kapoor', 'Candace', '2001-01-15', null, 'Instructor');
VALUES (26, 'Rogers', 'Cody', null, '2002-09-01', 'Student');
VALUES (27, 'Serrano', 'Stacy', '1999-06-01', null, 'Instructor');
VALUES (28, 'White', 'Anthony', null, '2001-09-01', 'Student');
VALUES (29, 'Griffin', 'Rachel', null, '2004-09-01', 'Student');
VALUES (30, 'Shan', 'Alicia', null, '2003-09-01', 'Student');
VALUES (31, 'Stewart', 'Jasmine', '1997-10-12', null, 'Instructor');
VALUES (32, 'Xu', 'Kristen', '2001-7-23', null, 'Instructor');
VALUES (33, 'Gao', 'Erica', null, '2003-01-30', 'Student');
VALUES (34, 'Van Houten', 'Roger', '2000-12-07', null, 'Instructor');
GO
SET IDENTITY_INSERT dbo.Person OFF
GO
-- Insert data into the Department table.

INSERT INTO dbo.Department (DepartmentID, [Name], Budget, StartDate, Administrator)
VALUES (1, 'Engineering', 350000.00, '2007-09-01', 2);
VALUES (2, 'English', 120000.00, '2007-09-01', 6);
VALUES (4, 'Economics', 200000.00, '2007-09-01', 4);
VALUES (7, 'Mathematics', 250000.00, '2007-09-01', 3);
GO
-- Insert data into the Course table.

INSERT INTO dbo.Course (CourseID, Title, Credits, DepartmentID)
VALUES (1050, 'Chemistry', 4, 1);
VALUES (1061, 'Physics', 4, 1);
VALUES (1045, 'Calculus', 4, 7);
VALUES (2030, 'Poetry', 2, 2);
VALUES (2021, 'Composition', 3, 2);
VALUES (2042, 'Literature', 4, 2);
VALUES (4022, 'Microeconomics', 3, 4);
VALUES (4041, 'Macroeconomics', 3, 4);
VALUES (4061, 'Quantitative', 2, 4);
VALUES (3141, 'Trigonometry', 4, 7);
GO
-- Insert data into the OnlineCourse table.

INSERT INTO dbo.OnlineCourse (CourseID, URL)
VALUES (2030, 'http://www.fineartschool.net/Poetry');
VALUES (2030, 'http://www.fineartschool.net/Poetry');
VALUES (2021, 'http://www.fineartschool.net/Composition');
VALUES (4041, 'http://www.fineartschool.net/Macroeconomics');
VALUES (3141, 'http://www.fineartschool.net/Trigonometry');
--Insert data into OnsiteCourse table.

INSERT INTO dbo.OnsiteCourse (CourseID, Location, Days, [Time])
VALUES (1050, '123 Smith', 'MTWH', '11:30');
VALUES (1061, '234 Smith', 'TWHF', '13:15');
VALUES (1045, '121 Smith','MWHF', '15:30');
VALUES (4061, '22 Williams', 'TH', '11:15');
VALUES (2042, '225 Adams', 'MTWH', '11:00');
VALUES (4022, '23 Williams', 'MWF', '9:00');
-- Insert data into the CourseInstructor table.

INSERT INTO dbo.CourseInstructor(CourseID, PersonID)
VALUES (1050, 1);
VALUES (1061, 31);
VALUES (1045, 5);
VALUES (2030, 4);
VALUES (2021, 27);
VALUES (2042, 25);
VALUES (4022, 18);
VALUES (4041, 32);
VALUES (4061, 34);
GO
--Insert data into the OfficeAssignment table.

INSERT INTO dbo.OfficeAssignment(InstructorID, Location)
VALUES (1, '17 Smith');
VALUES (4, '29 Adams');
VALUES (5, '37 Williams');
VALUES (25, '57 Adams');
-- Insert data into the StudentGrade table.

INSERT INTO dbo.StudentGrade (CourseID, StudentID, Grade)
VALUES (2021, 2, 4);
VALUES (2030, 2, 3.5);
VALUES (2021, 3, 3);
VALUES (2021, 3, 3);
VALUES (2030, 3, 4);
VALUES (2021, 6, 2.5);
VALUES (2042, 6, 3.5);
VALUES (2021, 7, 3.5);
VALUES (2042, 7, 4);
VALUES (2021, 8, 3);
VALUES (2042, 8, 3);
VALUES (4041, 9, 3.5);
VALUES (4041, 10, null);
VALUES (4041, 11, 2.5);
VALUES (4022, 14, 3);
VALUES (4022, 13, 4);
VALUES (4061, 13, 4);
VALUES (4041, 14, 3);
VALUES (4022, 15, 2.5);
VALUES (4022, 16, 2);
VALUES (4022, 19, 3.5);
VALUES (4061, 20, 4);
VALUES (4061, 21, 2);
VALUES (4022, 22, 3);
VALUES (4041, 22, 3.5);
VALUES (4061, 22, 2.5);
VALUES (4022, 23, 3);
VALUES (1045, 23, 1.5);
VALUES (1061, 24, 4);
VALUES (1061, 25, 3);
VALUES (1050, 26, 3.5);
VALUES (1061, 26, 3);
VALUES (1061, 27, 3);
VALUES (1045, 28, 2.5);
VALUES (1050, 28, 3.5);
VALUES (1061, 29, 4);
VALUES (1050, 30, 3.5);
VALUES (1061, 30, 4);
GO
Extensiones de & de Entity Framework Tools
IMPORTANT
Las extensiones se compilan mediante una variedad de orígenes y no se mantienen como parte de Entity Framework. Al
considerar una extensión de terceros, evalúe la calidad, las licencias, la compatibilidad, el soporte técnico, etc., a fin de
asegurarse de que cumple sus requisitos.
Entity Framework ha sido un popular O/RM durante muchos años. Estos son algunos ejemplos de herramientas y
extensiones gratuitas y de pago desarrolladas para ello:
EF Power Tools Community Edition
Analizador de EF
Generador de perfiles ORM
LINQPad
LLBLGen Pro
Huagati herramientas DBML/EDMX
Entity Developer

EF Core vs EF6: Comparar las versiones de Entity Framework

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

EF Core vs EF6: Comparar las versiones de Entity Framework

Cargado por

Copyright:

Formatos disponibles

Contents

Entity Framework es un asignador relacional de objetos (O/RM) que permite a los

Entity Framework Core

EF Core es una versión ligera, extensible y multiplataforma de Entity Framework.

Proveedores de bases de datos

EF 6 es una tecnología de acceso a datos probada con muchos años de características

Asignación de clase básica Sí 1.0

Constructores con parámetros 2.1

Conversiones de valores de propiedad 2.1

Tipos asignados sin claves 2.1

Convenciones personalizadas Sí 1.0 (parcial; n.º 214)

Anotaciones de datos Sí 1.0

API fluida Sí 1.0

Herencia: tabla por jerarquía (TPH) Sí 1.0

Propiedades de estado reemplazadas 1.0

Claves alternativas 1.0

Navegaciones de varios a varios Sí Planeado para la versión 5.0 (n.º 19003)

Varios a varios sin entidad de Sí En el trabajo pendiente (n.º 1368)

Generación de claves: Base de datos Sí 1.0

Generación de claves: Cliente 1.0

Tipos complejos/de propiedad Sí 2.0

Datos espaciales Sí 2.2

Formato de modelo: Código Sí 1.0

Crear modelo desde base de datos: Sí 1.0

Filtros de consulta global 2.0

División de tablas Sí 2.0

División de entidades Sí Stretch para la versión 5.0 (n.º 620) (1)

Asignación de función escalar de base Insuficiente 2.0

Asignación de campos 1.1

Tipos de referencia que aceptan valores 3.0

Visualización gráfica de modelo Sí No hay soporte técnico planeado (2)

Editor de modelo gráfico Sí No hay soporte técnico planeado (2)

Formato de modelo: EDMX (XML) Sí No hay soporte técnico planeado (2)

Consultas LINQ Sí 1.0

SQL generado legible Insuficiente 1.0

Traslación de GroupBy Sí 2.1

Carga de datos relacionados: diligente Sí 1.0

Carga de datos relacionados: Carga 2.1

Carga de datos relacionados: Vago Sí 2.1

Carga de datos relacionados: Explicit Sí 1.1

Consultas SQL sin formato: Tipos de Sí 1.0

Consultas SQL sin formato: Tipos de Sí 2.1

Consultas SQL sin formato: Redacción 1.0

Consultas compiladas de manera Insuficiente 2.0

await foreach (C# 8.0) 3.0

Lenguaje de consulta basado en texto Sí No hay soporte técnico planeado (2)

Seguimiento de cambios: Depurador de Sí 1.0

Seguimiento de cambios: notificación Sí 1.0

Seguimiento de cambios: Servidores Sí Combinado para la versión 5.0

Acceso al estado con seguimiento Sí 1.0

Simultaneidad optimista Sí 1.0

Procesamiento de instrucciones por 1.0

Asignación de procedimientos Sí En el trabajo pendiente (n.º 245)

Grafo desconectado: API de bajo nivel Insuficiente 1.0

Grafo desconectado: de un extremo a 1.0 (parcial; n.º 5536)

API de creación o eliminación de la base Sí 1.0

Datos de inicialización Sí 2.1

Resistencia de conexión Sí 1.1

Events Sí 3.0 (parcial; n.º 626)

Registro simple (Database.Log) Sí Combinado para la versión 5.0

Agrupación de DbContext 2.0

Proveedores de bases de datos (3)