LINQ to SQL: Stories of love and hate

So, we are trying to figure out in which ways the LINQ technologies can make our apps better, and our life as developers easier.

As a whole, there's no doubt the new language extensions in .NET 3.5 and the LINQ concepts are a hit. Once you find you can use the same syntax / extensions for every possible collection in your app and happily forget all those boring APIs like DataView.RowFilter or Array.Sort, there's no return. And this is just the tip of the iceberg, considering the potential of the new language extensions.

The plot thickens, however, when you focus on the LINQ to SQL current implementation (.NET Framework 3.5 and VS 2008 release versions). After spending many days trying to find the place for LINQ to SQL in a layered application architecture, I came up with a mix of happiness and frustration which I will share here - even at the risk of being overly simplistic.

Love:
The magic of expression tree evaluation that turns a multi-step query expression into a single Transact-SQL statement

Hate:
The fact that the query output - when not projecting into new types - is always a collection of items tied up into the data context, not able to be detached and sent up and down the layers of a multi-tier app. And this is by design, acording to Dinesh Kulkarni's post.

Love:
The inclusion of an O/R designer in the VS IDE, with good enough capabilities for mapping table schemas to a DBML markup.

Hate:
The O/R designer inability to figure out the stored procedure return schema in all but the more trivial cases (single fixed resultset)

------------

Am I not being fair if I don't mention the wonders of the data context SubmitChanges behavior?

Well... being focused on enterprise architectures, the concept of a single happy application committing changes into the DB all the way from the front-end to the back-end is not my preferred scenario. That's why I'm more concerned about interacting with stored procedures, and using LINQ to SQL to get detached entities or DTOs.

So maybe the problem is that I'm trying to inject this technology in a scenario for which it has not been built?

Let's see. Some portions of LINQ to SQL  definitely may fit in a layered application architecture. But the whole combo (O/R designer + code generation tool + System.Data.Linq classes) is too large a bite, and the key may be to take apart it's pieces.

Time to go back to the lab! More on this to come soon...