An Avanade Blogging Community

In search of a solution to how LINQ to SQL should be used in an N-tier application architecture with a smart client and WCF distribution I have come across the following links:

Ian Cooper: http://codebetter.com/blogs/ian_cooper/default.aspx, especially part 8: Architecting LINQ To SQL Applications, part 8

All of Ian's parts should be returned by this search.

MSDN:

• LINQ to SQL N-Tier with Web Services
• Learning by Walkthroughs (LINQ to SQL)

ScottGu (a bit old but still useful background data for LINQ):

• Using LINQ to SQL (Part 1)
• LINQ to SQL (Part 2 - Defining our Data Model Classes)
• LINQ to SQL (Part 3 - Querying our Database)
• LINQ to SQL (Part 4 - Updating our Database)
• LINQ to SQL (Part 5 - Binding UI using the ASP:LinqDataSource Control)
• LINQ to SQL (Part 6 - Retrieving Data Using Stored Procedures)
• LINQ to SQL (Part 8 - Executing Custom SQL BLOCKED EXPRESSION
• LINQ to SQL (Part 7 - Updating our Database using Stored Procedures)
• LINQ to SQL (Part 9 - Using a Custom LINQ Expression with the <asp:LinqDatasource> control)

Matt Warren

• IQueryable’s Deep Dark Secret
• The Origin of LINQ to SQL

DinnerNow.NET v 2.5 for VS2008 and .NET 3.5

Visual Studio 2008 Training Kit available here

A profound discovery after reading all of this is the following (taken from Ian's blog, emphasis mine):

... This suprises some people because they are used to working with DataSets, which formed a unit of work, and were serialized with both the old and current state of the rows they contained, allowing the updates to be played through a DataAdapter when they were passed back to the middle tier. LINQ To SQL does not support this model 'out-of-the-box'. This tends to shock people who expect that the features of DataSets should somehow extend to LINQ To SQL.