Your model is a bit weird for the business logic you describe. If an Event
can have many EventDates
you should not have a foreign key in Event
that refers to EventDate
, but the other way around: A foreign key in EventDate
that refers to Event
and possibly also a navigation property Event
in EventDate
:
[Table("EventDates")]
public class EventDate
{
public int EventDateId { get; set; }
public int EventId { get; set; }
[ForeignKey("EventId")]
public Event Event { get; set; }
public DateTime EventDateStart { get; set; }
public DateTime? EventEnd { get; set; }
public string TicketPurchaseUrl { get; set; }
}
[Table("Events")]
public class Event
{
public int EventId { get; set; }
public virtual ICollection<EventDate> EventDates { get; set; }
}
By convention EventDate.EventDateId
and Event.EventId
will be the keys and they will be autogenerated. I suggest that you save yourself the trouble of having a DateTime
as part of a composite key in EventDate
. If you do not really need such a composite key keep it simple with just an int
identity as key.