views:

1186

answers:

2

I am serialzing a linq object through WCF. The dbml is setup for unidirectional serialization.

My objects are pretty simple: Budget has a collection of BudgetLineItems. Each BudgetLineItem has an ItemCateogry.

Budget/BudgetLineItems are serialized fine. ItemCateogry on each BudgetLineItem do not, however. I noticed by default, linq didn't add a [DataMember] on ItemCategory for each BudgetLineItem. I added it manually, and also removed any possible circular reference on the ItemCategory entity with [IgnoreDataMember]. Not luck, however.

questions:

  1. Can wcf, by default, serialize many-to-one relationships, or am I just missing something? I know the serialized data would be rather redudant with duplicated ItemCategory data for each BudgetLineItem, but that is fine.

  2. Do I need to do a custom DataContractSerializer for this?

** EDIT ** Actually, that did work (adding [DataMember]), I just didn't update the service reference on the client (duh).

NEW QUESTION: Is there a way to tell the linqtosql designer to maintain those [DataMember] and [IgnoreDataMember] fields on an entity that the designer is generating? otherwise I'll need to update them everytime I save the dbml.

+1  A: 

you shouldn't send linq entities with WCF. Instead make your own business datamodel and send those over the wire. If you ever change your database you don't want to change every program that connects with your service

MichaelD
agreed, but for the purpose of this particlar item, we're trading that off.
ericvg
+1  A: 

Wow you successfully serialized your LINQ 2 SQL objects for WCF?

When I tried this (very reluctantly, see below as to why) it really fell over, there were relationships in my L2S entity pointing to children, and then the child pointing back to the parent and obviously when enumerating for building the WCF object, it could not traverse the tree infinitely in this fashion and [to the best I remember] it resulted in an overflow exception, so what I am basically saying is beware if you go down this road!

Following up on Michael's post, I would suggest transforming your WCF objects to POCO's (custom model representation). I'm kind glad the above did not work, as I would always prefer to make a custom WCF object which transports a clean subset of data, exactly what the WCF request needs and it then doesn't include a stack of superfluous data to be sent across the data, and I'm sure your L2S entities have lots of it. The actual reason I tried sending my L2S data directly across the wire was because I had to make an engine which employed certain 'rules' these rules were stored in a correlation of about 4 database tables with relationships and it was not viable to upkeep a separate WCF object.

So in the end what I ended up doing was extending custom code gen classes to include Wcf.cs with [DataContext] and then cloned property for property the L2S classes -> WCF custom classes.

It worked perfectly in the end and this is the cloning procedure I used with instructions on my blog.

I am happy with this and don't feel there is bad practice involved. Hope this helps.

GONeale
Thanks for the info. For successful serialization, we had to add a [DataMemberIgnore] to any prop that was recursive (usually the reference back to the parent), since those won't serialize. That invovled changing the dbml, which of course will be overwritten on every change. It works, but not very seamless. As you know, the serialized objects are _huge_.thankfully, this was only for a proof of concept (SQLRS2008 consuming a WCF layer to our services to rid us of redudant logic)
ericvg
OK no prob. Well check out my cloning procedure, hopefully that route will help you.
GONeale