Is .NET too successful?

Over the past few months I've been reading of rumblings in the .NET blogosphere about the directions Microsoft is taking with .NET.

The poster child for these rumblings is the dichotomy between LINQ to SQL and the ADO Entity Framework (EF). Both in essence are used to get data from your database engine into your .NET application, both implement an ORM (object-relational mapping), but it's not really clear which one to use. So there's a whole cottage industry that's grown up around this, with many august commentators opining for their readers which they'd go for (just google for "LINQ to SQL" "Entity Framework").

It turns out the reason there are two frameworks that have such wide overlap is that, ta-da!, they were written by two different teams at Microsoft. LINQ to SQL was written by the C# team, whereas EF came about through some long-winded gestation (I'm visualizing that scene from one of the Lord of the Rings movies where you see the orcs been "born") from something called Object Spaces and is owned by the ADO.NET team. LINQ to SQL was recently given over to the ADO.NET team.

Roger Jennings, in a post from May this year, wonders whether the ADO.NET team are just going to abandon LINQ to SQL. It's crippled in the sense that it only works with SQL Server and, as I said, there's a great deal of overlap between it, and EF. Why have 2 official ORMs when just having one will do?

And another example: the Patterns and Practices (P&P) group at Microsoft have been producing "best practices" type libraries, such as CAB, for a long time. Last year, just before TechEd, there was a flurry of information about a new product codenamed Acropolis that seemed to replicate a lot of what the P&P group were doing, but in a shiny new framework with designer support in Visual Studio. By October it had gone, its ideas to be subsumed in P&P and eventually the .NET framework itself. P&P has expanded its repertoire of libraries since.

And of course we have WPF, WCF and WF, all frameworks that expand on the basic .NET Framework. Ditto ASP.NET MVC. Poor old Visual Studio just can't keep up, which is unfortunate since they all really need VS's discoverability and designers to make them easier to use. So there's more blogging advice from august commentators...

The .NET Framework no longer seems to be single and indivisible. Instead it's turning into this multiheaded hydra, a victim of its own ease-of-use and productivity enhancers. Different teams at Microsoft seem to be producing libraries and frameworks as quickly as possible without anyone having much of any control over the process to try and unify them. David Worthington of SD Times seems to have a key to someone's filing cabinet at Microsoft, since he's quoting from yet another internal memo about exactly this issue in his latest article.

I don't know quite honestly what the answer to this might be. In one sense, it's great to get all this functionality flowing out of Microsoft. On the other, it just makes the whole process of developing with the .NET Framework that much more complex. Also, looking at it from our viewpoint, should we try and support everything that it makes sense for us to do? Wouldn't that spread us too thin, meaning our existing products and customers getting reduced love, but getting more marketing hits for new anemic products that support the latest framework/library? Or should we be more cautious, and test the waters a little with some experimental products before jumping in or retiring?

This is all a shame since the .NET universe was so much simpler than the previous COM and ActiveX universe. Are we getting to the point when another super abstraction is needed to make .NET simpler. together with full support in Visual Studio?

Free DevExpress Products – Get Your Copy Today