LinqDataSource is a new ASP.NET control in VS2008 that supports using you application’s DataContext to select, insert, update and delete data.
Beyond the Demos
While using this I found the following issues:
1. LinqDataSource (LDS) supports partial selects from Linq objects: e.g. selecting just CustomerID and CompanyName from Customers and not * is okay. However, this only works when doing read-only views – if you want to perform any insert/update/delete you have to select [table].* – this makes sense since LDS needs to construct the full object for any insert/update/deletes. It does however, generate efficient SQL – and will not update all columns if only one has changed.
2. If like me you are using a specialised DataContext, it can be incompatible with LinqDataSource for update/delete/insert operations. LinqDataSource only supports Table<T> objects in the datacontext. I have a modified TableView<T> – and even though TableView supports the ITable interface, and T is the generated LINQ class, it fails.
This problem can be hacked by using the insecure (original) datacontext in the LinqDataSource – this still contains the original Table<T>. However, the table is now insecure for select/insert/update/delete. The select I fixed by handling the LinqDataSource.Selecting() event. There is no obvious solution to fixing the update/insert/deletes at present. One possible approach is to define stored procedures for these functions rather than use the default LINQ-to-SQL behaviour. I’ve yet to test this, and it means writing a lot of procedures I’d rather not write.
3. This leads onto the last wrinkle – retuning Nothing/null to a LINQ query in Selecting event will make LinqDataSource assume you didn’t actually want to override the basic behaviour and will return the default select.