Question

I have a database, and I have entity POCO’s, and all I want to use EF for is to map between the two and keep track of changes for loading, saving, etc.

I have been reading a lot of the literature (such as it is) on “Code First”, and I am unclear on how much of the database information I need to supply when there is not going to be a database generated.

For example, does EF need to know which properties are keys, the maximum length of string properties, the relationships between the tables, etc.? Or if it does need to know, can it get that information from the database itself? In other words, do I have to provide [Key] annotations and such, or provide configuration information detailing the foreign-key relationships, if no database needs to be created?

UPDATE: To make things a little clearer, the following code is what I am talking about. I have to manually create this class derived from DbContext. I could supply a lot of DB information about the properties in OnModelCreating, or in attributes attached to the properties in the entity classes.

    public class SchedulerContext : DbContext
    {
    public SchedulerContext(EntityConnection connection)
        : base(connection)
    {
    }

    public DbSet<Client> Clients { get; set; }
    public DbSet<ConsultantDistrict> ConsultantDistricts { get; set; }
    public DbSet<ConsultantInterviewSetting> ConsultantInterviewSettings { get; set; }
    public DbSet<ConsultantUnavailable> ConsultantsUnavailable { get; set; }
    public DbSet<CustomEmailTemplate> CustomEmailTemplates { get; set; }
    public DbSet<DateEvent> DateEvents { get; set; }
    public DbSet<Event> Events { get; set; }
    public DbSet<EventItem> EventItems { get; set; }
    public DbSet<EventItemUserViewed> EventItemsUserViewed { get; set; }
    public DbSet<FlaggedDate> FlaggedDates { get; set; }
    public DbSet<Interview> Interviews { get; set; }
    public DbSet<Interviewee> Interviewees { get; set; }
    public DbSet<IntervieweeNote> IntervieweeNotes { get; set; }
    public DbSet<InterviewEvent> InterviewEvents { get; set; }
    public DbSet<NotificationSent> NotificationsSent { get; set; }
    public DbSet<SchedulerRole> SchedulerRoles { get; set; }
    public DbSet<SiteEvent> SiteEvents { get; set; }
    public DbSet<UnavailableHour> UnavailableHours { get; set; }
    public DbSet<UserLogin> UserLogins { get; set; }
    public DbSet<UserSites> UserSites { get; set; }
    public DbSet<Visit> Visits { get; set; }

    protected override void OnModelCreating(System.Data.Entity.ModelConfiguration.ModelBuilder modelBuilder)
    {
        base.OnModelCreating(modelBuilder);

        modelBuilder.Entity<ConsultantUnavailable>().MapSingleType().ToTable("ConsultantsUnavailable");
        modelBuilder.Entity<EventItemUserViewed>().MapSingleType().ToTable("EventItemsUserViewed");
    }
}

Answer 1

Yes, the EF does need information on string field lengths, foreign keys, etc., in the model. For example, if a DB FK has a cascade, the EF needs to know that so that it doesn’t force you to manually delete detail records; if the EF is aware of the cascade it will let the DB handle that. Similarly, if the EF is aware that a key is store-generated (e.g., auto-incremented), it won’t complain when you don’t set it on a new record, because it will presume that the DB will do that.

However, the code-only approach takes a “convention over configuration” approach. You don’t have to specify values which the EF can guess. You can read about those here.

If you are doing Code Only, the EF doesn’t look at the DB at all when creating the model.

There is no way to tell the EF to look at code and the DB to create the model. You have to choose one or the other.