(Originally posted 6/23/2005)
This entry was resurected from my old blog... it's a keeper.
____________________________________________________
The Microsoft Developers have already begun the process of picking up the shards and shattered pieces of their Whidbey implementation that were sheared off as the product was being stuffed into the box. Some of these feature fragments will be retooled and redesigned to be implemented in the next version of Visual Studio dubbed “Orcas“ designed to support Longhorn (the next version of Windows based on the .NET Framework). It's time for all of us to encourage Microsoft to fix old problems, address old issues and make ADO.NET better suited to develop our applications. To get us started I propose the following...
1) Focus on getting what you have already invented working better rather than inventing more classes to do things differently—making the existing classes redundant. Developers want clear choices not a Swiss army knife with 70 blades just to open an envelope.
2) Stop deprecating established classes like the DataAdapter Configuration Wizard. This just causes confusion and needless thrashing. You’re trying to get people to adopt the product and continue to leverage their existing skills. Ripping out or hiding familiar objects is counter-productive.
3) Add the ability to right click in the editor IDE and “Insert SQL”. This would launch the query builder and return a properly formatted query string.
4) Provide an ability to interactively construct (code-generate) Parameters collections from selected ad hoc or stored-procedure queries. You had this in 2003, but dropped it in Whidbey. You could drag a stored procedure from the server explorer and drop it on a form. This would generate the Parameters collection code.
5) Make it crystal clear how to indicate that a Parameter object is to use the server-side default value (this might only require a good doc topic)
6) Figure out how to generate these Parameter collections and get the direction correct. There are still cases where code generators use Input/Output for Output parameters.
7) Get server-side cursors working again. Yes, this is not generally needed by the masses, but there are still many situations where this “connected” approach makes abundant sense. We’ve seen that connected architectures work fine and can be more productive (and easier to write) than disconnected in many scenarios. Forcing everyone to use disconnected or ASP architectures is not helping adoption rates. Consider that the default behavior in ADO classic was “Server-Side” cursors—not disconnected client-side cursors. Provide more means to help manage server-side state—perhaps this is just more emphasis in the docs. Also consider that server-side cursors are complex to manage but they can be efficient if implemented correctly. Using dynamic cursors is not the answer. Keyset cursors are far more scalable and perform better than dynamic cursors. Developers should have control over the cache size and refresh rate (if auto-refresh is implemented). This should be implemented in a separate DLL so developers that choose not to use client-side cursors aren’t penalized by the additional overhead.
8) When you think about scalability and how it impacts your implementations, consider that the majority by far of applications don’t have to scale beyond a few dozen to a few hundred users. It’s only in the largest companies that these approaches break down. Forcing developers to use an architecture that scales from 50 to 50,000 clients does not make sense if all they need to support are 200 clients.
9) Make Open, Fill and Load asynchronous-capable. Saying that this can be done with a BackgroundWorker thread is simple to say, harder for some to do.
10) Provide progress events in Fill and Load to preclude the need to code these asynchronously.
11) Add more documentation on performance tuning that emphasizes server-side processing. That is, moving bulk data to the client for processing and shipping it back does not make sense if the query engine can perform these functions in situ.
12) Provide a better/smarter/more easily configurable CommandBuilder. We need to be able to set the same Update Criteria options that we could use in ADO classic.
13) Start writing the doc so it includes Visual Basic examples, but not necessarily just translated from C#. Visual Basic’s approach to events, object disposal and other issues is different—especially for Visual Basic 6.0 developers. Yes, Visual Basic has Using, but adding Using to a Visual Basic .NET example because C# has it does not help Visual Basic 6.0 developers understand how to convert their code.
14) Document scenarios for individual data-bound controls like the Visual Basic 6.0 MSHFlexGrid and show specifically how to convert to the DataGridView. Include similar topics for other typical custom controls and show how these can be converted on a more granular level.
15) Get Exception handling under control. I’m not sure where you are at this point, but as it is, it’s broken—there are still too many catch-all exceptions being returned. “Stuff happened” is not a suitable exception message…
16) Find a way to build a “VLW” (very light weight) SQL query engine (like SQL CE) for use on the desktop for applications that need to store and retrieve information from smaller databases. While developers can persist data with XML it’s harder to use traditional SELECTs and relational approaches to the rehydrated DataTables.
17) Think about ways to make replication foolproof. Your goal should be to make replication and database synchronization work as well and as deterministically as Outlook syncing with Exchange.