typeparam example c# entity-framework-4 entity-framework-5

example - params comments c#



¿Qué son las asociaciones independientes y las asociaciones de clave extranjera? (2)

Posible duplicado:
Código Primero: ¿Asociaciones independientes vs. asociaciones de clave extranjera?

En el Código EF 4 o EF 5 Primero, ¿qué es una "asociación independiente" y qué es una "asociación de clave externa", como se usa en MSDN o la clave externa frente a relaciones independientes? (énfasis añadido):

2.4.1 Uso de asociaciones de clave externa para reducir el costo de generación de vistas

Hemos visto varios casos en los que cambiar las asociaciones en el modelo de Asociaciones Independientes a Asociaciones de Clave Extranjera mejoró dramáticamente el tiempo empleado en la generación de vistas.

Entonces, ahora sé qué usar. ¡Ojalá supiera qué eran y cómo se convertirían a él! Mi pregunta, entonces, es, ¿cómo definirías esos términos? ¿Qué fluidez / anotaciones / convenciones invocan cada uno?


Asociación de clave externa es donde tiene una propiedad de clave externa en su modelo además de la propiedad de navegación correspondiente. Asociación independiente es cuando tiene una columna de clave externa en su base de datos, pero la propiedad de clave externa correspondiente a esta columna no está en su modelo, es decir, tiene una propiedad de navegación pero no hay ninguna propiedad de clave externa que le indique cuál es el valor de ID del propiedad relacionada es sin ir realmente a la propiedad relacionada.

Este es un ejemplo de un modelo con una asociación independiente (aviso que el dependiente no tiene una clave externa, solo propiedad de navegación):

public class Dependent { public int Id { get; set; } [Required] public Principal PrincipalEntity { get; set; } } public class Principal { public int Id { get; set; } public ICollection<Dependent> DependentEntities { get; set; } } public class MyContext : DbContext { public DbSet<Dependent> Dependents { get; set; } public DbSet<Principal> Principals { get; set; } }

Y aquí hay un ejemplo del mismo modelo pero con la Asociación ForeignKey (observe la propiedad PrincipalEntity_Id y el atributo [ForeignKey ()]):

public class Dependent { public int Id { get; set; } public int PrincipalEntity_Id { get; set; } [Required] [ForeignKey("PrincipalEntity_Id")] public Principal PrincipalEntity { get; set; } } public class Principal { public int Id { get; set; } public ICollection<Dependent> DependentEntities { get; set; } } public class MyContext : DbContext { public DbSet<Dependent> Dependents { get; set; } public DbSet<Principal> Principals { get; set; } }

Tenga en cuenta que su base de datos no cambiará: la base de datos subyacente siempre tenía la columna para la clave externa, pero con la asociación independiente no estaba expuesta.

Con las asociaciones de clave externa puede actualizar la relación simplemente cambiando el valor de la clave externa. Esto es útil si conoce el valor porque no necesita cargar la entidad a la que desea actualizar la propiedad de navegación.


Solo mis opiniones acerca de POR QUÉ usar asociaciones de claves independientes o extranjeras:

Asociaciones independientes

Pros:

  • Esta es la forma correcta de ir en el mundo orientado a objetos. En el mundo orientado a objetos, estamos utilizando referencias dentro de nuestros agregados, no algunas claves mágicas.

Contras:

  • Con POCO puro, no sabe si la relación principal es realmente NULA o simplemente no está cargada porque en ambos casos su referencia es nula. Debes pedirle al contexto que difiera entre esos dos nulos. Esto no fue un problema con las entidades base de EntityObject pesadas en las que cada propiedad de navegación a entidad principal se emparejó con otra propiedad con el sufijo Reference proporciona algunos detalles adicionales sobre la relación.
  • La forma de gestionar asociaciones independientes de EF es bastante compleja, especialmente cuando se trata de adjuntar gráficos de objetos separados. Cada asociación independiente tiene su propio estado y nunca puede estar en estado Modified . Cada modificación siempre consiste en establecer una relación antigua como eliminada y crear una nueva relación como se agrega - esto es un verdadero lío cuando intentas usarla.
  • Se informó que las asociaciones independientes ralentizan significativamente la generación de vistas durante la inicialización de EF (o durante la pregeneración de vistas).
  • La asociación independiente puede ser mucho más difícil de usar en escenarios de enlace de datos en los que necesita enlazar solo una clave externa.

Asociaciones de clave extranjera

Pros:

  • Sencillo. Las propiedades clave son fáciles de administrar y resuelven todos los problemas con asociaciones independientes: sin estado para asociaciones extranjeras, enlace directo de datos, visibilidad inmediata si la relación existe (la clave no es nula), etc.

Contras:

  • Conceptualmente están equivocados y ofrecerlos en EF fue un gran paso atrás del mundo objeto al mundo relacional. Todavía creo que la solución correcta estaba mejorando o cambiando la forma en que se manejan las asociaciones independientes, incluso si esto pudiera causar enormes cambios de ruptura entre EFv1 y EFv4. Tampoco me gusta la situación actual en la que tenemos dos tipos de asociaciones con comportamientos completamente diferentes. Solo debe haber un tipo con comportamiento bien definido y propiedades opcionales de clave externa expuestas en la entidad.

Esta diferencia solo importa para asociaciones de uno a muchos, porque uno a uno siempre son asociaciones de clave externa y muchos a muchos son siempre asociaciones independientes.