WCF DataContract/DataMember serialization to BSON

[John Volkar]

Let's say that I have a set of WCF DataContract's each with a
specifically annotated DataMembers, but each *also* having properties
which are NOT marked as DataMembers (e.g. they are "syntactic sugar"
to give easy access to derived values computed from other
DataMembers).

My question is: When serializing a DataContract object with non-
DataMember properties to be stored in mongodb, should I make an effort
to NOT store the derived properties? (By fiddling with the class-
mapper I guess?)

I guess I'm still stuck with my head back in SQL land, where my
inclination is to only store the raw/source properties... But I think
those in the mongodb world would maybe suggest that storing the
derived fields themselves would give query flexibility at the expense
of storage space?

I guess the "right" answer is "it depends", but I am hoping someone
out there has thought through and has experience/advice about using
WCF DataContract objects as the "unit of serialization" in a mongodb
backend.

Background: We have a system where WCF services are the basic
building block. Some of the DataContract objects passed around are
backed by objects which are stored in a traditional SQL database (we
use NHibernate there). We are considering exploring a no-SQL
database for some analytics work, and some of the the various WCF
objects are "pretty much" what we would want to store. I do NOT want
to add a "3rd tier" of data classes just for storing in mongodb (we
already have POCO's that map to NHibernate/sql-tables and have WCF
DataContracts to pass between services). At some point too many
differing representations of the same data starts to feel "wrong". I
am hoping that the WCF classes can just be "used-as-is" with mongodb.

Further background: NOTE: we do NOT use proxy classes which are
reversed from WSDL, so the non-DataMember properties remain available
on all object instances in all services. We use a common type library
that all services directly reference so that we can avoid the mess
involved in updating service references all the time.

Any one out there using WCF services and the DataContract classes as
the unit of serialization into a mongodb backend?

Regards,
John Volkar

[Robert Stam]

You can certainly get the C# driver to serialize your WCF
DataContracts they way you would like them to be.

One option is to double annotate your classes with both DataContract
attributes and BsonSerialization attributes. The main difference is
that DataContract is an opt-in serializer while the BsonClassMap
serializer is an opt-out serializer. So basically you would mark the
properties you don't want the C# driver to serialize with [BsonIgnore]
attributes.

If you don't want C# driver attributes in your DataContract classes
you can also set up the class map with code, though since it sounds
like you control you DataContract classes it would be easier to just
use attributes.