Ticket T204296
Visible to All Users

EF - Use of complex types that are not registered in DbContext and have no key property

created 10 years ago (modified 10 years ago)

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.

Comments (2)
J J
Jean Pierre Chauny 10 years ago

    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.

    Anatol (DevExpress) 10 years ago

      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.

      Answers approved by DevExpress Support

      created 9 years ago (modified 9 years ago)

      We have implemented the functionality described in this ticket. It will be included in our next update(s).

      Please check back and leave a comment to this response to let us know whether or not this solution addresses your concerns.

      Additional information:

      Consider the following entities:

      C#
      public class Product { public Product() { PriceRange = new Range(); } public Int32 ID { get; set; } public String Name { get; set; } public Range PriceRange { get; set; } } public class Range { public Range() { } public Decimal Low { get; set; } public Decimal High { get; set; } }

      The Range  class has no key property. Entity Framework does not map this class to a separate database table. Properties of such a class persist in the table mapped to the parent Product class, where the Range type property is declared. So, the Product table will have the ID, NamePriceRange_Low and PriceRange_High columns.

      We recommend that you apply the ExpandObjectMembers attribute to properties of a complex type:

      C#
      [ExpandObjectMembers(ExpandObjectMembers.Always)] public Range PriceRange { get; set; }

        Disclaimer: The information provided on DevExpress.com and affiliated web properties (including the DevExpress Support Center) is provided "as is" without warranty of any kind. Developer Express Inc disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.

        Confidential Information: Developer Express Inc does not wish to receive, will not act to procure, nor will it solicit, confidential or proprietary materials and information from you through the DevExpress Support Center or its web properties. Any and all materials or information divulged during chats, email communications, online discussions, Support Center tickets, or made available to Developer Express Inc in any manner will be deemed NOT to be confidential by Developer Express Inc. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.