Udostępnij za pośrednictwem

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

  • Artykuł

In this 15 minutes video blog I will explain the magic (or not so magicJ) that I’m doing in the LinqHelper client and server classes for enabling client side change tracking with LINQ to SQL.

If you didn’t watch the first part I encourage you to watch it first: https://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
Attached to the mentioned video blog is the sample code.

Disclaimer:

-          it is not production code, it is a sample to show one approach to change tracking in multi tier architecture with LINQ to SQL

-          there are for sure better solutions and feel free to submit your ideas and improvements.

-          works only with tables with Primary Key as single column

-          works with timestamps or original values

-          it is not fully tested (or better is not tested at allJ) with different tables/data types etc…

Ronnie Saurenmann

 

double click the player to play in fullscreen

Comments

  • Anonymous
    April 10, 2008
    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

  • Anonymous
    April 13, 2008
    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

  • Anonymous
    April 13, 2008
    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

  • Anonymous
    April 14, 2008
    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.

  • Anonymous
    June 02, 2008
    You might have noticed that posts have dropped off over the last month or so.  The reason being