I was playing around the other day with .NET’s data capabilities, mostly the DataGridView component and its family of data access components, i.e. the DataAdapter, DbCommand, DbConnection and so on; and what strikes me is how difficult it is to built any kind of data solution in .NET; and how complex the API is.

To add further damage to it, the whole thing is rather poorly documented; so in order to understand it completely, you have to look at publicly available examples and read books to figure it out. And in doing so you keep running into problems: For instance, creating a small program that simply opens a database connection and displays a table for editing, seems impossibly difficult to make. It doesn’t seem like such a simple idea has struck the .NET community just yet.

To begin with, you need an SqlConnection; so instantiate one of those. Then put a DataAdapter on the form and let it generate different SQL statements that it needs to update the database with. Also let it create a DataSet, and fill this one with the data fields and types from the table. Next, place a DataViewGrid on the form, and tie it to the data using a BindingSource component. Then add code to open the Connection, and make the DataAdapter fill the DataSet with data. By now you should have a program that, when run, displays a grid of data which you can edit.

Except, of course, that the data isn’t saved. The data can be edited alright, but to write the changes back to the table, you need to place an Update() call to the DataAdapter (or DataSet?). When to do this, we might ask? Well, it doesn’t seem like the DataGridView is even remotely capable of doing so itself. It needs to be done for it. And all the examples on the Internet suggest that there should be a “Save” button on the form whereby changes, when pressed, can be written back into the table. I found one example where someone had figured out a way – through serious hacking – how to get it to write changes back to the database, as soon as you select a new row (gasp!).

This is absolutely stunning, since Delphi has been doing this very thing since, oh, version 1.x or something. Natively. You don’t even have to ask it. You slap a TDatabase component on the form; then slap an additional TTable on it, tie them together with a Grid through a simple, barebones TDataSource, set the Active property to true and it immediately works, right out of the box. No source code required. Really. In fact, you don’t even have to compile the program; the data is displayed right there in the Delphi dialog editor.

After some personal pondering, it seems to me that the .NET model is fundamentally flawed. Delphi’s VCL library aims to be transparent; that is, it provides a lot of functionality but doesn’t try to be all-inclusive. If any problems should arise, you simply peek behind the scenes to the Win32 API and do what you want (which actually rarely happens – if ever). In stark contrast, .NET goes the other way: It aims to be all-inclusive. The difference is, when .NET no longer can do what you want, there is no behind-the-scenes area that you can affect. It’s all or nothing. You’re Locked In.

And that means Problems, with a big P: I am gradually coming to the conclusion that .NET, for all its classes and namespaces, is an immature API – not surprisingly, though, given it’s 2.0 release status – and that it needs a host of specialized solutions on top of it, like open-source components, libraries and similar add-ons, that for years and years have been available for Delphi in abundance. .NET, in my view, is simply not much more than an additional API – a lot better than the old Win32, admittingly – but still far too complex and advanced for true Rapid Application Development.

It seems like Microsoft, for all their ambitions and efforts, still haven’t had the light bulb come on.

P.S. With my present luck, Microsoft will probably change everything in ADO.NET 3.0 so everyone will need to rewrite their applications. It’s only happened, oh, maybe three or four times in the past.