| <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. |