How to: Perform CRUD Operations with Non-Persistent Objects

Dec 19, 2025
8 minutes to read

Follow the steps below to implement the Create, Read, Update, and Delete operations for non-persistent objects.

Implement the following non-persistent class:
Open the application’s Startup.cs file and ensure that the NonPersistentObjectSpaceProvider is registered. The Template Kit adds this code automatically. Note that this code may be missing if you created your project in an older XAF version:
Next, implement a global storage for non-persistent objects. The storage must implement all required CRUD operations:
Register your custom storage as a singleton service in the application’s Startup.cs file:
Extend the application’s Non-Persistent Object Spaces so that they use your custom storage to store objects. To do this, you can implement a NonPersistentObjectSpaceExtender class that encapsulates the logic that accesses all required services and handles all required events for every created NonPersistentObjectSpace:
To apply the NonPersistentObjectSpaceExtender to every created NonPersistentObjectSpace, add application builder code that handles the OnObjectSpaceCreated event as shown in the following code snippet:

The following image demonstrates the result:

Important Notes

1. Non-Persistent Object Spaces Do Not Track Changes

A non-persistent Object Space does not track changes of original objects and does not add changed objects to the ModifiedObjects collection. You can use the IObjectSpace.SetModified(Object) method to add changed objects to this collection explicitly. If a non-persistent object implements the INotifyPropertyChanged interface, you can set AutoSetModifiedOnObjectChange / AutoSetModifiedOnObjectChangeByDefault to true to automatically add the changed object to the ModifiedObjects collection when the PropertyChanged event is raised.

If a non-persistent object implements IObjectSpaceLink and its ObjectSpace property value doesn’t match the Object Space that manipulates the object, the following exception is thrown: ‘An error with the number 1021 has occurred. Error message: The object that was edited belongs to a different ObjectSpace. This error can occur if you manipulate your objects via an ObjectSpace to which these objects do not belong.’

We recommend that you do not share non-persistent objects when they implement IObjectSpaceLink or have linked persistent objects because of the following limitations:

You can use a shared (static) storage for non-persistent objects only if a single NonPersistentObjectSpace works with these objects at any time. Non-persistent objects that implement IObjectSpaceLink cannot belong to multiple Object Spaces simultaneously. When you change the IObjectSpaceLink.ObjectSpace property to a different Object Space, dispose of the previously used Object Space. Otherwise, object changes can trigger events in multiple Views and cause conflicts or unexpected behavior.
You cannot share persistent objects between Object Spaces.

Instead of sharing non-persistent objects, create new instances in each NonPersistentObjectSpace. If you want to preserve data from all instances of a non-persistent object, store this data separately. See the example in the MainDemo.Module\NonPersistentObjects\NonPersistentObjectSpaceExtender.cs_ file a demo that is installed in the following folder: %PUBLIC%\Documents\DevExpress Demos 25.2\Components\XAF\MainDemo.NET.EFCore\CS\BusinessObjects\NonPersistent.

For more information, refer to the following Breaking Change description: Core - Error 1021 may occur if a non-persistent object implements IObjectSpaceLink and is shared between different Object Spaces.