Try asking about a definition for LINQ-to-SQL. Is it an API for building .NET-based data access layers? Is it a poor man's Object/Relational Mapper (O/RM) tool? How does it relate to LINQ and querying? Is it heralding a new trend that may end up replacing T-SQL entirely?
In the end, LINQ-to-SQL can be correctly seen both as a data access layer technology and as a simple—but effective—O/RM tool. Confusion about the role of LINQ-to-SQL arises from the fact that LINQ-to-SQL is much richer than a plain database API (like ADO.NET), but not as functionally rich as a regular O/RM tool should be.
First It Was Just LINQ...
LINQ, short for "Language Integrated Query," is only about queries. However, queries require collections of data to search on. In .NET 3.5, LINQ provides a query object model through which you can formulate queries dynamically, then run them against a collection of data. In addition, C# and Visual Basic.NET have been extended with context keywords that map directly to some elements of the underlying query object model. But LINQ-related features in C# and Visual Basic.NET are merely syntactic sugar—the juice is all in the classes in the .NET Framework.
The LINQ query object model is designed to run queries against enumerable collections of data, or against any data source that looks like an enumerable collection of data. An array is an in-memory collection of data. In .NET, the array class implements IEnumerable and, as such, is a natively enumerable type. For instance, an XML document is a disk file. Once loaded in memory, it can be exposed as an enumerable collection of nodes. Some extra work is required to parse the XML document into a collection of nodes and map the query object model onto the collection of nodes. To enable LINQ to query on XML data, an extra object model is required—LINQ-to-XML. This XML-specific object model primarily supplies a contracted interface—IQueryable—to plug into the LINQ query object model. Additionally, it provides facilities to let you edit the content of XML documents. In the end, LINQ-to-XML is an API for working with XML documents that also fully support LINQ for queries. LINQ-to-SQL follows the same model.
LINQ-to-SQL is an API for working with data in a SQL Server database and fully supports the LINQ syntax for running queries. The LINQ-to-SQL API consists of an object model that represents a subset of the tables in the specified database. In LINQ-to-SQL, you provide a connection string and Visual Studio 2008 automatically builds the object model for you for all the specified tables. For example, if you pick up the Customers table, then the Visual Studio 2008 wizard provides a Customer class whose properties match the columns on the table. The final result is a table-centric object model. The LINQ-to-SQL object model supports the IQueryable interface, which makes it pluggable into the LINQ query model. Consequently, a LINQ-based query that targets a LINQ-to-SQL collection of data is transformed into a T-SQL query and executed. Results are then loaded into in-memory object collections and returned to the application. The LINQ-to-SQL object model also features facilities to write data to underlying tables—which makes it a tool for creating a data access layer. At the same time, the ability of transparently persisting objects to relational tables (as well as some inherent capabilities of the object model) makes LINQ-to-SQL look a lot like an O/RM tool.
Who's LINQ-to-SQL For?
Is LINQ-to-SQL for .NET developers doing database stuff, or SQL Server experts who spend their time writing, maintaining, and fine-tuning stored procedures and indexes? Is LINQ-to-SQL a tool that diminishes the role of handcrafted T-SQL code? Are T-SQL skills a thing of the past? Should we just take the T-SQL code that LINQ-to-SQL generates under-the-hood without any possibility of intervention?
LINQ-to-SQL is not here to kill T-SQL and related skills; LINQ-to-SQL is here to help. But it is a tool that heralds upcoming radical changes in the development of multitier systems. The more we move towards an object-oriented design of the business logic, the more we need powerful tools to smooth the subsequent object/relational impedance mismatch. LINQ-to-SQL may not be the perfect tool for the purpose, but its introduction should be seen in this perspective.
The real question is whether you're okay with a table-based representation of data. Are you fine working with recordset-like data structures? Is it okay for you to implement CRUD and query services with a mix of stored procedures and ADO.NET-based business components? If the answer is "yes," then you probably don't need LINQ-to-SQL.
But if your answer to the previous question is "No, I would really like to employ objects to represent my problem's domain," then LINQ-to-SQL is the first step in a new direction. LINQ-to-SQL uses T-SQL under-the-hood, but leaves room for customization. As a SQL Server expert, you should be looking at LINQ-to-SQL internals to see where you can intervene to improve things. LINQ-to-SQL may become your best friend and a higher level tool to work with.
