Winsmarts.com

Okay, this post was long overdue. So here it comes.

The last ORM show I am listening to on DNR, is the Ted Neward/Ayende show. I saw Frans also interviewed, so I listened to his show first :-). Frans was a reviewer on my book, and in general a very good friend and awesome guy. And oh by the way, he also is the dude behind LLBLGen Pro.

Having some background in data access on MSFT space, I decided to write this long overdue blogpost about my views on where we are, and where we are headed.

• LINQ, In my opinion is a good addition to the language, but certainly not worth the marketing buzz it has created. I know many developers just pulled out their knives to stab me to death, when I said this, but consider this - when you work on a project, a huge part of the project is ironing the requirements down, the development methodology, laying the logic in a maintainable fashion, structuring your objects, laying out the database etc. How often, do you ever need to query a client side collection? Sometimes !! Sure!! But is that the only thing I was hoping for a new generation of the .NET framework (sorry but .NET 3.0 ain't a new generation) that took literally 3+ years to incubate? What LINQ does give me, is a way to simplify my code for about 10-20% of the use cases in my code. It will revolutionize the 10-20%, but really - in an entire project - 10-20% of a revolution that took 3 years to incubate? I'm beginning to not get impressed. Also, just as some developers will use LINQ to simplify their code, some will abuse it and write completely unmaintainable code. Finally, don't forget - LINQ doesn't buy you any performance gain, or set based theory like Foxpro did, it is more or less syntactical sugar and bunch of .NET code under the scenes that you didn't have to write.
• LINQtoSQL, In the Ted Neward show, Ted remarks around 1:07:00 that LINQ to SQL doesn't have stored procedure support. Well, not really - because it does! However, LINQ to SQL is to .NET 3.5, what TableAdapters were to .NET 2.0. In my honest and not so humble opinion, most production projects will and should stay away from it. But I must qualify, LINQ to SQL isn't completely useless either - I will elaborate on that momentarily, but first, let me discuss the issues with Linq to sql.
  
  There are a number of problems with LINQ to SQL, it is too tied to a specific database & structure. The code produced will largely become unmaintainable for complex projects. Also, the code produced isn't very useful to begin with. In the early days of DLINQ, the ASP.NET team produced something called BLINQ. Tell ya what - it was pretty amazing that they could create asp.net pages that did paging and what not with such little effort. Quite impressive! But translate that into a real project where the conceptual model is sufficiently disjoint from the relational model, and suddenly DLINQ, sorry LINQ to SQL, becomes utterly useless. Why? Because translating that model back and forth is where the real pain is, LINQ doesn't buy you much more than syntactical goo, and anonymous types are not too useful when you start structuring your code hierarchically and functionally. But LINQ to SQL isn't entirely useless either.
• LINQ to SQL is great for scratch and sniff - concept projects. Low effort, get the app running - worry about more stuff later. It will probably act as the developer's powerpoint - which is an awesome thing to have. We don't have that today, and I am looking forward to having it in my arsenal.
• The biggest plus point of LINQ to SQL is, hey - it will actually ship with Orcas. :-)
• Entity SQL, ADO.NET Entity Framework, Now this got me really excited. The whole concept of the Entity Data Mapper, the Mapping provider, Entity Model and the best thing around - Entity SQL - are quite awesome. I strongly and vehemently disagree with Ted Neward on this as he compares eF with other ORMs or even EJB in the market. eSQL is what differentiates Entity Framework from the rest of the ORMs. eSQL is quite kickass. eSQL + LINQ gives you the organizability(!?) of C#, and the ease of Foxpro. What is there not to like?
• I do disagree with MSFT though that this will be a 100% coverage solution. Nothing is. There will be certain instances where you will want to abstract to a lower level and handle things yourself. I do feel however that Entity Framework, will not be such a leaky abstraction as Ted fears it to be.
• And now the biggest problem of the Entity Framework. It just ain't there :). I am quite disappointed to learn that it won't be a part of Orcas. So lets just hope that whenever it ships, it ships in completion and in style - not as a watered down version with critical peices missing. And it ships in time.
• And I pray to god that the WinFS and ObjectSpaces fate doesn't hit eSQL. I would be hella disappointed if that happened.
• Jasper, Astoria - Uhmm .. like we don't have enough ways to access data anyway :-/. These projects are awesome, but really these efforts need to be combined with other data driven efforts within MSFT, so the MSFT developer crowd gets a clear direction going forward.
• NHibernate, LLBLGen Pro etc. I feel that third party products like these will continue to forge forward much as component vendors remain a step ahead of basic ASP.NET. It's a healthy co-existence.
• Visual Studio.NET - I cannot finish this post without ranting about the current state of the VS.NET.
• The VS2005 IDE is extremely buggy. Debugging interoped com components, or even IIS gives the IDE the wobblies more than it should. I wish VS2005 had some competition, but unfortunately it doesn't. I hope the Orcas IDE shows some significant improvements.
• VSTS is a terribly useless pig. Please, may I have a show of hands if you actually use VSTS - complete with the sharepoint site? Just using TFS is not using VSTS. And if you are using only TFS, why the heck not use Subversion or Vault?
• The VS2005 IDE is stuck in a rather unfortunate monopolistic situation.
• There is no incentive for any other company to create a better IDE because the IDE costs some serious $$$ to create, and MSFT gives it away for peanuts. It is impossible to compete with such a model, so I don't expect google or adobe to come out with a Visual Studio.NET that is better. 
• And I don't expect the community to do it either, because when people who have tried to improve certain SKUs of the IDE get sued, it serves as a very big discouragement for the community. While I am terribly disappointed to see lawyers involved in suing someone who is really a developer/member of the community/one of us, I don't want MSFT lawyers on my ass either, so I'll just stay quiet on the whole "who is right" portion of that incident. I just wish nobody gets hurt in the process, and I wish both parties settle on a mutually amicable solution.

So, as you can see above, I am not too enthused about the current state of the data world. In fact, I am bored with it. I am bored to the bone because there isn't much activity, or excitement going on in either C# or in ADO.NET (DataAccess) in general. So how many times can I regurgitate about connections, commands, and connection pooling? Seriously, when you know something down to the metal - it becomes easy. And when it becomes easy - it becomes boring. Oh, and please don't confuse easy for problem free :-).

But either way, I am bored of data access, and will continue to watch it from the sidelines until we have some serious progress on the only one possible MSFT winner out of the above at this time, the Entity framework.

Note that LINQ will also fly, but IMO is a different animal and has nothing to do with Data Access. But really, LINQ isn't that big or complex (or even impressive! :-/).