.net - programacion - Código EF4 primero: definición de relaciones de objetos, claves externas

agregacion y composicion en java

Question

<RANT_MODE>

El enfoque del código EF primero está destinado a ahorrar mucho tiempo, pero por el momento solo he visto ejemplos de juguetes y pasé horas tratando de comprender cómo puedo hacer que genere la db que quiero. Pero todavía espero que el momento Eureka :-)

<RANT_MODE />

¡A las preguntas!

Propiedades virtuales vs. concretas.

Estoy tratando de entender cómo EF mapea y recupera relaciones de objetos. ¿Cuándo debo marcar una propiedad como virtual y cuándo no? (Al igual que en public Person Owner { get; set; } vs. public virtual Person Owner { get; set; } .) En las docenas de ejemplos de código primero, he visto que parecen usarlos de manera intercambiable, sin mucho en términos de explicacion Lo que sí sé es que las propiedades de navegación ( public virtual ICollection<Person> Owners { get; set; } ) necesitan ser virtual para hacer posible la carga perezosa (¿correcto ...?), Pero ¿cómo se aplica eso en el mundo de no colecciones?

Relaciones de objetos y claves externas.

No pude encontrar ninguna información sobre si debería incluir un campo de clave foránea ( public int OwnerId { get; set; } ) además de la propiedad "principal" en la que estoy interesado ( public Person Owner { get; set; } ). Intenté no hacerlo, y EF amablemente agregó automáticamente una columna int denominada Owner_Id en mi tabla, al parecer entendiendo lo que quería lograr.

En Convenciones para el Código Primero (sección ''Claves Foráneas'') el Equipo EF menciona que "es común incluir una propiedad de clave extranjera en el extremo dependiente de una relación", y que el "Código Primero ahora inferirá que cualquier propiedad denominada '''' (es decir, OwnerId) [...] con el mismo tipo de datos que la clave principal, representa una clave externa para la relación ". Es decir. Si tengo ambos, EF sabrá que están relacionados.

Pero, ¿se considera una buena práctica especificar explícitamente las propiedades que tienen FK, además de los "objetos extraños"?

Objetos extraños, llaves foráneas - continuación

Como mencioné anteriormente, incluso si solo tengo public Person Owner { get; set; } public Person Owner { get; set; } public Person Owner { get; set; } en mi objeto (digamos Event ), la tabla Events contará con una columna Owner_Id agregada Owner_Id por EF. Además, al recuperarlo, tendré acceso a las propiedades del Owner .

Sin embargo, considere el siguiente escenario. Tengo dos clases:

public class Account
{
public int Id { get; set; }
public Person Owner { get; set; }
}
public class OpenIdAccount : Account
{
public string Identifier { get; set; }
}

Quiero que estén relacionados con TPT. Esto significa mapeo manual:

modelBuilder.Entity<Account>().MapHierarchy(a => new
{
a.Id,
Owner_Id = a.Owner.Id
}).ToTable("Account");
modelBuilder.Entity<OpenIdAccount>().MapHierarchy(a => new
{
a.Id,
a.Identifier
}).ToTable("OpenIdAccount");

Como puede observar, intenté recrear lo que EF hace con mi columna Owner_Id . Sin embargo, en la recuperación, myAccountInstanceFromDb.Owner es nulo. ¿Porqué es eso? ¿Cómo le digo a EF que debe hacer su magia y llenar mi propiedad de Owner ?

Punteros, punteros

Estaré muy agradecido si pudiera aclarar lo anterior; llegó al punto de realmente desear conocer las respuestas, pero no poder leer otro artículo que simplemente muestra otro ejemplo de juguete de lo fácil que es jugar con EF. Dicho esto, si tiene una referencia actualizada y detallada sobre los cerebros de EF, por favor, publique enlaces también.

¡Gracias de antemano por su tiempo!

Answer 1

Propiedades virtuales vs. finales:

Esto realmente no tiene nada que ver con el código primero, es el tema de EF y POCO: cuando tienes POCO, pierdes un montón de soportes de EF para tus propiedades de navegación y puedes optar a ellos haciéndolos virtuales. Esto le permite a EF hacer un proxy en tiempo de ejecución y brindarle soporte al anular las propiedades de navegación en esa clase de proxy. Esos soportes son la notificación de cambios , la reparación de relaciones y la carga diferida .

La carga diferida funciona de la misma forma para las propiedades de navegación de colección y no de tipo Colección. También se considera una buena práctica marcar siempre las propiedades de navegación como virtuales.

Asociación de llave extranjera o asociaciones independientes

EF3.5 no admite FK en las asociaciones y las hace ocultas (también conocidas como Asociaciones Independientes ). EF4 comienza a admitir FK en las asociaciones (también conocida como Asociación de clave externa ). Dependiendo de cuál le guste, puede incluir o no incluir explícitamente las propiedades de FK, pero definitivamente es una buena práctica especificar explícitamente las propiedades de FK, además de las propiedades de navegación, ya que le brinda la máxima flexibilidad para trabajar con sus objetos.

Tras la recuperación, myAccountInstanceFromDb.Owner es nulo. ¿Porqué es eso? ¿Cómo le digo a EF que debe hacer su magia y llenar mi propiedad de propietario?

Por supuesto, no lo marcó como virtual, por lo que no se admite la carga diferida, pero no se cargó ni se aplazó explícitamente. Para resolver eso, use una palabra clave virtual y deje que EF lo cargue por usted o use el método Include para cargarlo con entusiasmo en el momento en que se materialice todo el objeto.

Propiedades escalares vs. propiedades de navegación

Las propiedades escalares son propiedades cuyos valores están contenidos literalmente en la entidad y se corresponden con las columnas de la tabla (por ejemplo, Account.Id).
Las propiedades de navegación son meramente punteros a las entidades relacionadas. Por ejemplo, la entidad de Cuenta tiene una propiedad de Propietario que permitirá a la aplicación navegar desde una Cuenta al Propietario que posee esa Cuenta.
Así que, volviendo a su pregunta, todo lo que necesita hacer es especificar una propiedad de navegación como virtual Person Owner y, opcionalmente, especificar una propiedad FK como int OwnerId y int OwnerId listo.

Answer 2

Marcar una propiedad virtual hace que los objetos relacionados sean perezosos.

no es necesario agregar un campo de clave foránea público Persona Propietario {obtener; conjunto; } agregará una asignación de clave externa