A demanded feature on our Ideas and Feedback portal is the out-of-the-box ability to generate persistent classes that can be serialized, and here it is in Telerik Data Access Q2 2014. Currently, when you modify your domain models through the Model Settings dialogue, the Code Generation tab, you can choose whether the classes should implement the ISerializable interface, and if so how to handle the serialization of the navigation properties.
Furthermore, the same options are available to you during the generation of new models, on the Advanced Options dialogue of the New Domain Model wizard, and the New Fluent Model wizard.
If you choose the default settings, the persistent classes will be decorated with the SerializableAttribute and will implement the ISerializable interface in the ISerializable Implementation region.
In addition, thanks to two partial methods: CustomizeSerializationProcess() and CustomizeDeserializationProcess(), the Telerik Data Access code generation capabilities provide you with flexibility that allows you to customize those processes applied on the persistent classes. Implementing them in partial classes when needed would make it possible to specify exactly which persistent classes should be serialized with their navigation properties.
You can also serialize a custom subset of persistent properties by inheriting the persistent classes and overriding the automatically generated implementation of the GetObjectData(). The modification of deserialization process can be achieved in a constructor that takes SerializationInfo and StreamingContext instances as parameters.
For an example of Serializable Data Access entities, you can take a look at the SerializationExample sample in our Data Access Samples repository in GitHub. In it you can find a demo of how to consume a custom subset of persistent properties of a given class through WebAPI and how to bind the JSON result to an ASP.NET AJAX RadGrid.
Ivailo Ivanov is Team Lead in Telerik Data Access