[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
[Expand]CodeRush Classic
[Collapse]Cross-Platform Core Libraries
 [Collapse]DevExpress ORM Tool
  [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]DevExpress Data Library
 [Expand]DevExpress Pivot Grid Core Library
 [Expand]API Reference
[Expand]Tools and Utilities
 End-User Documentation

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?​​​​​​​