docs/geode-native-docs-dotnet/serialization/dotnet-serialization/archive/dotnet-data-serialization-options.html.md.erb

<a id="data-serialization-options"></a>
## Data Serialization Options

Built-in .NET types are serialized automatically into the cache and can be retrieved by Java servers and other <%=vars.product_name%> clients. For domain objects that are not simple types, you have three <%=vars.product_name%> serialization options.

The options give good performance and flexibility for data storage, transfers, and language types. The <%=vars.product_name%> options can also improve performance in serializing and deserializing built-in types.

The simplest option is to use automatic serialization by registering the <%=vars.product_name%> .NET PDX reflection-based autoserializer in your application. When you have this registered, <%=vars.product_name%> uses it for all domain objects that are not custom serialized.

You can also custom serialize your objects by implementing one of the <%=vars.product_name%> .NET interfaces, `Apache.Geode.Client.IPdxSerializable` or `Apache.Geode.Client.IDataSerializable`.

In addition, You have the option of using default .NET serialization, but you cannot use it unless you also use helper classes. The helper classes you must use are `CacheableObject` and `CacheableObjectXml`.

<%=vars.product_name%> .NET PDX serialization has more bytes in overhead than <%=vars.product_name%> .NET Data serialization, but using PDX serialization helps you avoid the performance costs of deserialization when performing queries. Applications can use `PdxInstances` in functions to avoid the deserialization of entire objects.

<a id="concept_6DC3DD288F6C4190AEA07DEDE76DD867__table_D61A94C4BFBE4712835F632F30BB488E">Serialization Options—Comparison of Features</a>
<table>
<colgroup>
<col width="33%" />
<col width="33%" />
<col width="34%" />
</colgroup>
<thead>
<tr class="header">
<th>Capability</th>
<th>IDataSerializable</th>
<th>IPdxSerializable and PDX reflection-based autoserializer</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td><p>Handles multiple versions of domain objects*</p></td>
<td></td>
<td>X</td>
</tr>
<tr class="even">
<td><p>Provides single field access on servers of serialized data, without full deserialization. Supported also for OQL queries.</p></td>
<td></td>
<td>X</td>
</tr>
<tr class="odd">
<td><p>Automatically ported to other languages by <%=vars.product_name%> - no need to program Java-side implementation</p></td>
<td></td>
<td>X</td>
</tr>
<tr class="even">
<td><p>Works with <%=vars.product_name%> delta propagation</p></td>
<td>X</td>
<td>X (See explanation below.)</td>
</tr>
</tbody>
</table>


\*You can mix domain object versions where the differences between versions are the addition and removal of object fields.

By default, you can use <%=vars.product_name%> delta propagation with PDX serialization. However,
delta propagation will not work if you have set the <%=vars.product_name%> property `read-serialized`
to `true`. To apply a change, delta propagation requires a domain class
instance and the `fromDelta` method. If you have set `read-serialized` to `true`, you will receive an
`IPdxInstance` instead of a domain class instance, but `IPdxInstance` does not have the `fromDelta`
method required for delta propagation. You will also require a Java domain class on the server
similar to your .NET PDX Delta domain class.