views:

44

answers:

2

I am trying to use inherited types with EF, which has been all cool and gravy until now.

I have a base type (Person) and two types that inherit person (Employee & Customer). I run into a problem when I want a person to be an Employee and a Customer at the same time. For example:

Person person = db.Persons.Single(p => p.id == id);

if (person is Employee)
{
    Console.WriteLine("Person is an employee");
}

//True only if person is Employee == false
if (person is Customer)
{
    Console.WriteLine("Person is a customer");
}

If I map a Person to an Employee and a Customer, "Person is Customer" always returns false until I remove the Employee mapping from the person.

And I am not sure what that is called... but there is a table per type (Person is a table, Customer is a table, and Employee is a table in the DB).

+2  A: 

You can't do this since you can not have multiple inheritance.

Within your DB Customer and Employee tables I would suggest foriegn key into the Person table. Then in your object model the Customer and Employee there would be a Person property.

As you are just wanting to iterate over whether they are Customers or Employee's just use linq on those collections which should be on the Entity context

aqwert
Sucky :(Lot's of code to change now. Thanks for your help
Chris
A: 

Perhaps the Customer class could have a property (essentially a pointer) called EmpObj (of type Employee) which could point to the instantiated Employee object. If it's null then the given Customer wouldn't also be an Employee. You can do the same thing in the Employee class and give it a property called CustObj that would point at the instantiated Customer object for the given Employee.

Clear as mud?

Essentially what you're asking here is to know if a Customer is also an Employee, and vice-versa. If a person is a Customer and an Employee then you really should have instances of both classes to represent that person. It's a simply a matter of making Customer and Employee aware of each other.

Jagd
I see what you are trying to say here now, however I think this is more confusing than just going back to using navigation properties to get the Employee and Customer objects instead of inherited types. I thought it was cool at first (since all the properties where available in one object which made some tidier code), but obviously in this instance it isn't the best solution. Thanks for your help
Chris