Customizing Serialization of Entities in the ADO.NET Data Services Client Library

Attention! Phani on Deck!

Man vs Code — Fri, 12 Dec 2008 21:23:44 GMT

One of the most common feature requests we hear for Astoria is the ability to mark properties on an entity

re: Customizing Serialization of Entities in the ADO.NET Data Services Client Library

Keoz — Sat, 28 Mar 2009 06:02:21 GMT

You know this completes the circle since whe can partialize a data entity to implemente INotifyPropertyChanged and we can mark an attribute to dont be part of the context we now really can customize and use a data entity in business layer so we dont need extra classes to achieve this, thats one of the many things i love data services, great post! thank you!!

re: Customizing Serialization of Entities in the ADO.NET Data Services Client Library

Charles — Thu, 23 Apr 2009 02:02:08 GMT

This is a very cool idea, but I'm curious if it can be used on a field in an ADO.NET entity model? If so, how would I set a field there to have the DoNotSerialize property?

re: Customizing Serialization of Entities in the ADO.NET Data Services Client Library

PhaniRajuYN — Thu, 23 Apr 2009 04:24:24 GMT

Hi Charles,

This property is client-side only.

By design , the server does not expose any events for us to hook in and change the markup .

Which scenario are you trying to solve with this ?

-Phani

re: Customizing Serialization of Entities in the ADO.NET Data Services Client Library

John Allen — Tue, 12 May 2009 19:12:06 GMT

I may be missing something but I'm trying to use this in a Silverlight project and my derived class that inherits from DataServiceContext is auto generated for my Service Reference. If I update the code that defines my Service Reference to inherit from my new custom class it is simply blown away the next time I refresh the service.

What am I missing?

re: Customizing Serialization of Entities in the ADO.NET Data Services Client Library

PhaniRajuYN — Fri, 22 May 2009 05:29:38 GMT

Hi John,

You are right . I wanted to update this blog entry to use a partial class instead of an inherited class for a long time .

Using a partial class preserves this code in another code file and doesnt get affected if you re-generate the client proxy classes.

-Phani

re: Customizing Serialization of Entities in the ADO.NET Data Services Client Library

Pedro Garces — Wed, 15 Jul 2009 19:19:47 GMT

I was having the same issue with ADO.NET Service generated classes that we wanted to extend (since they are partial classes).

I tried several techniques to do the serialization in order to exclude the newly created (extended) properties to the ADO.NET generated classes, since ADO.NET detects the newly created properties; which causes an exception specifying the NONE existing properties.

Some didn't work, other were very tricky. So I found this solution much cleaner and practical.

The only problem I found was the LINQ code to access the extended properties to remove them from the ATOM Payload, doesn't work anymore. The methods to process the Lambda expression don't exist or the version I have in silverlight is different. So I fix it this way to eliminate a propertyname (string):

XName xNameProperty = XName.Get(propertyName, rootElement.GetNamespaceOfPrefix("d").NamespaceName);

//Get descendants for xNameProperty object within ALL xElements

IEnumerable<XElement> PropertyElements = rootElement.Descendants(xNameProperty);

//Initialize variable

XElement elementxHasProperty = null;

//Find xElement for the searched propertyName

foreach (XElement element in PropertyElements)

{

//Verify if it is the property looked for

if (element.Name.LocalName == xNameProperty.LocalName)

{

elementxHasProperty = element;

break;

}

//Verify if the propertyName was found to remove the property from being sent to ADO.NET Services

if (elementxHasProperty != null)

elementxHasProperty.Remove();

Thank you so much for your guidance