Is .NET too successful?

11 August 2008

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?

8 comment(s)
Colin Mackay

Just look at the Java world - There are lots of frameworks that have overlapping functionality. I think it is inevitable that something similar will happen with .NET. It doesn't have to be Microsoft that produce all those frameworks.

11 August, 2008
Julian Bucknall (DevExpress)

Colin: You're right, of course. Perhaps it's just a function of success: the more the environment is successful like Java, the more you'll find complexity creeping into that environment via choice. Conversely: the less choice there is available, the less successful the platform, perhaps.

Food for thought.

Cheers, Julian

11 August, 2008
Thorsten Engler

The problem seems to be that people seem to see everything .NET related that comes out of Microsoft as part of "the .NET platform".

Which I think is just wrong. Most of the new offerings are really "just another third party library", which happens to be published by a division or another of Microsoft.

In case of LINQ to SQL vs. EntityFramework, these 2 are really just 2 contenders in a field that's including .[...redacted big list of products...] (and I've probably overlooked quite a few). You might notice that DevEx also contributes to that list.

Given the sheer size and number of divisions at Microsoft they end up competing with each other just like different third party vendors do. So it shouldn't really come as a huge surprise if their competing offers end up with overlapping functionality.

While the fact that there are competing products from the same company making it all the way out to the public seems to indicate some lack of control and direction from upper management (really, the competition should be sorted out internally before publishing) I think it can only be seen as a part of an active and healthy market.



11 August, 2008

I think the release of some of the competing products from within Microsoft is healthy for the overall eco-system of .net.  

It gives the developers opportunity to help pick which approach we like and it sure beats being stuck with the Henry Ford approach to cars - you can have any color you want as long as it is black.

11 August, 2008
Kevin McFarlane

Re: ASP.NET MVC, there is also the Web Client Software Factory from P and P that's been out for well over a year! To muddy the waters further it's even possible to use both together!

12 August, 2008
Julian Bucknall (DevExpress)

Yikes, people. This blog post wasn't "Julian's talking about ORMs so let's see how many we can list." Hello? It's about what I see as a lack of coherence and maybe strategy in the .NET offerings we get from MS. I'm perfectly aware of the lack of coherence that is evinced collectively by all the third-party vendors ("I can't seem to use X's and Y's products in the same app") -- that's possibly another blog post -- but to have the same from MS is a little worrying, no?

Cheers, Julian

12 August, 2008
Garth Henderson

Aloha Julian,

Very good topic.  I vote  that “. . . we be more cautious, and test the waters a little with some experimental products before jumping in . . . “

My recommendation is that we help to constrain the “multiheaded hydra” by clearly identifying the scope and goals of DevExpress with a listing of the selected group of .NET technologies that best align with our community goals.  There are many strong and worthwhile .NET concepts and technologies that DevExpress aligns with.  Based on the DevExpress technology foundation (and the support of a few brief white papers) the wisdom of the DevExpress direction should naturally be self-evident to discerning developers.  

As commercial developers we require a stable programming environment with thoughtfully controlled improvements that continually increase our revenue stream.  

Logically, it makes a lot of sense for MS to apply the thousands of experienced Dynamics employees to “eat their own dog food” in writing a pure .NET business application.  Dynamics set this target a few years ago as Project Green to consolidate the four Dynamics legacy products (most written in the ‘80s) into a single .NET product.  The success of their professional product will prove the validity of a comprehensive environment for scalable business applications.   To date, Dynamics is using .NET much the same way that IBM has been using Java to front end legacy RPG and COBOL applications.

The continuance of a small team, sophomoric, piecemeal approach to .NET enhancements, as David Worthington’s article points out, doesn’t serve the best interests of our global business community.   A clear big picture architectural approach is needed.

We need improvement.  Change without improvement is counterproductive.



13 August, 2008
Roger Areia

I would just like to add my vote for caution.  Microsoft has a long history of floating technology ballons, just to see if anyone uses them.  All to often the technology is quickly abandonned and we are left holding the bag (I am still supporting XSL-WD, Microsoft JavaVM and a host of other applications that still work, but all references to the technology have been "disappeared").

This said, ORM is particularly hard and has even been refered to as the "Vietnam of computer science" (see  All this argues for extreme caution when adopting these competing APIs.



18 August, 2008

Please login or register to post comments.