Can use interfaces in creating my models in Entity Framework Codefirst?
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... Thanks!
Ys, You have to define the inheritance in the model. After that make sure you define one/many to one/many relationship. Refer link here, good tutorial.
http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/implementing-inheritance-with-the-entity-framework-in-an-asp-net-mvc-application
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 (ie business objects layer) should adhere to object-oriented principles.
链接地址: http://www.djcxy.com/p/60450.html