Question

The following is using EF 5.0.0-rc and Code First. In my design, I have an attribute entity:

public class Attribute
{ 
    public int AttributeId { get; set; }
    public Guid Guid { get; set; }
    public string Name { get; set; }
    public string Value { get; set; }

    /* Used for testing the first fluent statement */
    public virtual ICollection<Customer> Customers { get; set; }
}

I also have multiple entities containing a GUID:

public class Customer
{ 
    public int CustomerId { get; set; }
    public Guid Guid { get; set; }
}

public class Location
{ 
    public int LocationId { get; set; }
    public Guid Guid { get; set; }
}

I would like the attribute table to be common to both the customer and location table, with no columns or tables in between. I just can’t seem to get the correct mapping in the fluent API to create a FK without a helper table:

        modelBuilder.Entity<Customer>()
            .HasMany(o => o.Attributes)
            .WithMany(o => o.Customers)
            .Map(m => m.MapLeftKey("Guid"));

… will generate a CustomerAttributes table, which it shouldn’t need.

        modelBuilder.Entity<Organization>()
            .HasMany(o => o.Attributes)
            .WithOptional()
            .HasForeignKey(o => o.Guid);

… won’t compile because

The types of all properties in the Dependent Role of a referential constraint must be the same as the corresponding property types in the Principal Role.

How should the relationship be setup? Or is the design not appropriate?

Edit: Success!

On Raphaël Althaus direction, I was ready to give into EF’s ways and live with separate tracking tables for each entity, but his suggestion to create a new class that the Cust and Loca entities will inherit set me off on the right direction.

First I created a “parent” class, which also gave me a place to refactor some of the audit data that is stored on most entities:

public class ParentEntity
{
    [Key]
    public Guid Guid { get; set; }

    public DateTime? CreatedOn { get; set; }
    public string CreatedBy { get; set; }
    public DateTime? ModifiedOn { get; set; }
    public string ModifiedBy { get; set; }

    [Timestamp]
    public byte[] Version { get; set; }

    public virtual ICollection<Attribute> Attributes { get; set; }
}

Then I inherited the parent class on the Cust and Loca entities:

public class Customer : ParentEntity
{ 
    public int CustomerId { get; set; }
    public Guid Guid { get; set; }
}

public class Location : ParentEntity
{ 
    public int LocationId { get; set; }
    public Guid Guid { get; set; }
}

I also modified the Attribute class to support a new FK field, EntityGuid:

public class Attribute
{
    public int AttributeId { get; set; }
    public Guid EntityGuid { get; set; }
    public string Name { get; set; }
    public string Value { get; set; }
}

Which gave me almost everything I needed, except … it was trying to store every entity in the new ParentEntity table. To fix that I used:

        modelBuilder.Entity<Customer>().ToTable("Customers");
        modelBuilder.Entity<Location>().ToTable("Locations");

And finally the piece that brings it all together:

        modelBuilder.Entity<ParentEntity>()
            .HasMany(e => e.Attributes)
            .WithRequired()
            .HasForeignKey(e => e.EntityGuid);

The only drawback I can tell is the ParentEntity takes over as the primary key, which is a Guid. But I kept my other keys in place though and plan to use those as clustering index.

Answer 1

Your mixing object world and rDBMS world.

You’re in an ORM, so you shouldn’t mind (well, not completeley, but in this case, yes) what’s really in your Database.

A rDBMS can’t manage a many to many relationship without a “link” (relation) table (how to represent a foreign key which is a list ? Impossible without a relation table).

In the object world, a List<x> in y and a List<y> in x can do that, without any “relational” entity.

EDIT

If you want a common “Relation” table, you could maybe create a new entity (with a Guid) : Customer and Location would inherit from that new entity, and attribute entity would be linked with that new entity.