The requested page is not available for the requested platform. You are viewing the content for .NET Framework 4.5.2+ platform.

Relationships Between Persistent Objects in Code and UI

  • 7 min to read

When designing a business model, it can be necessary to set specific relationships between business objects. This topic describes how to set these relationships between persistent objects in an XPO application and demonstrates how these relationships will be organized in a UI.

Tip

To learn about the relationships between entities in Entity Framework, refer to the Relationships Between Entities in Code and UI topic.

The "Many" side of an association, which is a collection property and displayed in UI using the ListPropertyEditor in WinForms and ASP.NET applications and MobileLinkToListPropertyEditor in Mobile applications. To show the "One" side that is a reference property, LookupPropertyEditor, ASPxLookupPropertyEditor and MobileLookupPropertyEditor are used in the WinForms, ASP.NET and Mobile applications accordingly. If ExpandObjectMembersAttribute is applied to the reference property with the ExpandObjectMembers.Never parameter, ObjectPropertyEditor is used instead. Each object collection has an individual Actions set, which depends on the collection type. You can manage the New, Delete, Link, or Unlink Action's visibility in the Model Editor. Set the List View's AllowNew, AllowDelete, AllowLink, or AllowUnlink property to false to hide these Actions.

If a child object is aggregated (i.e., this object is considered a part of a master object and decorated with the AggregatedAttribute), an XPNestedObjectSpace Object Space is created for its Detail View, because this object should not be physically saved to the database until its owner is saved. If a child object is not aggregated (i.e., it can exist separately), a separate XPObjectSpace is used for its Detail View. A nested List View where objects from the detail collections are shown uses the same master XPObjectSpace regardless of the aggregation.

This topic includes the following sections.

One-to-Many (Non Aggregated)

The relationship between the Department and Contacts illustrates the One-to-Many type, when many Contacts can be included into one Department. In this example, Department object contains a child ContactsCollection collection and is the "One" side of its One-to-Many relationship.

NonAggregatedOneToMany_Win

NonAggregatedOneToMany_Web

NonAggregatedOneToMany_Mobile

The List View that displays the ContactsCollection is accompanied by a New Action. This Action allows end-users to add new Contact objects to one of the existing Department objects (including the current object). In addition, the Link and Unlink Actions are available and allow you to add and remove a reference to a Contact object from another collection.

Nonaggregated objects are created in their own Object Space. So, the new Contact objects created within the Department Detail View can be saved separately from the parent object.

The following code demonstrates how you can implement this type of relationship.

[DefaultClassOptions]
public class Contact : XPObject {
    //...
    private Department department;
    [Association("Department-Contacts")]
    public Department Department {
        get { return department; }
        set { SetPropertyValue(nameof(Department), ref department, value); }
    }
}
[DefaultClassOptions]
public class Department : XPObject {
    //...
    [Association("Department-Contacts")]
    public XPCollection<Contact> ContactsCollection {
        get { return GetCollection<Contact>(nameof(ContactsCollection)); }
    }
}

One-to-Many (Aggregated)

Let's assume that a Contact has a collection of Notes, which are aggregated with their parent Contact. In this case, the Note object declares the "One" aggregated side of the One-to-Many relationship with the Contact object.

AggregatedOneToMany_Win

AggregatedOneToMany_Web

AggregatedOneToMany_Mobile

The List View that displays the NotesCollection is accompanied by the New Action. This Action allows end-users to add new Note objects. Note that in this instance, the Contact property of the new Note objects will be automatically set to the current Contact and this editor is not displayed in the UI.

Aggregated objects are created in the parent object's Object Space. So, the new Note objects created within the Contact Detail View will be saved when their parent object is saved, and will be deleted when their parent object is deleted (cascade deletion mechanism).

The following code demonstrates how you can implement this type of relationship.

[DefaultClassOptions]
public class Contact : XPObject {
    //...
    [Association("Contact-Notes"), DevExpress.Xpo.Aggregated]
    public XPCollection<Note> NotesCollection {
        get { return GetCollection<Note>(nameof(NotesCollection)); }
    }
}
[DefaultClassOptions]
public class Note : XPObject {
    //...
    private Contact contact;
    [Association("Contact-Notes")]
    public Contact Contact {
        get { return contact; }
        set { SetPropertyValue(nameof(Contact), ref contact, value); }
    }
}

Many-to-Many

For example, each Contact can have a collection of Tasks and each Task can be assigned to a number of Contacts. Thus, the relationship between the Contact and Task objects is named Many-to-Many.

ManyToManyObject_Win

ManyToManyObject_Web

ManyToManyObject_Mobile

The List View that displays the TasksCollection is accompanied by the Link Action. This action allows end-users to add references to existing Task objects. If the NewObjectViewController.LinkNewObjectToParentImmediately property is set to true, the New Action is not applied to this collection. This behavior complies with the unique concept of the Many-to-Many relationship. However, you can create a new Task in the Link Action's pop-up window.

The Unlink Action is also provided for the TasksCollection. This Action allows end-users to remove references to Task objects from the collection.

The following code demonstrates how you can implement this type of relationship.

[DefaultClassOptions]
public class Contact : XPObject {
    //...
    [Association("Contacts-Tasks")]
    public XPCollection<Task> TasksCollection {
        get { return GetCollection<Task>(nameof(TasksCollection)); }
    }
}
[DefaultClassOptions]
public class Task : XPObject {
    //...
    [Association("Contacts-Tasks")]
    public XPCollection<Contact> ContactsCollection {
        get { return GetCollection<Contact>(nameof(ContactsCollection)); }
    }
}

One-to-One

If each Contact can have only one unique Address and one Address can't be assign to many Contacts, this relationship is the One-to-One.

OneToOneObject_Win

OneToOneObject_Web

OneToOneObject_Mobile

This relationship doesn't provide a collection side. Note that in this instance, the Contact property of the new Address objects will be automatically set to the current Contact.

The following code demonstrates how you can implement this type of relationship.

[DefaultClassOptions]
public class Contact : XPObject {
    //...
    [Aggregated]
    private Address address;
    public Address Address{
        get { return address; }
        set {
            if (address == value) return;
            Address prevAddress = address;
            address = value;
            if (IsLoading) return;
            if (prevAddress!= null && prevAddress.Contact == this)
                prevAddress.Contact = null;
            if (address != null)
                address.Contact = this;
            OnChanged(nameof(Address));
        }
    }
}
[DefaultClassOptions]
public class Address : XPObject {
    //...
    Contact contact = null;
    public Contact Contact {
        get { return contact; }
        set {
            if (contact == value)
                return;
            Contact prevContact = contact;
            contact = value;
            if (IsLoading) return;
            if (prevContact != null && prevContact.Address == this)
                prevContact.Address = null;
            if (contact != null)
                contact.Address = this;
            OnChanged(nameof(Contact));
        }
    }
}
See Also