Many database developers have loudly bemoaned Microsoft’s decision late last year to marginalize LINQ to SQL in favor of its ADO.NET Entity Framework.

The angst played out as many who build applications designed to access Microsoft’s SQL Server felt left holding the bag as reported here. Make no mistake: the Entity Framework is Microsoft’s object relational mapping (ORM) technology of choice and that will become even more evident next year with the release of Entity Framework 4, Visual Studio 2010 and the .NET Framework 4.

Hence there will be no major emphasis on LINQ to SQL from Microsoft other than some fixes and occasional tweaks. To many that decision was an unfortunate turn of events because LINQ to SQL is faster and easier to work with than the Entity Framework, many developers say. And if all you’re trying to connect to is SQL Server, it does the trick, whereas the Entity Framework at some point will become more appealing to those looking to connect with multiple vendors back-end databases.
But there have been some positive developments for those who intend to stick with LINQ to SQL. For example, Microsoft did make some improvements to it in the .NET 4 Framework, as noted Damien Guard, a software development engineer within Microsoft’s Data Programmability Group. Here are the changes to expect when .NET 4.0 arrives:

LINQ to SQL Change List

Performance

• Query plans are reused more often by specifically defining text parameter lengths (when connecting to SQL 2005 or later)
• Identity cache lookups for primary key with single result now includes query.Where(predicate).Single/SingleOrDefault/First/FirstOrDefault
• Reduced query execution overhead when DataLoadOptions specified (cache lookup considers DataLoadOptions value equivalency)

Usability

• ITable<T> interface for additional mocking possibilities
• Contains with enums automatically casts to int or string depending on column type
• Associations can now specify non-primary-key columns on the other end of the association for updates
• Support list initialization syntax for queries
• LinqDataSource now supports inherited entities
• LinqDataSource support for ASP.NET query extenders added

Query stability

• Contains now detects self-referencing IQueryable and doesn’t cause a stack overflow
• Skip(0) no longer prevents eager loading
• GetCommand operates within SQL Compact transactions
• Exposing Link<T> on a property/field is detected and reported correctly
• Compiled queries now correctly detect a change in mapping source and throw
• String.StartsWith, EndsWith and Contains now correctly handles ~ in the search string (regular & compiled queries)
• Now detects multiple active result sets (MARS) better
• Associations are properly created between entities when using eager loading with Table-Valued Functions (TVFs)
• Queries that contain sub-queries with scalar projections now work better

Update stability

• SubmitChanges no longer silently consumes transaction rollback exceptions
• SubmitChanges deals with timestamps in a change conflict scenario properly
• IsDbGenerated now honors renamed properties that don’t match underlying column name
• Server-generated columns and SQL replication/triggers now work instead of throwing SQL exception
• Improved binding support with the MVC model binder

General stability

• Binary types equate correctly after deserialization
• EntitySet.ListChanged fired when adding items to an unloaded entity set
• Dispose our connections upon context disposal (ones passed in are untouched)

Database  control

• DeleteDatabase no longer fails with case-sensitive database servers

SQL Metal

• Foreign key property setter now checks all affected associations not just the first
• Improved error handling when primary key type not supported
• Now skips stored procedures containing table-valued parameters instead of aborting process
• Can now be used against connections that use AttachDbFilename syntax
• No longer crashes when unexpected data types are encountered

LINQ to SQL class designer

• Now handles a single anonymously named column in SQL result set
• Improved error message for associations to nullable unique columns
• No longer fails when using clauses are added to the partial user class
• VarChar(1) now correctly maps to string and not char
• Decimal precision and scale are now emitted correctly in the DbType attributes for stored procedures & computed columns
• Foreign key changes will be picked up when bringing tables back into the designer without a restart
• Can edit the return value type of unidentified stored procedure types
• Stored procedure generated classes do not localize the word “Result” in the class name
• Opening a DBML file no longer causes it to be checked out of source control
• Changing a FK for a table and re-dragging it to the designer surface will show new FK’s

Code generation (SQL Metal + LINQ to SQL class designer)

• Stored procedures using original values now compiles when the entity and context namespaces differ
• Virtual internal now generates correct syntax
• Mapping attributes are now fully qualified to prevent conflicts with user types
• KnownTypeAttributes are now emitted for DataContractSerializer with inheritance
• Delay-loaded foreign keys now have the correct, compilable, code generated
• Using stored procedures with concurrency no longer gets confused if entities in different namespace to context
• ForeignKeyReferenceAlreadyHasValueException is now thrown if any association is loaded not just the first

Potentially breaking changes

We worked very hard to avoid breaking changes but of course any potential bug fix is a breaking change if your application was depending on the wrong behavior. The ones I specifically want to call out are:

“Skip (0)” is no longer a no-op

The special-casing of 0 for Skip to be a no-op was causing some subtle issues such as eager loading to fail and we took the decision to stop special casing this. This means if you had syntax that was invalid for a Skip greater than 0 it will now also be invalid for skip with a 0. This makes more sense and means your app would break on the first page now instead of subtlety breaking on the second page.

ForeignKeyReferenceAlreadyHasValue exception

If you are getting this exception where you weren’t previously it means you have an underlying foreign key with multiple associations based on it and you are trying to change the underlying foreign key even though we have associations loaded.Best thing to do here is to set the associations themselves and if you can’t do that make sure they aren’t loaded when you want to set the foreign key to avoid inconsistencies.

Alternative

One viable alternative to LINQ to SQL is, certainly,  PlinqO, a technology developed by code generation tool supplier, CodeSmith, that brings a bunch of features that we are missing with LINQ to SQL. More about this in some of the next posts.

Sources: visualstudiomagazine.com, damieng.com.