Issues related to communication between non-persistent domain components are described in this article.
The use of domain components imposes certain limitations on the description of 1:N relations between them. In other words, by default, XAF does not permit to use non-persistent entities in the 1:N relation. See more detailed information on the implementation of relations at
From the angle of persistence, there are 4 possible combinations of relations:

Persistent MasterNon-persistent Master
Persistent Details++
Non-persistent Details-+

Persistent Master, persistent Details

It is a standard combination, we will not discuss it here.

Persistent Master, non-persistent Details

I was unable to imagine a situation in which this option could be useful in practice. Therefore, we will not discuss this combination, either.

Non-persistent Master, persistent Details

An example for this case is given below.

There are entities, Master1 and Details1. Master1 contains a calculated non-persistent collection of objects Details1, and Details1 contains non-type-safe link DevExpress.Xpo.XPWeakReference, which is similar to BackRefrence. DerivedMaster1 and OneMoreDerivedMaster1 are persistent heirs of Master1.

When implementing domain logic Master1Logic, base class DomainLogicBase<> is used; it implements method GetWeakList<>(), which is necessary in this case.
That both heirs of Master1 have fully valid persistent collections Details1 with absolutely identical behavior, is an advantage of this approach. In so doing, we did not need to duplicate the code.


A separate table is created for XPWeakRefrence in the Database, and, if there are a few million such links in your application, all of them will be stored in this table. It may have a negative effect on the performance of the application as a whole.
Instead of DevExpress.Xpo.XPWeakReference, you can use structure XPWeakReferenceStruct, which is implemented in Xafari. Unlike XPWeakReference, this structure keeps its data in the same table where the persistent class keeps its data (
DomainLogicBase<> processes both types of non-type-safe links.

Non-persistent Master, non-persistent Details

An example for this case is described below.

There are two entities, Master2 and Master2Details1. Master2 contains a calculated non-persistent collection of objects Master2Details1, while Master2Details1 contains a link to Master2, which is similar to BackRefrence. DerivedMaster2 and OneMoreDerivedMaster2 are persistent heirs of Master2. DerivedMaster2Details1 and OneMoreDerivedMaster2Details1 are persistent heirs of Master2Details1.

Here we use an approach where the calculated properties for the collection and the back reference are described at the non-persistent level. However, the real relations between the entities only come to existence in persistent heirs. In so doing, the persistent properties must be marked with attribute Term. This allows determining exactly the properties that implement the relations, in the base logic.
The following extension methods for Type are used in this example:

  • GetValueByTerm()
  • SetValueByTerm()
  • GetListValueByTerm()

These methods allow controlling property values of the entity through Term names, instead of using property names. It is convenient when property names are not yet known, but the Term names are known, at the time of writing the code.
This method was used for describing hierarchical dictionaries HierarchicalClassifierItem using IHiererchyNode.