Can use interfaces in creating my models in Entity Framework Codefirst?

Question

I'm new to Entity Framework and I'm practicing CodeFirst. My problem is I'm creating a model class and I want that class to inherit from two other classes. For example, an Employee has personal information such as first name,middle name,last name, and etc... it has also a contact information such as address,phone,email, and etc... Students also has those properties as well. The reason why I separated those information into two different classes was that, another entity also can have contact information but without personal information, such as a company,schools,hospitals,warehouses and etc...

Sample codes:

public class ContactInfo
{
    public string Address { get; set; }
    public string Email { get; set; }
    public string Phone { get; set; }
}

public class PersonalInfo
{
    public string Firstname { get; set; }
    public string Middlename { get; set; }
    public string Lastname { get; set; }
}

public class Employee : // This should be inheriting from PersonalInfo and ContactInfo
{
    public int EmployeeID { get; set; }
}

public class Supplier : ContactInfo // Inheriting from ContactInfo and no PersonalInfo
{
    public int SupplierID { get; set; }
    public string Name { get; set; }
}

What I wanted to do is to create interfaces (IPersonalInfo,IContactInfo) to be inherited by Employee so that it will look like this:

public class Employee : IPersonalInfo,IContactInfo
{
    public int EmployeeID { get; set; }
}

Is this a good practice? And if not, how can I manage with this kind of scenario?

Answer 1

First of all, it sounds like you are confusing inheritance and composition. An example of inheritance would be having a common Person base class from which you could inherit an Employee or a Student. An example of composition would be an Employee and a Supplier each composed with a common ContactInfo object, but having no common base class.

When you design your entities, you are really designing the table structure of the underlying relational database. You can model inheritance: a common base class can be represented by its own table and any common fields, and any specialized classes could be in their own table with a foreign key linking to the common table. It may or may not make sense to do this - by breaking things up into separate tables, you're adding another join to your queries. This will slow down performance.

Composition can also be represented in a relational database, but it only really makes sense if it is a common component shared amongst many other data entities. ContactInfo is almost always going to be unique for a given person/supplier, so it really doesn't make sense to break it out into a separate table - you're just adding an extra table join which, again, will slow down performance on your queries.

You should think about moving inheritance/composition up a layer in your design. The entities (data access layer) should match the relational database, but the domain model (i.e. business objects layer) should adhere to object-oriented principles.