Este artículo proviene de un motor de traducción automática.

Puntos de datos

Vista previa de Entity Framework: código primero, ObjectSet y DbContext

Julie Lerman

Mientras el Entity Framework (EF) 4 aún estaba en versión beta, el equipo de desarrollo comenzaron a trabajar en otra forma de utilizarlo. Tuvimos la primera función de base de datos - primera forma de crear un modelo (de forma inversa de una base de datos de ingeniería en un modelo de datos de entidad) y el nuevo modelo de 4 EF-(definir un modelo de datos de entidades, a continuación, crear la base de datos a partir de él). Además, el equipo decide crear un elemento denominado “ código primero. ”

Con el código comience con el código, no a la base de datos, no del modelo. De hecho, con el código en primer lugar hay ningún modelo visual y no hay XML que describe ese modelo. Simplemente cree las clases para el dominio de aplicación y el código en primer lugar que les permitirá participar en EF. Puede utilizar un contexto, escribir y ejecutar LINQ a las consultas de entidades y aprovechar las ventajas de control de cambios EF. Pero no es necesario para tratar con un modelo en un diseñador. Al no generar aplicaciones altamente diseñadas, casi puede olvidar que EF aún existe, es toda la interacción de la base de datos y el seguimiento de cambios controla automáticamente.

Ventiladores de desarrollo controlado por dominio (DDD) parecen encanta código primero. De hecho, era un número de los Gurús de DDD que ayudó al equipo EF comprender qué código podía hacer en primer lugar para los programadores DDD. Consulte de blog ’ Danny Simmons acerca del Consejo consultivo de programabilidad de datos para obtener más información acerca de ese ( blogs.msdn.com/b/dsimmons/archive/2008/06/03/dp-advisory-council.aspx ).

Pero el código en primer lugar no estaba preparado para su inclusión en el 4 de Microsoft .NET Framework y Visual Studio de 2010. De hecho, aún está evolucionando y Microsoft está ofreciendo a los programadores acceso a los bits para jugar con y proporcionar información a través de la CTP de Entity Framework Feature (CTP del Feature EF). La cuarta iteración de esta comunidad de vista previa de tecnología (CTP4) se publicó en de 2010 de mediados de julio. Los cambios en esta iteración eran significativos.

Así como incluir el ensamblado de código a la primera en la versión CTP4, Microsoft ha trabajado en algunas buenas ideas nuevas para la siguiente iteración del EF. Los que también se incluyen en el CTP4 para que las personas puedan reproducir con ellos y, a, proporcionar comentarios. Lo que es más importante, código primero aprovecha algunas de estas nuevas características.

Puede encontrar una serie de tutoriales detallados en esta CTP en entradas de blog del equipo de EF (tinyurl.com/297xm3jde ), Scott Guthrie (tinyurl.com/29r3qkb ) y Scott Hanselman (tinyurl.com/253dl2g ).

En esta columna, que desea centrarse en algunas de las características específicas y las mejoras en la versión CTP4 de que han generado una cantidad increíble de moda alrededor EF porque simplifican el desarrollo con EF: y .NET Framework en general, por lo tanto, en gran medida.

Mejoras de API de núcleo

Una de las mejoras notables que la versión CTP4 se agrega al tiempo de ejecución EF es una versión ligera de dos clases de base, ObjectContext y ObjectSet. ObjectContext permite consultar, control de cambios y guardar en la base de datos. ObjectSet encapsula los conjuntos de objetos similares.

Las nuevas clases, DbContext y DbSet, tienen las mismas funciones esenciales, pero no exponen al conjunto de características completo de ObjectContext y ObjectSet. No cada escenario de codificación exige el acceso a todas las características de las clases más robustas. DbContext y DbSet no derivadas de ObjectContext y ObjectSet pero DbContext proporciona fácil acceso a la versión completa a través de una propiedad: DbContext.ObjectContext.

Conceptos básicos de ObjectSet y la DbSet simplificado

Un ObjectSet es una representación de tipo de colección genérica de un conjunto de tipos de entidad. Por ejemplo, puede hacer que un ObjectSet <Customer>llama a los clientes que es una propiedad de una clase de contexto. LINQ to Entities se escriben consultas contra ObjectSets. Ésta es una consulta contra la ObjectSet de clientes:

from customer in context.Customers 
where customer.LastName=="Lerman" 
select customer

ObjectSet tiene un constructor interno y no tiene un constructor sin parámetros. La forma de crear un ObjectSet es a través del método ObjectContext.CreateObjectSet. En una clase de contexto típico, la propiedad de los clientes se definirá como:

public ObjectSet< Customer> Customers {
  get { 
    return _ customers??
(_customers = 
      CreateObjectSet< Customer >(" Customers"));
  }
}

private ObjectSet< Customer > _ customers;

Ahora puede escribir consultas con respecto a los clientes y manipular el conjunto, agregando, asociar y eliminación de objetos según sea necesario.

