I have two classes, Client and Author, that are both derived from Member. They add nothing to Member, but I prefer to have separate classes for semantics and possible later extension. I differentiate based on roles, where an Author is a Member that has an AuthorRole membership, and a Client is a Member that has a ClientRole membership. Using plain vanilla TPH mapping with a discriminator column precludes a Member being both a Client and an Author.
The only way I can see to resolve this is to have a ClientRepository and AuthorRepository do the mapping, with my db context blissfully unaware of any inheritance, but here I take a performance hit, because e.g. a ClientRepository will have to query for Member instances and map these to Client instances.
Is there some other way to do this?
TPH mapping in EF says that client is member and author is member but there can be never a member who is client and author. There even cannot be a member who will change the role from client to author or vice versa.
If you want to store two derived classes in the same table you must use TPH and discriminator. EF will ensure that preceding rules are ensured. If any of those rules is not valid in your scenario inheritance is a bad design for you anyway because even .NET will not allow you changing the type of the instance from client to member.
If you want to keep your current design you will have to use client repository and additional level of mapping to your custom classes because EF is not able to drive TPH inheritance through relation. In EF meaning such inheritance cannot exists because you can change the relation but you cannot change the type of already created instance.