Most Web applications are data-driven and centered on relational databases. However, for years architects have designed applications modeling the domain of the problem through objects. But communication between objects and relational databases has never been smooth and easy. The difficulties that arise when you try to set up this sort of communication are often referred to as "object/relational impedance mismatches" (O/RM). A persistence layer is required to save and load from objects from relational tables. Over the years, a number of design patterns have been defined to provide guidance to architects engaged in this task. Today, developers write this persistence layer entirely on their own or, more often than not, with some help from O/RM tools such as NHibernate or Genome.
While a backend with a domain model and persistence layer is still the most recommended option for complex, large, durable, and enterprise-class applications, it might be too costly for simpler scenarios. And applications that fall under the umbrella of "simpler scenarios" are probably more numerous and used more frequently.
LINQ-to-SQL was created just to address the needs of these applications and provide a powerful, yet simple, set of tools to operate on data stores at a higher conceptual level.
The LINQ-to-SQL framework is specific to SQL Server and, unlike ADO.NET, can't be used to address other relational databases. LINQ-to-SQL is based on the LINQ syntax and is used to query and update an object model built on top of a given database.
LINQ operators such as from, where, and select work on the data context. The data context is a collection of objects created to model the schema of a particular database. In Visual Studio 2008, you find a tool -- the O/R designer -- purposely created to automate the creation of the data model for Linq-to-SQL.
From the programmer's perspective, note that the data context is filled up with data as you access objects programmatically, and any changes to the model (deletions, updates, insertions) are saved back to the database as you call a submit method on the data-context class. Lazy-loading and pre-fetch options give you a way to fine-tune the data loading to optimize the overall behavior of the application.
So what is LINQ-to-SQL and where does it belong? Is it a tool to express the domain model of a system incorporating both logic and persistence? Or is it a sort of object-oriented ADO.NET?
All in all, you can use LINQ-to-SQL for both extremes once you have clear the overall design of your system's backend. In any backend, no matter the complexity, you need logic and persistence. Then, based on the level of complexity of the domain model you decide whether you need a separate persistence layer or perhaps a unique layer of code. LINQ-to-SQL offers an effective domain model (sort of an Active Record) and persistence. In most cases, this is just enough.
In complex, typically enterprise, scenarios LINQ-to-SQL is only an excellent tool to perform physical data access when no O/RM tool is employed. In this case, the objects of the LINQ-to-SQL model are internal to the data access layer and have nothing to do with the domain model in the business layer. In the middle tier, I suggest you use another set of objects to manage entity classes. The middle-tier objects can then use LINQ-to-SQL classes to store data and add methods to expose any requested behavior to the presentation layer. The LINQ-to-SQL objects therefore will be only an object-oriented replacement for T-SQL opaque strings.