¿Cuál es el sentido de crear propiedades de clave externa cuando se usa primero el código de Entity Framework?

Question

Al mirar las preguntas y respuestas en este sitio y leer algunos de los mejores tutoriales clasificados por Google en primer lugar el desarrollo Código frecuencia veo el siguiente patrón ...

public class Category 
{ 
    public Category() 
    { 
     Products = new Collection<Product>(); 
    } 
    public Guid ID { get; set; } 
    public string Name { get; set; } 
    public virtual ICollection<Product> Products { get; set; } 
} 

public class Product 
{ 
    public Guid ID { get; set; } 
    public string Name { get; set; } 
    public DateTime DateAdded { get; set; } 
    public Guid CategoryID { get; set; } // Seemingly redundant property 
    public virtual Category Category { get; set; } 
} 

Durante la búsqueda de tutoriales Código Primero los dos siguientes páginas vienen que el uso de este mismo patrón:

http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity-framework-4.aspx

http://www.codeproject.com/Articles/327945/Architecture-Guide-ASP-NET-MVC3-Entity-Framework-C

Pregunta: Entonces, ¿qué sentido tiene tener la propiedad de clave foránea en el objeto Code First C#? En el ejemplo anterior puede omitir CategoryID de la clase Product y todo funcionará perfectamente. La clave externa Category_ID se seguirá creando en la base de datos.

Lo único que podía pensar es que las personas les gustaría ser capaz de especificar si la relación es opcional el uso de tipos anulables en lugar de la API fluida, pero creo que realmente confunde las cosas a tener tanto una propiedad Category y CategoryID .

Así que antes de ir y eliminar todas mis propiedades de clave foránea, ¿hay algo que me falta aquí? ¿De qué sirve hacer esto?

Gracias!

Answer 1

Sí, creo que no hay necesidad de propiedades de clave externa y de alguna manera son un artefacto relacional en el mundo de los objetos. Puede definir relaciones completamente sin propiedades FK. En Fluent API puede definir si la relación es opcional o obligatoria y puede especificar el nombre de la columna de la clave externa de la tabla de la base de datos. La relación se llama entonces Asociación independiente.

Mi comprensión es que Asociaciones de claves foráneas - relaciones con las propiedades de claves externas expuestas en su clase de modelo - solo existe para hacer que trabajar con relaciones en Entity Framework sea más fácil y más cómodo en ciertos escenarios. Por ejemplo:

Supongamos que tiene una vista web para crear o editar un producto y la vista contiene un cuadro combinado para seleccionar una categoría y asignarla al producto. Para completar el cuadro combinado cuando se visualice la vista, cargará, por ejemplo, el ID y el Name de todas las categorías de la base de datos.

Cuando la página se publique nuevamente recibiría las propiedades del producto y el ID de la categoría seleccionada. Si usted no tiene una propiedad clave externa CategoryID en su Product que tendría que crear la relación de esta manera:

var category = new Category { ID = IDFromComboBox }; 
context.Categories.Attach(category); 
product.Category = category; 

Con una propiedad FK sólo necesita una línea:

product.CategoryID = IDFromComboBox; 

Clave externa las propiedades no existían en Entity Framework versión 1 (.NET 3.5) y se han introducido con EF versión 4 (.NET 4) para admitir mejor escenarios como el anterior.

Una visión crítica sobre la asociación de clave externa se puede encontrar y la diferencia entre los dos tipos de asociaciones está muy bien discutido en el blog de Ladislav:

http://www.ladislavmrnka.com/2011/05/foreign-key-vs-independent-associations-in-ef-4/