DbSet es mucho más fácil trabajar con. DbSet no está públicamente construirse (similar a ObjectSet) pero se DbSets crear de forma automática y asignarlos a las propiedades (con establecedores públicas) se declara en su DbContext derivada.

Los métodos de colección ObjectSet están orientados a la terminología EF: AddObject, asociar y DeleteObject (EliminarObjeto):

context.Customers.AddObject(myCust)

DbSet simplemente utiliza Agregar, conectar y Remove, que es mucho más en consonancia con otros nombres de métodos de colección, por lo que no tiene que dedicar tiempo a averiguar “ cómo quiere decir en EF, ” de este modo:

context.Customers.Add(MyCust)

El uso del método Remove, en lugar de DeleteObject (EliminarObjeto) también más claramente describe lo que hace el método. Quita un elemento de una colección. DeleteObject (EliminarObjeto) sugiere que se eliminarán los datos de la base de datos que ha provocado la confusión para muchos desarrolladores.

Sin duda Mi característica favorita de DbSet es que le permite trabajar más fácilmente con los tipos derivados. ObjectSet ajusta los tipos base y todos los tipos que heredan de él. Si dispone de una entidad base, el contacto y una entidad de cliente que se deriva de ella, cada vez que desee trabajar con los clientes, tendrá que iniciar con el ObjectSet de contactos. Por ejemplo, para una consulta para los clientes, escriba context.Contacts.OfType <Customer>. No sólo es confusa, que no lo es también fácilmente reconocible. DbSet le permite ajustar los tipos derivados, por lo tanto, ahora puede crear una propiedad Customers que devuelve DbSet <Customer>y permite interacción con el directamente en lugar de hacerlo a través del conjunto de contactos.

DbContext: un contexto optimizado

DbContext expone las funciones más utilizadas de ObjectContext y proporciona algunas de las adicionales que son realmente útiles. Mis características favoritas de dos hasta el momento de DbContext son la propiedad Set genérica y el método OnModelCreating.

Todos esos ObjectSets he mencionado hasta ahora son propiedades explícitas de una instancia de ObjectContext. Por ejemplo, supongamos que tiene un modelo denominado PatientHistory que tiene tres entidades en él: Paciente, direcciones y OfficeVisit. Tiene una clase, PatientHistoryEntities, que se hereda de ObjectContext. Esta clase contiene una propiedad de pacientes que es un ObjectSet <Patient>al igual que una propiedad de direcciones y una propiedad OfficeVisits. Si desea escribir código dinámico utilizando los componentes genéricos, se debe llamar a context.CreateObjectSet <T>donde T es uno de los tipos de entidad. De nuevo, pero no es reconocible.

DbContext tiene un método más sencillo que se llama a SET que le permite llamar simplemente context.Set <T>, que devolverá una DbSet <T>. Es sólo es posible que sea igual a 12 menos letras, pero para el cerebro de codificación, mediante la propiedad es correcta, mientras que una llamada a un método de fábrica no. También puede utilizar entidades derivadas con esta propiedad.

Otro miembro DbContext es OnModelCreating, lo que resulta útil en el código en primer lugar. Ninguna configuración adicional que desee aplicar a su modelo de dominio se puede definir en OnModelCreating justo antes de que la EF genera los metadatos de la memoria en función de las clases de dominio. Esto supone una mejora importante en primer lugar a través de las versiones anteriores de código. Podrá ver más información al respecto en.

Código primero se obtiene de forma inteligente y más fácil

Código en primer lugar se primero presenta a los desarrolladores como parte de la CTP1 Feature EF en junio de 2009 con el nombre “ código sólo. ” La premisa básica detrás de esta variación del uso de EF era que los desarrolladores simplemente desean definir las clases de sus dominio y no preocuparse por un modelo físico. Sin embargo, el tiempo de ejecución EF depende XML del modelo para convertir las consultas en función del modelo en las consultas de base de datos y, a continuación, de seguridad de los resultados de la base de datos en objetos que se describen mediante el modelo. Sin esos metadatos, EF no puede realizar su trabajo. Pero los metadatos no tiene que estar en un archivo físico. EF lee esos archivos XML una vez durante el proceso de aplicación, crea los objetos de metadatos con establecimiento inflexible de tipos en función de ese código XML y, a continuación, lleva a cabo esa interacción con el XML en memoria.

Código primero crea objetos de metadatos de la memoria, demasiado. Pero, en lugar de crearlo mediante la lectura de archivos XML, deduce los metadatos de las clases de dominio (consulte de figura 1). Se utiliza la convención para realizar esta operación y, a continuación, se proporciona un medio por el que se pueden agregar parámetros de configuración adicionales para restringir aún más el modelo.

La figura 1 de código crea primero los metadatos de Entity Data Model en tiempo de ejecución

En primer lugar, otro trabajo importante de código es utilizar los metadatos para crear un esquema de base de datos y aún la base de datos. Código primero ofrece estas funciones desde su primera versión pública.

