Visual Studio .NEXT Wish List

At Microsoft’s annual MVP Global Summit, the Microsoft folks asked me for a list of features that I thought should be in Visual Studio (VS) 2010. I've already been keeping a “wish list” on my blog for a while, so now seems like a good time to update that list to reflect what’s in VS 2008 and pass it on to Microsoft. Most of my VS 2010 wish list items are data-centric. That’s because I’m a data guy and most of the applications out there access data one way or another. I'll consider recommendations for other VS wish list items as well. But first, I'd like to run the list by you and see what you think.

The "Real" RTM of VS 2008
VS 2008 isn't complete. Unlike VS 2005, VS 2008 doesn't offer the ability to create, test, or deploy SQL Server Reporting Services (SSRS) reports. It also doesn't access the new SQL Server datatypes or ADO.NET 3.5 features related to SQL Server. I can't even open a VS 2005 Business Intelligence (BI) project—and still won’t be able to even after VS 2008 SP1 ships sometime after SQL Server 2008 goes to manufacturing. Microsoft tells me that this functionality will be brought back to life post SP1, but what about the year in between? Although I would like to use VS 2008, I have to revert back to VS 2005 to do so.

Also, two of the more important innovations in VS 2008 is the new Local Data Cache and ADO.NET 3.5 Synchronization Services. However, if developers try to use these against a SQL Server 2005 database, their catalogs (table schema) must be munged or mangled to support the additional columns used to keep local and hosted tables in sync. I find it hard to recommend this feature (as cool as it is) because the SQL Server 2008 implementation uses behind-the-scenes functionality to enable it. The wizards will add columns to the target table (the one to be synced) on the server. Right after that the DBA comes and sets fire to your desk. It seems to me that Microsoft should have held Visual Studio 2008 until SQL Server was ready or not exposed the feature in Visual Studio until SQL Server was ready.

Add a Sync Button
I think code generation is an accepted practice in general, and it's understood that part of VS's job (regardless of the language) is to generate code to lay out the forms, load and describe the controls, and provide the plumbing to connect these controls with data sources using the selected language.

The fundamental problem with code generation is that VS hard-codes these elements. That's fine for the bulk of the UI controls: You can easily move them around or re-dock them as necessary. However, when it comes to the data structures behind the scenes, hard-coding schema is a serious problem. The TableAdapter Configuration Wizard, like its predecessors, makes one big fallacious assumption: that the data catalog (what we used to call the schema) is fixed, cast in stone. As you well know, in every stage of application development from newly created apps to those being modified for the fourteenth time, the database catalog is always subject to change. Although a disciplined shop might restrict these changes, changes occur nonetheless.

Because VS has hard-coded the generated TableAdapter classes, simply changing a column in a database table from an Int to a Long can be problematic. As it is, after a developer uses the wizard to code-generate a class against a database table, there's no mechanism to get VS to correct that generated code to reflect these changes without a lot of drag-and-drop work.

As difficult as it might be to create, I think the TableAdapter Configuration Wizard should have a “catalog sync” button to walk the schema as addressed by the ConnectionString and compare it to the generated code. If there are changes to be made, it needs to either add a list of tasks to repair those changes or simply make the changes. Hard-coding schema-specific SQL in applications is something we’ve been telling front-end developers to avoid for decades.

Set Up a Metadata Catalog
When we build a forms-over-data application whether it’s hosted in Microsoft Internet Explorer (IE) or on the Windows desktop, it’s the application’s responsibility to validate the data. Unless the data is validated, it shouldn't be saved anywhere. To this end, our applications should validate every entry by every user and validate every record that arrives from another data source—even a trusted one. Validation goes way beyond “type safety,” which only validates that the data conforms to a fairly loose type constraint. I, for one, implement Defaults, Rules (yes, rules), constraints, typed-parameter stored procedures and in some cases triggers on the SQL Server database to make sure that if something evil gets through, it’s not added to the valid data. However, I believe these validation rules should be done while the end user is focusing on the content as it’s entered.

Mapping business rules, validation criteria and other constraints to UI controls could be made a lot easier in VS. While developers can use Visual Basic expert and MVP Billy Hollis’s great UI controls to help incorporate the metadata to validate the keystrokes, a lot more can be done. I propose that VS help the developer community set up a metadata catalog for each product (a set of selected rows over a table or product of a JOIN) that we expose to the application. That way, when the business rules change, the code and UI controls can be morphed automatically. These metadata values would include “min,” “max,” “mask,” “default,” “valid values list,” “caption,” “read-only,” and more; potentially, a lot more. I propose that this metadata be standardized so that it can be stored in the database along with the database tables so that it can be leveraged to generate code and requeried by VS when the developer changes it.

Because developers need a standard way to expose and store meta data, it means there should be a way to define and manage the metadata for an entire table as well as the database itself. Table metadata might provide alternate table “names” to be used to build UI elements, the PK, and other suggested filtering columns. It could contain ownership (schema) details or other easily accessible data to describe how the table should be used.

I call this approach “soft coding” (as opposed to hard-coding) the generated code. If the code generators were designed to be driven from the data catalogs and from metadata that was expected to change not only at design time but at runtime as well, applications would be able to automatically adapt to current business rules, constraints, and end-user preferences.This metadata could also be stored locally in a SQL Server Compact Edition database so it could be accessed when the application is disconnected.

Disable Tables Check Box
After all these years, VS still builds its generated code DataTable classes as if developers should map the entire table in a database. VS even exposes a Tables check box to let the developer choose all of the tables in the database for TableAdapter code generation. While this check box might make it easy if you’re building a toy application or a demo, no developer (or developer's manager) in their right mind would do so. This check box should be disabled. Consider that virtually all of the developers in the sessions and workshops I teach tell me that their DBAs don’t expose the base tables so Visual Studio tools that depend on tables to generate code are counterproductive. A VS UI tool that treats stored procedures as an afterthought is not my idea of a best-practice tool.

Continue on Page 2