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 when to use them.
Complex types are non-scalar properties of entity types that enable scalar properties to be organized within entities. Like entities, complex types consist of scalar properties or other complex type properties.
A complex type is a template for defining rich, structured properties on entity types or on other complex types. Each template contains the following: A unique name. ( Required) The name of a complex type cannot be the same as an entity type name within the same namespace.
by Microsoft. According to the OData v4 specification, a complex type can inherit from another complex type. (A complex type is a structured type without a key.) Web API OData 5.3 supports complex type inheritance. This topic shows how to build an entity data model (EDM) with complex inheritance types.
Complex types are nested data structures composed of primitive data types. These data structures can also be composed of other complex types. Some examples of complex types include struct(row), array/list, map and union. Complex types are supported by most programming languages including Python, C++ and Java.
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With