This isn't the first time I (Mike speaking) have commented on this subject, I have done so once before at least on the MyGeneration forums. However, now that we are implementing EntitySpaces design time data binding support for ASP.NET 2.0 my anger has been renewed ten fold on this subject. To put it bluntly, Microsoft ruined ASP.NET programming when they released ASP.NET 2.0. Quite a statement I agree, however, I'm not the only one who thinks that. I've been communicating with several key folks in the know concerning this new ObjectDataSource/DataSourceControl fiasco and received this comment just today.

"IMHO, Microsoft ruined data binding in ASP.NET 2.0 when they dropped component support from the design surface"

What am I talking about? Well, if you have ever used data objects or business objects that support the proper interfaces you can drag then right out onto your form, add them as the datasource to your grid, and then pick which columns you want to use, and in what order, including sorting, and so on. You can do that now with EntitySpaces in Windows.Forms, but all that was removed from ASP.NET 2.0. Why? Let's go back in time and look at the reason Microsoft gave (and still gives) as the reason they decided to remove design time data binding support from the ASP.NET 2.0 Framework. 

Microsoft's Statement on this:
http://lab.msdn.microsoft.com/ProductFeedback/viewfeedback.aspx?feedbackid=e2996990-64a5-4308-921d-245071e6f174

Thank you, we appreciate all of the feedback on this issue. Unfortunately we will not be able to implement a Component Tray for components in VS 2005. As stated previously, the existing model in VS 2003 was prone to bugs and code-loss and as such we've removed the functionality of a designer tray for components defined in InitializeComponent. The team understands the desire to have this functionality and we will look at potential solutions in future releases which are more robust. While the designer tray support for components declared in Initialize component is removed, components themselves are fully supported and can be edited by modifying code, and existing components defined in pages will not break and will continue to work when the page is executed.

We regret the loss of functionality in this scenario and we will certainly aim to provide similar functionality which is realizable and not error prone in future versions of Visual Studio.

My Paraphrase: "We couldn't get it to work?"

So, what does this mean. It means Microsoft hurt immensely the development communities ability to write ASP.NET applications in 2.0. There is just no way around it. To say that they couldn't figure it out is insulting to the say the least. They should have picked up the phone and called me, I guarantee I could have had made it work. No, there had to be another reason and I think I know what it is, more on that later in this post.

One of those sounding the warning sirens early on was Daniel Cazzulino and you can see his blog and his replies on the Microsoft link (or rather excuse) above. His responses are as kzu as he urged them to re-open this issue. In fact, I remember that post being much longer, a lot of it has been removed, I wonder why? He was so right of course, thanks Daniel, but there was nothing you could do, it wasn't that they couldn't fix it, it was removed for a purpose.

So, left trying to pick up the pieces are the ORM folks, from Paul Wilson, Rockford Lhotka, Frans Bouma, and Winston Fassett's work surrounding NHibernate, and probably quite a few others I have left out. On Rocky's Blog Post you can see his frustration and rightly so, remember, this all worked via generic interfaces like IBindlingList and ITypedList and so on in ASP.NET 1.1 .... Paul Wilson's DataSourceControl sample is cool, but one thing you learn very quickly is that his sample, while appreciated, merely allows for runtime data binding. All that work just for runtime databinding?  Then there's Winston Fassett's NHibernate Example on The Code Project which takes it a little further.

However, and I must say, NONE of these samples are actually what you would call design time data binding support. This is not to discredit anyone's work, their work is good. The point is everyone is being fooled into believing that this is something that it is not; DataSourceControl is not a replacement for ASP.NET Design Time data binding and neither is ObjectDataSource. Take a look at this image from the NHibernate based article.
 

Notice the TypeName property is Northwind.Model.Product. This is the type of object you want to bind to, which is then loaded via reflection in both Paul's and Winton's samples. In fact, there really is no other way to do it. So medium trust goes out the window. Also, if you look closely you will see things like WhereFragments and SelectParameters and other strange items. It quickly becomes evident that this is a strange and rather bizarre way to create a web page. Rather than write the code in a code behind page to load the entity you get to use a strange dialog with a dialect completely different than your normal way of working. And the vendor of the ORM architecture get's to invent an entirely new API to query the objects since you cannot use C# or strongly typed mechanisms in a dialog like this. 

Look at these methods of the low level DataSourceView class that Microsoft holds out as a better way?

virtual int ExecuteUpdate(IDictionary keys, IDictionary values, IDictionary oldValues);
virtual int ExecuteDelete(IDictionary keys, IDictionary oldValues);
virtual int ExecuteInsert(IDictionary values);

So, Microsoft now expects us to actually write our insert/delete/update statements by passing IDictionary's of typeless data around and using reflection to translate those into properties in order to make sure any business logic that needs to be executed is triggered. I'm getting pretty ticked just writing this up. Am I the only one who see's this? This isn't design time data binding or even runtime data binding, this is worse than scripting, in fact, none of this is necessary at all, just support IBindingList and ITypeList and you can write your code in C# or VB.NET and not in some strange bizarre dialog? This type of programming would make me long for VB4 if there ever was such a thing ....

I have yet to find a simple sample of a grid binding to a business object (like we used to be able to do in the .NET 1.1 Framework) using this new scheme they've hatched. I've tried to hold my tongue and not bash, but this one deserves bashing, whoever dreamed up this monstrosity obviously had no idea what was lost and no idea what object oriented programming or strongly typed programming is. Instead, they come up with update/delete/select methods that take IDictionary's. They must have been using a raw ADO.NET datatable with no foresight beyond that. In a way I feel sorry for them, they had nothing else to go by, they haven't created nor probably ever used a well written architecture like EntitySpaces or some of the others mentioned above.  And that leads me to my conclusion.

For Microsoft to say "We regret the loss of functionality in this scenario and we will certainly aim to provide similar functionality which is realizable and not error prone in future versions of Visual Studio" is disingenuous. Does anybody reading this believe Microsoft on this? The company that creates massive development teams just to release free products like Sql Ce couldn't get this minor issue to work in ASP.NET 2.0? One of their most important products?  Honestly, I'm appalled at this statement.

Could it be that ASP.NET design time support was dropped to allow Microsoft time to work on ADO.NET vNext while at the same time severely hampering those vendors who stood to gain a dominance in the very important ORM market, a market that Microsoft thus far is severely lacking a presence in? It will be interesting to see if by miracle this "loss of functionality" is restored in conjunction with the release of ADO.NET vNext. Perhaps there will be a new model released as what exists now is frankly, worse than nothing. My guess is a miracle is on the horizon.