LinqDataSource vs ObjectDataSource vs SqlDataSource
With ASP.NET 3.5, a new data source control joins the company: the LinqDataSource control. How does it position itself in the grid of data source controls?
The difference between SqlDataSource and ObjectDataSource is fairly clear. The first leads you to add SQL code directly in the markup of ASP.NET pages, which is not certainly a practice to recommend even though the resulting page will still work great. ObjectDataSource is right the opposite. It pushes the use of objects and makes the binding between data-bound controls and data sources happen through made-to-measure objects. In most cases, the objects bound to ObjectDataSource won’t be just the top layer objects of your business tier. But ObjectDataSource allows you to preserve—and, to a good extent, it mandates you to have—a well designed business tier.
What about LinqDataSource, instead? To me, it falls somewhere in between the other two.
I should have read somewhere that one of the advantages of LinqDataSource over ObjectDataSource is that it doesn't require you code manually the source of the classes in the object model. Uhmmmm. Tell me, what's your priority being a developer/architect?
If you're simply trying to save yourself a few hours of development, aiming at a longer weekend home with the family, then by all means pick up the LinqDataSource control. If, instead, your priority is the overall design of the application, then just forget about LinqDataSource; just as much as you should have forgotten about SqlDataSource.
To enable Linq-to-SQL (and subsequently LinqDataSource), you necessitate to create a data model—better if through the O/R designer embedded in Visual Studio 2008. This data model is rooted in a data context class and contains initially only data container classes, with data properties but no behavior. The idea behind LinqDataSource is that you use the auto-generated object model to manage data and provide any required behavior through direct injections of Linq-to-SQL commands. As you can see, the pattern behind LinqDataSource and SqlDataSource is nearly the same. The only difference is the language you use: Linq-to-SQL in one case, raw SQL in the other. Another key difference that must be noted between SqlDataSource and LinqDataSource is that SqlDataSource can accommodate any relational data source, whereas LinqDataSource is limited to SQL Server.
The purposes of LinqDataSource and ObjectDataSource are clearly different. ObjectDataSource enables you to take advantage of RAD data binding on top of your existing middle tier. LinqDataSource and related tools give you instead a quick way to build an extremely thin and to some extent, anemic, object model that, in addition, can hardly be deployed on a physically different tier.
The bottom line that I see here is that you should only consider ObjectDataSource for enterprise class applications and wherever the complexity of the domain model is significant. LinqDataSource is a much smarter replacement for SqlDataSource with the current technological limitation of being limited to SQL Server.
This said, I wouldn't bother using either SqlDataSource or LinqDataSource for applications with a very simple domain model, a trivial business logic, or just in the context of temporary pages that are to be quickly arranged and just work.
Using Linq-to-SQL in the Data Access Layer is all another story, instead. As long as your data store is SQL Server, Linq-to-SQL may be an excellent replacement for T-SQL and its underlying data model returns objects rather than tables as in VS 2005 table adapters. This is much more powerful and easy to maintain. But the interface towards the middle tier must still be rendered using contracted data transfer objects leaving the middle tier in charge of talking to the presentation and ASP.NET pages. If you intend to use data source controls for this, ObjectDataSource is the only option you have.