N-Tier and Remote Applications with LINQ to SQL
You can create n-tier or multitier applications that use LINQ to SQL. Typically, the LINQ to SQL data context, entity classes, and query construction logic are located on the middle tier as the data access layer (DAL). Business logic and any non-persistent data can be implemented completely in partial classes and methods of entities and the data context, or it can be implemented in separate classes.
The client or presentation layer calls methods on the middle-tier's remote interface, and the DAL on that tier will execute queries or stored procedures that are mapped to DataContext methods. The middle tier returns the data to clients typically as XML representations of entities or proxy objects.
On the middle tier, entities are created by the data context, which tracks their state, and manages deferred loading from and submission of changes to the database. These entities are "attached" to the DataContext. However, after the entities are sent to another tier through serialization, they become detached, which means the DataContext is no longer tracking their state. Entities that the client sends back for updates must be reattached to the data context before LINQ to SQL can submit the changes to the database. The client is responsible for providing original values and/or timestamps back to the middle tier if those are required for optimistic concurrency checks.
In ASP.NET applications, the LinqDataSource manages most of this complexity. For more information, see LinqDataSource Web Server Control Overview.
The following illustration shows the basic architecture of an n-tier application that uses LINQ to SQL in the data access layer.
.png "LINQ to SQL N-Tier Architecture")
Additional Resources
For more information about how to implement n-tier applications that use LINQ to SQL, see the following topics:
For more information about n-tier applications that use ADO.NET DataSets, see N-Tier Data Applications.