As we are not Microsoft marketers, we tend to see the cons of the products that Microsoft builds. As every product has its flaws, of course Linq to SQL is no exception. Here is my list of the things that I compiled from various sites & forums or hit a limitation block by myself:

A) Architecture

1 – Enabled Provider Model & More providers than SQL

Since Matt Warren has explained in his blog post that LINQ to SQL supported multiple providers internally, but it was disabled for some “non-technical” reasons there is an unstoppable desire in each of us to see it enabled in the next version. (I am not even asking for Persistance Ignorance)

2 – Fully Mockable, A Design by Contract Framework

If this happened, we wouldn’t look for hacks like this one. I want to be able to mock DataContext out without doing any funky tweaks.

3 – A Disconnected Data Context

I can not remember how many times I have seen this everywhere. This DataContext will be able to be serialized & deserialized somewhere and even if it is dead, we should be able to benefit from Object Tracking and Deferred Loading.

By this I mean a stateless DAL, where I don’t have to say “delete these children” or “update these but not these”.

4 – Support for more inheritance models

Currently only Table per Hierarchy model is enabled, multiple entities constituting 1 table or vice versa are not.

5 – Out of the box many to many relationships

Title explains, as we currently can’t do this mapping.

6 – Batch Statements Execution

Currently Linq to SQL sends multiple queries to the DB if an operation needs it. A batch statement like NHibernate’s would have been more than cool.

7 – More control on the resulting statement

Advanced users should be able to sneak in the generation or submission process – like the interceptors in NHibernate again.

B) Tools and Designer

1 – Code generation into different structures

The ability to separate each entity and DataContext into different files or assemblies. Partial files do not let us reside our extensions in different assemblies.

2 – Make DBML designer support giving Entity Base Class

SQL Metal has this, so why does the designer not?

3 – Make DBML designer support external mapping

Again, this is a SQL metal specific “magic”.

4 – Enable partial generation in SQL Metal

Sometimes we human beings do not want to generate all the database, just one table for instance.

This is usually followed by a request on being able to “refresh” an object on the design surface. I don’t know anybody who fancies to delete & drop from connection explorer each time something is changed in the db and loose custom associations.

It would also be good if user changes to designer are kept, not overridden everytime by the tool (a smart merge may be?).

5 – A tool to generate POCO translators from/to Linq Entities

This could be configured in code or via XML files. Some of us (including me) are using Software Factories to generate them; it would have been nice to have an out of the box support in Visual Studio.

That’s all I can remember of at the midnight. What would you like to have in this list apart from these?