CRUD using Silverlight 2 Beta1, WCF and LINQ to SQL Part2

Swiss MSDN Team Blog : CRUD operations with Optimistic Locking using Silverlight 2 Beta1, WCF and LINQ to SQL (inserts, updates and deletes)

Fri, 11 Apr 2008 14:16:00 GMT

PingBack from http://blogs.msdn.com/swiss_dpe_team/archive/2008/04/04/crud-operations-with-optimistic-locking-using-silverlight-2-beta1-wcf-and-linq-to-sql-inserts-updates-and-deletes.aspx

re: CRUD using Silverlight 2 Beta1, WCF and LINQ to SQL Part2

ernow — Mon, 14 Apr 2008 08:13:37 GMT

Hi,

I really like the ideas presented here (although I'd encapsulate them more in a DataSet kind of class)

One thing I do not understand is why you use a shallow copy. Shouldn't it be a deep copy? Or am I not understanding how this works?

Erno

re: CRUD using Silverlight 2 Beta1, WCF and LINQ to SQL Part2

ronnies — Mon, 14 Apr 2008 12:20:19 GMT

Hi Erno,

Thanks for the comment.

At first I have thought also about doing an encapsulation class a la DataSet. But I also wanted to make the WCF contract strict and not something like a DataSet that can contain any arbitrary number of tables that you can’t figure out when looking at the contract. I also wanted to keep the plain Objects that LINQ to SQL generates. It is a philosophy discussion both are valid option with both pro and cons.

Regarding the deep vs. shallow in my example is a deep copy of the List collection (table) but a shallow copy of the Customer object (rows). So if Customer object has an Order collection I’m not doing any deep copy of the Order collection. It was a choice to keep things simple and to avoid having nested collection. Design was to have separated entities like DataTables in DataSet to avoid complex looping code server side and Eager loading challenges on the reads. So the right name should be a DeepShallowCopy:-)

ronnie

re: CRUD using Silverlight 2 Beta1, WCF and LINQ to SQL Part2

ernow — Tue, 15 Apr 2008 11:52:23 GMT

Thanks Ron for clarifying.

I agree on the keeping the WCF contract strict. All I would do is tidy up the client and server code. There is too much knowledge in the methods about the way concurrency is handled. So I would encapsulate in a DataSet class but on the wire it would look the same.

I understand your Deep vs. Shallow explanation but in a way it breaks the principle to have plain objects (or rather an object model) so you're back to a DataSet structure while you wanted to avoid that.

To make it clean you could consider all plain objects to have a way of keeping their original state.

New Posts Coming Soon...

Scott Morrison — Tue, 03 Jun 2008 02:08:37 GMT

You might have noticed that posts have dropped off over the last month or so.  The reason being