How to perform CRUD operations with non-persistent objects using standard XAF forms

This post is about our putting a continuous effort into improving XAF developer usability in scenarios requiring manipulation of non-persistent objects or POCOs. Typical scenarios relying on such non-persistent classes include all sorts of confirmation dialogs, user input forms with parameters, lists with temporary data, analysis and reporting data obtained from dynamic runtime calculations, stored procedures (SP), arbitrary SQL queries or third-party services or anything that needs a standard XAF CRUD UI (and, of course, extra modules), but does not require object state to be eventually persisted to the database.

As you probably know, XAF was primarily designed for automatic UI generation tied to one of the two supported persistence layers or ORM technologies - XPO and Entity Framework. Don't get me wrong here: binding standard XAF forms to temporary non-persistent data was always possible (and there are many standard XAF pieces are implemented with it: logon, change the password, about, validation, notification dialogs, etc.), but the number of supported scenarios was quite limited previously. For instance, a year ago there was no really straightforward way of binding a non-persistent list of objects to a ListView directly. It required creating an intermediate non-persistent class holding a collection of non-persistent objects and then showing its DetailView (learn more on this former approach...).

So that is where NonPersistentObjectSpaceProvider, NonPersistentObjectSpace and its ObjectsGetting event first came to the rescue in v15.1 to simplify the lives of XAF developers (learn more...). The current v15.2 brought it to the next level by allowing standard XAF CRUD commands (the New, Delete and Save Actions) for non-persistent objects. The ModifiedObjects property of the NonPersistentObjectSpace class provides access to all created, deleted and modified objects within its scope, unless the IObjectSpace.CommitChanges, IObjectSpace.Refresh or IObjectSpace.Rollback methods are called. Step-by-step instructions for implementing this functionality in your XAF v15.2.4+ project are now provided in the online product documentation:

How to: Perform CRUD Operations with Non-Persistent Objects

And here are a couple of screenshots showing what it can look like in the UI*:

Using a built-in lookup editor based on values from another table for editing simple property types

This is actually a variation of a solution I described in my recent A very interesting way to update and display a persistent property via a non-persistent one post, because it is again based on a non-persistent reference property filtered using the DataSourcePropertyAttribute along with a custom data source collection.
This non-persistent reference property is represented using the standard XAF's lookup PropertyEditors, which are quite convenient for providing a user with the capability to select a single value either from a database table or from an arbitrary data source. In one turn, by adding custom logic to the getter and setter of our non-persistent calculated property, we can update the stored persistent value, which does not need to be a reference to another persistent class (table), but to any type (e.g., string or integer). This may come in handy for legacy databases when you cannot really modify the schema to provide normal associations between tables.

Let's take a look at the actual code for this solution:

A very interesting way to update and display a persistent property via a non-persistent one

Scenario:

A customer wanted to extend the User class with additional property that would store the information about the startup View for this user when it launches the app. This is very similar to the StartupNavigationItem attribute, which is present for the NavigationItems node in the application model, but with the difference that application users should be able to modify this via the standard XAF CRUD forms.

How would you normally approach this?;-)

Possible solutions

At this time, I can think of at least three good options for accomplishing this task: two platform-dependent and one platform-agnostic, which I am going to detail later in this post. In all three cases we will extend our business class with a string property that would store this startup View information (its identifier) in the database.