Designing models with multiple (optional?) inheritance in Entity Framework

Question

I am struggling for the last couple of days on an idea of how to model these entities in EF. So I decided to ask the community to lend a hand. :-) The core classes are given below.

class BaseEntity
{
   long Id;
   DateTime DateCreated;
}


class Person : BaseEntity
{
   string Name;
   string Address;
}

class Taxpayer : Person
{
    string TaxpayerIdentificationNumber;
    double Income;
    Taxpayer(or Person) Spouse;
}

class Client : BaseEntity
{
    string CustomerId;
    string ContactNumber;
}

class Partnership : Client
{
    List<Taxpayer (or Person)> Partners;
}

class Company : Client
{
    string CompanyRegistrationNumber;
}

The scenario is, a Client can be one of the 3 types i.e. Taxpayer, Partnership, Company (Specialization/IsA).

The problem is, in the case of the Taxpayer class he should inherit both the properties of Client and Person classes. (UPDATE: A taxpayer can be a client but not necessarily) Also in the other places Taxpayer class is used, most of the time it can be either a Person class or Taxpayer class.

Any ideas on how to proceed?

Thanks.

they can't because a client can be a partnership/company which is not a person. — FireDrakon, Jun 06 '17 at 12:03

score 1 · Answer 1 · answered Jun 06 '17 at 06:37

you might need to give a thought to interfaces instead of classes. Following example could help a bit:

interface IBaseEntity
    {
        long Id;
        DateTime DateCreated;
    }

    interface IPerson : IBaseEntity
    {
        string Name;
        string Address;
    }

    interface IClient : IBaseEntity
    {
        string CustomerId;
        string ContactNumber;
    }

    class Taxpayer : IClient, IPerson
    {
        string TaxpayerIdentificationNumber;
        double Income;
        Taxpayer Spouse;
    }

    class Partnership : IClient
    {
        List<Taxpayer> Partners;
    }

    class Company : IClient
    {
        string CompanyRegistrationNumber;
    }

Thanks for the solution. :) This solves the problem to an extent. But what about the scenario when Partners(Partnership class) or Spouse(Taxpayer) is not a taxpayer? — FireDrakon, Jun 06 '17 at 12:05

score 0 · Answer 2 · answered Jun 06 '17 at 18:25

thinking out loud:

People are a lot of things, but always people. A person does not morph into a new species with different DNA just because (s)he is unemployed, in a business partnership, or plays professional tiddily-winks.

This leads me to thinking about composition not inheritance. A client might have a person reference to tell who (s)he is. Likewise for a taxpayer or partner.

Partnerships is an engagement in particular behavior. For the purpose of a partnership class I don't care who you are, only that you can function in a partnership. So now I'm thinking how there is explicit, specific functionality with a focus on taxpaying, partnering.

This gets me thinking about 2 design patterns, visitor and decorator. Decorator adds functionality to an existing class dynamically; essentially extends a class via composition, not inheritance. A visitor performs its functionality against a given object (or set of said objects). Visitor can solve the "double dispatch" problem - i.e the lack multiple inheritance.

I get two things from design patterns. First is inspiration. How to think about what my problem is. The inspiration and perspective has proven far more helpful than patterns as mere recipes. Second is specific Object Oriented design. That is design, revise, and extend without resorting to amateurish code hack-n-slash. But don't take that design too literally. These are patterns, not inflexible dictats. Features of your particular programming language can work within these patterns. I'm thinking of how i've used delegates in C# in lieu of "command" subclasses as called for in the command pattern.

Designing models with multiple (optional?) inheritance in Entity Framework

2 Answers2