none
Object Model to Data Model (ORM) Advice RRS feed

  • Question

  • I am building an object model for a Person. A Person can be one of two types; Employee or Contractor (although they can be both). I am proposing having a Person object which contains core data for a person (dob, height, stuff that never changes). I started with an inheritance hierarchy where Person is the root (Employee and Contractor as subtypes), but that led me to conclude that a Person can only ever be an Employee OR Contractor. With this approach, I cannot create an Employee and a Contractor that share the same Person info.
    My issue possibly stems from the fact that I come from a Data Modelling background (and don't have such a good grasp on OO). I want to store this model in my database with a Person table, and a Employment table (which will store the Employee and Contractor data). There will be a one to many relationship from Person to Employment.
    How am I best to model this in C#??? I thought I'd maybe use composition, where the Employee and Contractor classes contain associations??? But then I lose the concept of Employee and Contractor deriving from the same type. Any Ideas??
    Many Thanks....
    Friday, July 22, 2011 4:25 PM

All replies

  • I don't see them as two types.

    I work for the company for a year as a contractor.

    Then I go perm.

    Get a new boss.

    I leave.

    Old boss has moved rather than left.

    6 months later he gets me back in as a contractor.

     

    I'm me all the way through, not a different entity at all.

     

     

    What would go in Employment?

     PersonID

     DateStart

     DateEnd

     EmployeeType

     

    If I model that via EF I would expect to see Employee and Employment as two classes you see.

    I'd then maybe use linq to entities to filter for the last Employment type and DateEnd.

    Or maybe another method GetEmployeeWithLastType(ID)


    Friday, July 22, 2011 6:53 PM
  • I would find all the properties that each type, and Employee or Contractor would have in common and put them in an abstract person class.

    I would then have an employee as a concrete type of an abstract person.

    Since you identified a case where a person can be both types at once, the distinction in your case may not be enough to warrant a seperate class for each.

    If you can identify the distinctive attributes of a contractor and employee, you can put those properties in interfaces that the employee implements. Properties common to both go into Person.

    Say a contractor implements IContract, which has a ContractId. Also say that an employee implements IEmployee, which has a BenefitsId.

    By having Employee inherit from Person, they have a name and an age etc from the abstract base Person. If the Employee is a contractor, then they have a ContractId. The distinction that an Employee is both would be when you have the property BenefitsId and a ContractId for your Employee.


    Louis
    Friday, July 22, 2011 7:01 PM
  • Hi

    I would see the relation 

    Employee is a Person

    Contractor is a Employee , Contractor is a Person

    So, Employee implements Person and Contractor implements Employee,

    In context with NHibernate, there will be one table with discriminator whether record represent Employee/Contractor....

    If and only Contractor has it's own properties else better idea is what Andy suggested..just having EmployeeType , probably enum, in Employee table itself.


    If this post answers your question, please click "Mark As Answer". If this post is helpful please click "Mark as Helpful".
    Monday, July 25, 2011 4:53 PM
  • Thanks for all the replies.

    @Andy: I agree that through all those changes you suggested (new contract, made perm, new boss, leave job etc.) I am the same person and that is why I want the person object to represent ME (containing, dob, height etc...). There will only ever be one record for me in the database. The employee and contractor objects will represent the multiple instances for when I am an employee and/or a contractor.

    I would expect the employment table (with hindsight, that's a poor name for that table, as it does not represent employment, but rather specific data relating to an employee, contractor, prospective employee, etc) to store PersonId, Type, Employee related stuff (NI Number,?), Contractor related stuff (Contractual contract id?). I need the employee and contractor to be seperate in my object model, because they are different types and would be treated differently by the UI.

    My problem is how i go about creating an employee and a contractor that share the same person details (without ending up with a new row in the person table)??

    @IAmLouis: That is exactly how i would like to model this problem, but I just cannot understand how to do that in the EF, without resulting in multiple rows in the person table for the same person.

    Thanks again for your time on this...

    Thursday, July 28, 2011 8:53 AM
  • You need to store People by Id. Always deal with person and have thier ID unique. Specify the key on the person entity. The contractor and Employee tables should store a primary key, and a foreign key to the person id.
    Louis
    Thursday, July 28, 2011 4:57 PM