Question

I have a class with a relationship to another table.

public class MyClass
{
    [Key]
    public Guid Id {get; set; }

    public virtual OtherClass OtherClass { get; set; }
}

I hook this up to a controller and create views for CRUD – all works fine.

In the DB a OtherClass_OtherClassId column is created, but this is not in the model.

How can I put a reference in this Id column during the controller’s Create method?

How can I force this relationship to be [Required] without having to create a brand new OtherClass each time?

Answer 1

Annotated class with some description:

public class MyClass
{
    // [Key] - Don't actually need this attribute
    // EF Code First has a number of conventions.
    // Columns called "Id" are assumed to be the Key.
    public Guid Id {get; set; }

    // This reference creates an 'Independent Association'.  The Database
    // foreign key is created by convention and hidden away in the code.
    [Required]
    public virtual OtherClass OtherClass { get; set; }

    // This setup explicitly declares the foreign key property.
    // Again, by convention, EF assumes that "FooId" will be the key for
    // a reference to object "Foo"

    // This will still be required and a cascade-on-delete property
    // like above - an int? would make the association optional.
    public int OtherClass2Id { get; set; }

    // Leave the navigation property as this - no [Required]
    public virtual OtherClass2 { get; set; }
}

So which is better? Independent associations or declaring the foriegn key?

Independent associations match object programming closer. With OOP, one object doesn’t really care much about the Id of a member. ORM’s try to cover these relationships up, with varying degrees of success.

Declaring the foreign key puts database concerns into your model, but there are scenarios where this makes dealing with EF much easier.

Example – when updating an object with a required independent association, EF will want to have the entire object graph in place.

public class MyClass
{
    public int Id {get; set; }
    public string Name { get; set; }
    [Required]  // Note the required.  An optional won't have issues below.
    public virtual OtherClass OtherClass { get; set; }
}

var c = db.MyClasses.Find(1);
c.Name = "Bruce Wayne";

// Validation error on c.OtherClass.
// EF expects required associations to be loaded.
db.SaveChanges();  

If all you want to do is update the name, you’ll either have to pull OtherClass from the database as well since it’s required for entity validation or attach a stubbed entity (assuming you know the id). If you explicitly declare foreign key, then you won’t run into this scenario.

Now with foreign keys, you run into a different issue:

public class MyClass
{
    public Guid Id {get; set; }
    public string Name { get; set; }

    public int OtherClassId { get; set }
    public virtual OtherClass OtherClass { get; set; }
}

var c = db.MyClasses.Find(1);

// Stepping through dubugger, here, c.OtherClassId = old id

c.OtherClass = somethingElse;

// c.OtherClassId = old id - Object and id not synced!

db.SaveChanges();               

// c.OtherClassId = new id, association persists correctly though.

In summary –

Independent associations

• Good: Match OOP and POCO’s better
• Bad: Often requires a full object graph, even if you’re only updating one or two properties. More EF headaches.

Foreign Keys

• Good: Easier to work with sometimes – less EF headaches.
• Bad: Can be out of sync with their object
• Bad: Database concerns in your POCO’s