This example is applicable to XAF versions prior to 16.1. In 16.1, we significantly simplified the use of non-persistent objects. For details, refer to the How to: Display a Non-Persistent Object's Detail View from the Navigation help topic.
Question Comments
Added By: DKx at: 7/1/2015 7:27:56 AM
This code fails with session-based non-persistent classes when Refresh action is called:
"The error occurred:
Type: SessionMixingException
Message: The 'Example.Module.MyNonPersistentObject' object belongs to a different session."
void application_CustomProcessShortcut(object sender, CustomProcessShortcutEventArgs e)
{
if (e.Shortcut.ViewId == "MyNonPersistentObject_DetailView")
{
IObjectSpace objectSpace = Application.CreateObjectSpace();
e.View = Application.CreateDetailView(objectSpace, objectSpace.CreateObject<MyNonPersistentObject>(), true);
e.Handled = true;
}
}
How to solve it?
Added By: Dennis (DevExpress Support) at: 7/1/2015 11:26:44 AM @DKx: It is wrong to inherit non-persistent classes from the base XPO classes like BaseObject, XPObject, etc. Use session-less POCOs instead (like demonstrated in this example).Added By: DKx at: 7/2/2015 12:52:10 AM@Denis: Yes, you're right.
A possible solution I found as working is to pass ObjectSpace instead of Session to created non-persistent object. This way I can use session functions inside as usual (FindObject etc.):
abstract public class NonPersistentObject
{
private IObjectSpace ObjectSpace;
public NonPersistentObject(IObjectSpace ObjectSpace)
{
if (ObjectSpace == null)
throw new Exception("Unintialized ObjectSpace for non-persistent object passed.");
this.ObjectSpace = ObjectSpace;
}
protected Session Session
{
get { return ((XPObjectSpace)ObjectSpace).Session; }
}
}
When you develop something like this, but need an editable detailview, change AllowEdit to true, and add the following line:
((DetailView)e.View).ViewEditMode = ViewEditMode.Edit;
This will put the detailview immediately in edit mode.
This isn't an issue when using domain components, but when you use nonpersistent classes derived from an XPO object, it comes in handy, because changing from view to edit mode forces a refresh, with an sessionmixing error as a result.
@Dennis: using nonpersistent objects gives us great power when using OnChanged() etc. And it frees us from studying the DC world.
Added By: Michael (DevExpress Support) at: 7/3/2015 2:42:43 AM @Willem: Non-persistent classes derived from base XPO classes won't work correctly with built-in controllers. They cannot be refreshed because they are not read from the database. If you need property change notifications, implement the INotifyPropertyChanged interface in the POCO class.