Entity Framework and XmlIgnoreAttribute

Question

Say that you have one single link in your entity model. The code generator will decorate it with the following attributes:

[global::System.Xml.Serialization.XmlIgnoreAttribute()] [global::System.Xml.Serialization.SoapIgnoreAttribute()] public RelatedObject Relationship { get {...} set {...} } 

I want to serialize a parent object along with all its properties for which data has been loaded through an XML web service. Obviously, these related properties do not become serialized due to these attributes.

So, for my purposes, I just want to remove these “don't serialize me” attributes. I can find and replace in the designer code, but any modifications that I make in the designer will return these attributes.

In my request, I am .Include () ing and explicitly load only the child objects that I need for serialization. Therefore, I will be sure that there are no round dots in my request. Some child properties are not required, so I won’t include () them, so they won’t be serialized.

How can I achieve what I want? Make a separate call from my application for each child? Let's say I return hundreds of parent objects; I would have to make hundreds of separate calls to get each child.

How can I finally get rid of these attributes?

VS 2008 / EF 3.5.

Answer 1

Here is a little known fact ... Entity Framework + Web Services =: '(

There are three (3) approaches that can be taken to solve your problem (namely, the problem of serializing an XML diagram ... or its absence).

I will list each approach in order of least development time and complexity of the required implementation ["Bang-For-Buck"] versus scalability, maintainability, and performance ["Future Proofing"].

• Create POCO classes for each object to project when sent by wire. This is the easiest (and monotonous) approach, but solves your problem. I included a sample at the end.

• Use WCF to transfer your data. Entity Framework and WCF are like "brothers from another mother." They were designed to work together, but share their differences. You will notice that all Entity Objects created by EF, inherently [DataConctract] with all fields, are [DataMember]. This allows you to use WCF DataContract Serializer with handle graphs very efficiently and maintains an object reference even after deserialization. The WCF DataContract Serializer also proved to be 10% faster than the standard default XML serializer.

• Use EF 4.0 Self Tracking Entities (STE). It is still very new, but it is workable. In Visual Studio 2010, you are given the opportunity to generate self-monitoring objects that are designed for the N-level and SOA. The best thing about STE is the use of T4 Transformed Text templates to generate code. The classes created by T4 are clean and very malleable, giving you plenty of room to insert your logic and test. There is a link to the STE tutorial to get started.

Good luck and hope you find the best approach for you.

POCO example.

 public class CustomerPOCO { public int ID { get; set; } public string Name { get; set; } public List<SubLocationPOCO> SubLocations { get; set; } // ... #region Ctors public CustomerPOCO() { } public CustomerPOCO(Customer customer) { // Inits if (customer.SubLocations != null) SubLocations = customer.SubLocations.Select(sl => new SubLocationPOCO(sl)).ToList(); } #endregion } public class SubLocationPOCO { public int ID { get; set; } public string Name { get; set; } #region Ctors public SubLocationPOCO() { } public SubLocationPOCO(SubLocation subLocation) { // Inits } #endregion } 

And your [WebMethod] is something like this.

 [WebMethod] public CustomerPOCO GetCustomerByID(int customerID) { using (var context = new CustomerContext()) { var customer = (from customer in context.Customers.Include("SubLocations") where customer.ID == customerID select new CustomerPOCO(customer)).FirstOrDefault(); return customer; } } 

Answer 2

Just don't do it. It's simple.

You indicate on your post that you want to serialize the parent of your object, right?

Now let's see what happens when you do something like this ...

• The serializer starts transforming your object and its properties
• When it finds the parent of your object, it starts to serialize it
• When the parent is serialized, if it finds the child that it serialized, and returns to 1.

And he will never come out without any support.

So these attributes exist for a good reason.

Answer 3

Paulo is right (+1), but he did not tell you how to fix this problem. Since serializing XML is a legitimate precedent, even if serializing entities is the wrong way to do this.

Project on anonymous types and serialize it. For example, for serialization in JSON, I:

 var q = from e in Context.MyEntities where // ... select new { Id = e.Id, Children = from c in e.Children select new { Id = c.Id, // etc. }, // etc. }; return Json(q); 

This does not guarantee circular links, etc., and it works.