LINQ to SQL with Tightly-Coupled Client-Server Applications
LINQ to SQL can be used on the middle tier with tightly-coupled Smart Clients on the presentation layer. In scenarios that involve read-only data access, no optimistic concurrency checks, or optimistic concurrency with timestamps, there is not much more complexity than with non-remote scenarios. However, when a database requires optimistic concurrency checks with original values, LINQ to SQL does not provide the level of support for round-tripping of data that you find in DataSets. However, a LINQ to SQL middle tier can exchange data with clients on any platform.
LINQ to SQL in Visual Studio 2008 provides no infrastructure for tracking entity state after they have been serialized to a client. LINQ to SQL enables service-oriented architectures where interactions between the data and presentation layers are small and relatively atomic, but does not perform any round-tripping of original values. Therefore, if you want to use a tightly-coupled Smart Client with LINQ to SQL, and a database uses optimistic concurrency with original values, you will have to implement your own mechanism for communicating changes between the presentation tier and middle tier. It is up to the system designer to decide whether it makes sense to do this bit of extra work in exchange for the benefits that LINQ to SQL provides on the middle tier. On the other hand, if the database has timestamps, then there is no need for custom change-tracking logic.
See Also
Concepts
N-Tier and Remote Applications with LINQ to SQL
LINQ to SQL N-Tier with Web Services