Transferring LINQ data objects

I am working on a webservice where we use LINQ-to-SQL for our database abstraction. When clients use our webservice, the objects are serialized to XML and all is dandy.

Now we wish to develop our own client that uses the native data types since there's no reason to do objects->xml->objects. However, from what I understand you can't transfer LINQ objects as they directly map to the database and as such the data is "live".

My question is whether there is a way to take a "snapshot" of the data you've extracted, set the LINQ object to "offline" and then transfer it. The data will not be changing after it's transferred to our client and we don't need the database access.

From stackoverflow

• If you're willing to use WCF (for the webservice and the client) you can decorate your Linq2SQL generated classes with the [DataContract] and [DataMember] attributes.

  Check the following links for some guidance:

  • http://msdn.microsoft.com/en-us/library/bb546184.aspx
  • http://msdn.microsoft.com/en-us/library/bb546185.aspx
  • http://www.codeproject.com/KB/WCF/LinqWcfService.aspx
  • http://www.aspfree.com/c/a/Windows-Scripting/Designing-WCF-DataContract-Classes-Using-the-LINQ-to-SQL-Designer/

• The LINQ-to-SQL classes can be used with DataContractSerializer (for WCF) easily enough (you need to enable the serialization property in the designer, though). With this in place, you should be able to share the data assembly with the client. As long as you don't use the data-context, the objects themselves should be well behaved (just disconnected - so no lazy loading).

  The trick is that you need to re-use these types (from the existing assembly) in your serialization code. If you are using WCF, you can do this with svcutil /r, or via the IDE.

  That said though; it is often cleaner to maintain separate DTO classes for these scenarios. But I'm guilty of doing it the above way on occasion.