CODEWITHSUNDEEP
ef-code-firstentity-framework-5code-first
Kirsten
Kirsten

Reputation: 18188

Is it OK to declare a DBSet in the context for both a base table and a derived table?

I have a SalesOrder table which inherits from a SalesDocument table using Table Per Type Inheritance

The ( simplified) table classes are;

[Table("SalesDocumentHeaders")]
public abstract class SalesDocumentHeader  
{
[ForeignKey("CreatedByUserId")]
public virtual User CreatedBy { get; set; }

[Required]
public int CreatedByUserId { get; set; }

[Required]
public virtual DateTime? DocumentDate { get; set; }

[Required]
public String ReferenceNumber { get; set; }

} 

[Table("SalesOrders")]
public class SalesOrder : SalesDocumentHeader
{
[Required]
public String CustomerOrderNumber { get; set; }

public DateTime? DeliverBy { get; set; }

public virtual SortableBindingList<SalesOrderLine> Lines { get; set; }

}

The context contains

public DbSet<SalesOrder> SalesOrders { get; set; }

public DbSet<SalesDocumentHeader> SalesDocumentHeaders { get; set; }

It doesn't strictly need the SalesOrders DBSet, since SalesOrder inherits from SalesDocumentHeader however I find it convenient.

It seems to work OK, but I am worried that there are 2 ways of reaching the same record , am I doing something wrong?

Upvotes: 0

Views: 174

Answers (1)

Gildor
Gildor

Reputation: 2574

Usually you only need to keep the DBSet for the base table. This helps when you have multiple derived tables (call them A and B) and you need to decide the actual type dynamically.

For example if you have another entity which references type A or B (like a user can have different types of contact information), you can reference the base table and EF will resolve the correct concrete type at runtime. Though of course this adds some extra casting code.

Upvotes: 1

Related Questions