[Expand]General Information
[Expand]WinForms Controls
[Expand]ASP.NET Controls and MVC Extensions
[Expand]ASP.NET Bootstrap Controls
[Expand]ASP.NET Core Bootstrap Controls
[Expand]WPF Controls
[Expand]Xamarin Controls
[Expand]Windows 10 App Controls
[Expand]Office File API
[Expand]Report and Dashboard Server
[Expand]eXpressApp Framework
[Collapse]eXpress Persistent Objects
 [Expand]Product Information
 [Expand]Getting Started
 [Expand]Feature Center
   Basics of Creating Persistent Objects for Existing Data Tables
   Creating a Persistent Object
   Creating a Session
   Creating an XPCollection
   Custom Collection Types
   Deferred and Immediate Object Deletion
   Explicit Units of Work
   Filtering Basics
   Generating Persistent Objects for Existing Data Tables
   How to: Add Persistence to an Existing Hierarchy by Changing the Base Inheritance
   How to: Add Persistence to an Existing Hierarchy by Using Session-less Persistent Objects
   How to: Connect to a Data Store
   Inheritance Mapping
   Nested Units of Work
   NULL Value Handling Specifics
   Optimistic Concurrency Control
   Pageable Collections
   Property Descriptors
   Relationships Between Objects
   Saving Persistent Objects
   Simplified Criteria Syntax
   Simplified Property Syntax
   Sorting Basics
   Using Explicit Transactions
   Using Transactions
   Value Converters
   Working with Sessions
   XPCollection Concepts
   XPDataView Concepts
   XPO Classes Comparison
   XPView Concepts
 [Expand]Design-Time Features
 [Expand]Member Tables
 [Expand]API Reference
[Expand]CodeRush Classic
[Expand]Cross-Platform Core Libraries
[Expand]Tools and Utilities
 End-User Documentation
View this topic on docs.devexpress.com (Learn more)

How to: Add Persistence to an Existing Hierarchy by Using Session-less Persistent Objects

Using Session-less persistent objects implies that the corresponding class definitions have no session-specific constructors, compared to the other option of adding persistence to an existing class hierarchy which is discussed in the How to: Add Persistence to an Existing Hierarchy by Changing the Base Inheritance topic. Because of this, all persistent operations on the objects can be performed directly via the Session object by calling the corresponding methods.

In the most basic instance of using this technique, all that needs to be done to add persistence to an object is to mark the corresponding class with the PersistentAttribute and provide a key field or property (if there isn't one already defined in the class) which will be used to specify an identity value for a specific object's state. After that, the object can be persisted by calling the Session.Save method and passing the object as a parameter. The default mapping in XPO allows you to persist objects at this early stage but generally, you'll be required to override the default mapping to map to custom tables (views) and columns.

Below are step-by-step instructions on what you need to do.

Expanded Adding the Persistent Attribute and Customizing the Default Mapping

By adding persistence to an object you also need to determine which properties or fields of the object are to be stored and the mapping and format options that should be applied. With XPO, this can be carried out by marking the required classes, properties and fields with the following attributes:

  • PersistentAttribute. Use this attribute to specify whether a class, property or field should be stored. By default, XPO automatically designates database tables (views) and column names for the objects being persisted. You can pass the relevant name as a parameter to this attribute to override the default mapping.
  • PersistentAliasAttribute. Use this attribute to specify the association between a field and a property. The property's value is stored by persisting the corresponding field.
  • NonPersistentAttribute. Mark a property or field with this attribute to prevent it from being persisted.
  • SizeAttribute. Mark a property or field with this attribute to specify the format size of the database column which will be created for it.

The following code example demonstrates how persistence options can be specified.

Expanded Implementing an Object Identity Value

To distinguish the states of persistent objects stored in a database, an object identity value should be used. It is used to address a specific object's state. In the following code example one possible implementation of identity values is shown. In a database it will be represented by an auto-generated key field of the integer type.

Expanded Manipulating Session-less Persistent Objects

A session-less persistent object represents a standard persistent object in regard to the functionality. The only exception is that it doesn't implement the IXPSimpleObject interface, thus all the persistent operations such as saving, reloading and deletion can be initiated only by the Session object or the default session as shown in the following code snippet.

Expanded See Also

Is this topic helpful?​​​​​​​