Paulo Pialorsi is co-author of the book “Introducing Microsoft LINQ”, which is downloadable for free (please note that this book has been written for LINQ beta 1, thus some syntax is obsolete now). However, the Programming Microsoft LINQ book is updated to RTM and has an entire chapter dedicated to LINQ and architectures of multi-tier solutions. Paulo wrote a short text for Microsoft Press on LINQ and Architectures:
One of the most frequent questions I get while talking about LINQ with other people is: “What’s the role of LINQ in a distributed architecture?”
In fact a lot of developers think about LINQ as an ORM replacement, however LINQ is not just an ORM, and LINQ is not just LINQ to SQL. LINQ is a new programming model, with a declarative approach, realized through language extensions. LINQ to SQL is just a LINQ flavor, targeting the needs of people who want to have a “simple” and easy to use ORM for Microsoft SQL Server only persistence storage.
From an architectural point of view, LINQ should find its place in many of the common layers of n-tier architectures. For instance you can leverage LINQ as a data layer replacement, using LINQ to SQL or LINQ to Entities. By the way the data layer should continue to return and manage your own domain model entities, in order to be persistence ignorant and independent. Then you can use LINQ to Objects into the business layer, in order to query and handle your domain model entities. Sometime could be useful to be able to query IQueryable<T> set of data within the business layer, in order to leverage LINQ providers (LINQ to SQL, LINQ to Entities, LINQ to YourPersistenceInfrastructure J, etc.) and extracting from the storage exactly what is needed, even if transparently for the business layer. However keep in mind that each query provider can handle a different set of expressions while visiting the expression trees corresponding to LINQ queries to execute. Working with IQueryable<T> in layer higher than the data layer, could be prone to issues and you should take care of this while defining your solutions’ architecture.
In the presentation layer you should leverage LINQ to SQL or LINQ to Entities, just in case you are working on a two-tier (client/server) solution. On the other side you could use LINQ to Objects in order to manage entities and also to make custom data presentation, using anonymous type projection, in order to build “on the fly” Data View Objects to bind to the UI.
The Programming Microsoft LINQ book is for sale at Belgian IT book stores: