Scenario description:
Suppose there is a complex type without a key property and an entity type with a complex type property:
C#public class Address {
public string PropertyX { get; set; }
}
[Table("Organisations")]
public class Organisation {
[Browsable(false)]
public Int32 Id { get; protected set; }
public Organisation() {
ShippingAddress = new Address();
}
public Address ShippingAddress { get; set; }
}
public class Solution4DbContext : DbContext {
...
public DbSet<Organisation> Organisations { get; set; }
}
According to EF docs, no table is created for the Address type and its data is mapped to the main table by default.
However, the Address class appears in the Model Editor as if it is a regular entity and Views are created for it as for other business classes.
This is confusing and may even lead to errors if you try to use XAF built-in editors for entity properties with this complex type. Refer to the T200742 ticket for more details.
Current solutions:
First, decorate the complex type with the DomainComponent attribute or add it to the ModuleBase.AdditionalExportedTypes collection to register this type in the types info and Application Model. After this, XAF will handle this type as a usual non-persistent class. For example, you will be able to use DetailPropertyEditor for it as shown below:
C#[EditorAlias(DevExpress.ExpressApp.Editors.EditorAliases.DetailPropertyEditor)]
public Address ShippingAddress { get; set; }
It will also be possible to display individual properties of this type as described in the How to show data from related objects in XAF views article.
If you want to show a drop-down control (lookup) for this property, implement a custom dropdown-based PropertyEditor, which can work with key-less types. Choose an appropriate control, e.g. LookUpEdit, and configure it in your property editor as described in our documentation: Implement Custom Property Editors.
Proposed improvements:
Either do not treat such complex types as entities or ensure support of built-in editors for such properties, e.g. ObjectPropertyEditor or DetailPropertyEditor. Take special note that this improvement makes sense only when a complex type has no key property.
The proposed improvement was posted 2 months ago.
Any news?
According to Domain Driven Design, Value Objects (Entity Frameworks Complex Types) are a very important element of the Domain Model. Abstractions such as Money (Amount and Currency), Address (AddresLine1, AddresLine2, ZipCode, City, Country) are Value Objects. It makes none sense to treat a Value Object as an Entity.
Thank you for your feedback. I have described more solutions in the Current solutions section. I hope you will find them useful. We will keep you posted on the progress with this task.