I think everyone thinks EF should be great, but it’s too much work for alot of applications. Okay, LINQtoSQL is never going to be LINQtoMySQL or LINQtoOracle… But adding dynamic LINQ into the library as standard, making many-to-many references easier… Okay technically someone might feel that it isn’t LINQ or LINQtoSQL… But the point is that those features would help developers be productive and in my opinion niether of those features contaminate what you’re trying to do. If anything it makes SQL Server more attractive to businesses because when you write applications you don’t need the complexity of EF, but you’re getting most of the benefit.

If it’ll help, with due consideration give the people what they want!

I remember when C# was just released and alot of people asked about optional parameters. I remember seeing someone say, it’ll never happen and I was kind of glad at the time. I had the same fear about ‘dynamic’ keyword too, thats for another time. Now we’ve got optional parameters, I don’t have to write loads of overloads, I quite like it.

I shouldn’t of been so closed minded.

I guess it re-inforces that C# and .NET is there to do a job, it’s not a religion.

Why people expect MS to write products for competing vendors is beyond me.

As for the comments surrounding EF, I agree with the general consensus that EF is about as good for data access, as a piece of feces is good for dinner! It is painfully slow, and the while the idea of abstracting your models for use with different databases is great, EF manages to bugger that up by relying on the clients having the models of the underlying databases! Imagine having 10 clients all using database X, and then trying to migrate to database Y. Instead of the abstraction happening in one place, it is happening on all 10 clients!! ALL of which now need to be updated!!! Obviously that only leaves EF useful as DAL, which in fact turns out to be horrible idea as the compilation is so horribly slow.

Having said that however, I do agree with the approach of not automatically lazy loading data. This can lead to some rather interesting bugs, especially if the context gets disposed between queries.

In certain scenarios where the lazy loading behavior is desirable, it can be easily achieved by extending your entity objects… ie. Remove original foreign key reference property, add your own property with a query in the get accessor to the other side of the partial class. Not exactly rocket science. I do realize it would be easier if the code was auto generated, but especially when it comes to auto generated code it is never a good idea to generate code that can cause confusing bugs for developers.

Many thanks for keeping us updated. You mention in your last post that you are not on the LINQ dev team anymore however your blog is the one that comes up when you do any searches for LINQ-to-SQL. Can you share with us any other blogs or places where we can find anymore information about LINQ-to-SQL, i.e. current developer blogs.

Hopefully Microsoft have realised that there is widespread support for LINQ-to-SQL and will continue to develop it alongside Entity Framework.

It’s also quite specialized and advanced. I’d rather see the framework stay smaller and focused and have dynamic LINQ move into CodePlex – but I’m not on LINQ/.NET Framework any more so don’t have any insider knowledge.

[)amien

I was under the impression that the reason this feature wasn’t in the first version was simply because you ran out of time. I guess I assumed that meant it would be in the next version!

Extremely useful for ad hoc where clauses (the only time I ever really use it.)

I was looking at EF for this exact reason, though I like linq2sql alot myself. I needed to interface with a MySQL database. What I found is that EF’s MySQL support is pretty limited. It sounds like the problem is more related to the MySQL Connector software used to allow MySQL support (which is not Microsoft software). I’m just saying EF isn’t necessarily going to solve people’s cross database compatibility issues either.

If only Linq to nHibernate were more complete, I’d be using nHibernate. I only experimented with fluent nHibernate some, but its was pretty sweet for setting up object/table mappings.

My experience using linq2sql has been great. The main reason I can’t use it in production environments is that the systems I work on use stored procs that return multiple tables, which is not supported natively by either linq2sql or EF.

[)amien