Why use Base class on POCO's with EF Repository Pattern?

Question

I've seen many EF POCO examples where each POCO class inherits a base Entity class or implements an IEntity interface.

I kind of understand why this is used, but I can't see that it will work in all situations, unless I'm missing something.

The Entity base class might look like this:

public class Entity
{
    #region Primitive Properties
    [Key]
    public int Id { get; set; }
    public DateTime DateCreated { get; set; }
    public DateTime DateModified { get; set; }
    [Timestamp]
    public byte[] rowversion { get; set; }
    #endregion
}

... and the concrete POCO class would look like this:

public class BlogCategory : Entity
{
    #region Properties

    [Required(ErrorMessage = "Category Name is required.")]
    public string CategoryName { get; set; }
    public virtual ICollection<Blog> BlogList { get; set; }

    #endregion
}

This is fine when all my classes contain a single Primary Key property, but what happens when I have a many-to-many relationship? Usually in a many-to-many relationship, the entity has dual properties that represent the Primary Key of this entity.

Such as:

public class ClaimQuestionAnswer : Entity <-- this will not work, will it?
{
    [Key]
    public int QuestionId { get; set; }
    [Key]
    public int AnswerId { get; set; }
    public string Answer { get; set; }
    public byte[] rowversion { get; set; }
}

Will this particular POCO not inherit the base class?

Any clarification is appreciated.

Thanks.

In your example, I would make a combined unique constraint, and a separate PK rather than having a combined PK. — Maess, May 10 '12 at 17:56
@Maess: That's fine from database perspective but as long as EF does not support unique constraints I wouldn't do that. EF doesn't know anything about the unique constraint and you have to ensure uniqueness manually. This would be a solution to only keep an architecture with a single key base class for all entities, but if you naturally have composite keys in the model the architecture is wrong in the first place. — Slauma, May 10 '12 at 18:15
@Slauma, so are you saying that in the case of a "join" entity, it should have a single Id primary key, and then two foreign keys? There doesn't seem to be an overall consensus on this. — Kahanu, May 10 '12 at 19:05
I would use a 2-part composite primary key and each part of the key is a foreign key to one of the two tables that are joined, for example like here: http://stackoverflow.com/a/7053393/270591 (The two parts of the primary key in `MemberComment` in that example are foreign keys by naming conventions, read it as if there were `ForeignKey("Member")` and `ForeignKey("Comment")` attributes on the two ID properties.) — Slauma, May 10 '12 at 20:13
@Slauma, that's what I thought. I like your example in that post and nice explanation. — Kahanu, May 14 '12 at 16:05

score 1 · Accepted Answer · answered May 10 '12 at 18:05

You might have seen only examples which just don't use any entity classes with composite key. Otherwise they had the same problem you are facing now.

The many-to-many relationship is not the best example because in a true many-to-many relationship the join table does not have a corresponding entity in your model. But you might have for any other reason a composite key in an entity, or you could have entities whose key simply need to have another type (string, long, Guid or whatever).

In this case you cannot use your base class because the key is not a common property anymore for all entities. You could move the key out of the base class and put it into the different derived classes - only DateCreated, DateModified and rowversion are common properties. Or you can create multiple base classes for the different key types you are using.

It all depends what common properties you want to support in all entities.

Thanks for this explanation, it was as I expected, but I wasn't sure I was missing something. The multiple base class scenario is a thought that I'll have to contemplate. Thanks. — Kahanu, May 10 '12 at 18:45

Why use Base class on POCO's with EF Repository Pattern?

1 Answers1