Éste es un ejemplo de la que tiene una configuración para superar algunas suposiciones no válidas. Hay una clase denominada ConferenceTrack con una propiedad de identidad denominada TrackId. Convención código primero busca “ ID ” o nombre de la clase + “ ID ” como una propiedad de identidad que se utilizará para EntityKey la entidad y clave principal de la tabla de base de datos. Pero TrackId no cabe en este modelo, por lo que se tiene que indicar a EF que se trata de la clave de identidad.

La nueva clase de código de primera ModelBuilder basa el modelo de la memoria en función de las clases que se ha descrito anteriormente. Puede definir aún más las configuraciones que utilizan ModelBuilder. Soy capaz de especificar que la entidad ConferenceTrack debe utilizar su propiedad TrackId como su clave con la configuración de ModelBuilder siguiente:

modelBuilder.Entity<ConferenceTrack>().HasKey(
  ct => ct.TrackId);

ModelBuilder ahora tendrán en cuenta esta información adicional, como es crear el modelo de memoria y trabajar con el esquema de base de datos.

Aplicar las configuraciones más lógicamente

Aquí es donde DbContext.OnModelCreating entra tan bien. Puede colocar las configuraciones de este método para que se va aplicar como el modelo se ha creado mediante el DbContext:

protected override void OnModelCreating(
  ModelBuilder modelBuilder) { 
  modelBuilder.Entity<ConferenceTrack>().HasKey(
    ct => ct.TrackId); 
}

Otra característica nueva que se agregó en el CTP4 es otra forma de aplicar configuraciones a través de atributos en las clases. Esta técnica se denomina las anotaciones de los datos. Puede lograr la misma configuración mediante la aplicación de la anotación key directamente a la propiedad TrackId en la clase ConferenceTrack:

[Key] 
public int TrackId { get; set; }

Sin duda el más simple, sin embargo, mi preferencia personal consiste en utilizar las configuraciones de programación para que las clases no es necesario tener conocimientos específicos de EF en ellos.

Este enfoque también significa que DbContext se encargará de almacenamiento en caché el modelo para construir más DbContexts no incurre costo de descubrimiento del modelo de nuevo.

Las relaciones de Get es más fácil

Una de las mejoras más importantes para el código en primer lugar es es mucho más inteligente sobre la realización de las suposiciones de las clases. Aunque hay muchas mejoras en las siguientes convenciones, encuentro las convenciones de mejora de la relación que han afectado a mi código el máximo rendimiento.

Aunque las relaciones se definen en las clases, en la CTP anterior era necesario proporcionar información de configuración para definir estas relaciones en el modelo. Además, las configuraciones eran bastante ni lógico. Ahora código primero puede interpretar correctamente la intención de la mayor parte de relaciones definidas en clases. En el que necesite ajustar el modelo con algunas configuraciones de los casos, la sintaxis es mucho más sencilla.

Las clases de Mis dominio tienen un número de relaciones definidas mediante las propiedades. Por ejemplo, el ConferenceTrack tiene esta relación de uno a varios:

public ICollection<Session> Sessions { get; set; }

Sesión tiene la relación de lo contrario, así como varios a varios:

public ConferenceTrack ConferenceTrack { get; set; }
public ICollection<Speaker> Speakers { get; set; }

Utilizar mis clases y una única configuración (para definir la TrackId como clave para las conferencias), el generador de modelos, crea la base de datos con todas las relaciones y se muestra en del 2 de la figura de herencias.

La figura 2 del creado por la creación del modelo de estructura de base de datos

Tenga en cuenta en la tabla Sessions_Speakers creada para la relación de varios a varios. Mi dominio dispone de una clase de taller que hereda de la sesión. De forma predeterminada, código primero supone tabla por jerarquía herencia, por tanto, crea una columna del discriminador en la tabla de sesiones. Para cambiar su nombre a IsWorkshop o incluso para especificar que debe crear una tabla por tipo de herencia en su lugar, se puede utilizar una configuración.

Cantidad a adelantar planear las siguientes funciones nuevas

Estas nuevas características que se tiene acceso anticipado a en la versión CTP4 de atractivas pueden ser una fuente de frustración para los desarrolladores que dicen “ deseado ahora! ” Es cierto que esto es sólo una vista previa y no se puede ponerlo en producción hoy en día, pero sin duda, jugar con estos bits si podemos y proporcionar sus comentarios al equipo de EF para ayudar a que sea aún mejor. Para comenzar a planear con antelación cómo utilizará código en primer lugar y otras EF características nuevas en las aplicaciones futuras.

Julie Lerman is a Microsoft MVP, .NET mentor and consultant who lives in the hills of Vermont. Puede encontrar su presentación en el acceso a datos y otros temas de Microsoft .NET a grupos de usuarios y conferencias de todo el mundo. Blogs de Lerman en thedatafarm.com/blog de y es el autor del libro muy aclamado “ Programming Entity Framework ” (O’Reilly Media, 2009). Siga a ella en Twitter.com: julielermande .

Gracias al siguiente experto técnico para este artículo: Rowan Miller