EF Code First: Treating entity like a complex type (denormalization)

I'm using EF 4.1 Code First, and I'm making a configurable utility for parsing/importing large delimited files. Each row in the file may contain data for several entities.

The exact data and layout for the file will be unknown at build time (it's configured differently for each client), so I'm making it configurable.

Example model (simplified)

public class Contact {
    public int Id { get; set;}
    public string Name { get; set; }
}

public class Account {
    public int Id { get; set; }
    public decimal Balance { get; set; }
    public bool IsOpen { get; set; }
}

Depending on the client, a file may contain contact info, account info, or both. Because of the size of these files (tons of records), we have to use SqlBulkCopy to do the data loading. It's also unknown at compile time exactly what rules will be run against the data (validation changes by client, etc.)

I want to have a table and class, like ImportRecord, to hold the imported data. My current working class is like:

public class ImportRecord {
    public string Contact_Name { get; set; }
    public decimal Account_Balance { get; set; }
    public bool Account_IsOpen { get; set; }
}

The issue here is that as we add/change fields in the model classes, the ImportRecord has to get changed also -- it's duplicative/less than ideal. It's somewhat important to me that the import data resides in a single table to simplify the SqlBulkCopy import.

My ideal ImportRecord class would look like this:

public class ImportRecord {
    public Contact Contact { get; set; }
    public Account Account { get; set; }
}

But that would just create a table with two foreign keys (aside from complaining about no FK properties). Is ther开发者_StackOverflowe a way to have the entity classes behave more like a denormalized, keyless, complex type for the ImportRecord? Am I going about this entirely wrong?

Thanks!

Entity cannot be nested and in the same time complex type cannot have entity key so you cannot use one instead of other but you can try this little cheat. I just tested that it at least creates correct database structure:

public class Context : DbContext
{
    public DbSet<Account> Accounts { get; set; }
    public DbSet<Contact> Contacts { get; set; }
    public DbSet<ImportRecord> ImportRecords { get; set; }

    protected override void OnModelCreating(DbModelBuilder modelBuilder)
    {
        base.OnModelCreating(modelBuilder);

        modelBuilder.ComplexType<ContactBase>();
        modelBuilder.ComplexType<AccountBase>();
    }
}

public class ContactBase
{
    public string Name { get; set; }
}

public class AccountBase
{
    public decimal Balance { get; set; }
    public bool IsOpen { get; set; }
}

public class Contact : ContactBase
{
    public int Id { get; set; }
}

public class Account : AccountBase
{
    public int Id { get; set; }
}

public class ImportRecord
{
    public int Id { get; set; }
    public ContactBase Contact { get; set; }
    public AccountBase Account { get; set; }
}