I have tried to read the msdn article on complex types. But it does not explain when to use it. Also there is not a comprehensive explanation on the web on complex types and
Consider this ContactDetails
class for example:
public class ContactDetails
{
public string HomePhone { get; set; }
public string MobilePhone { get; set; }
public string FaxNumber { get; set; }
}
By default, EF will treat ContactDetails
as an Entity. That means that if (for example) you're having a Person
class with a navigation-property of ContactDetails
type, EF will map the Person.ContactDetails
relationship to a different table (because Entity is something that is having an identity of its own, hence other entities may refer to it - and that would require a different table in relational terms).
By denoting ContactDetails
as a Complex Type instead, EF will no longer treat it as an entity that requires a relationship and instead map it to the same table of the parent (containing) entity (Person
in my example), effectively making it a Value Object.
The lengthy explanation is in the MSDN article you linked... so you basically want an easy explanation:
A complex type is a set of properties that exist in its own object for C#, but are mapped to columns on an already existing table (the one for the entity that contains it), instead of having its own table (which would need a key, etc.).
So imagine you want this table on the database:
Orders
----------
Id (bigint)
Name (varchar)
Street (varchar)
Region (varchar)
Country (varchar)
But want this structure in the C# entities:
class Order
{
long Id;
string Name;
struct Address
{
string Street;
string Region;
string Country;
}
}
So there Address
would be a complex type: it would not exist on its own (there wouldn't be Addresses
table) on the database... it would only exist as a set of columns on the Orders
table.
As noted by @HenkHolterman in the comments, the value of having complex types is having a single C# entity which can be used as a value for other containing entities (in my example, you could have an Address
in a Supplier
entity, for example, but it will just be mapped as a set of columns in the Suppliers
table). It makes it easy to work with the values in the complex type.
The disadvantage is precisely that one: you may have to repeat the complex type values many times in the database if it happens that a same Address
(or whatever other type you use) can be shared among different entities.
Whether you choose to work with complex types or separate entities is up to you and your design.