Is Microsoft Listening or Open for Output Only?

>

I'm convinced by the hundreds of developer and customer interviews I've done over the years that building a SELECT query without a WHERE clause is just wrong. It makes an assumption that the application can consume all of the rows in the target table. Unless you're fetching a list of valid US states, populating a pick list that contains a few hundred rows, or creating a (very) simple single-user application, it simply does not make sense. It almost never makes sense for DataSets you intend to update. IMHO, no demo done by Microsoft should show this practice. In addition, no code generator should be permitted to ship that does not at least ask the developer for a WHERE clause and handle the inevitable parameters it requires. That's where VS falls short. The Data Source Configuration wizard still does not capture a WHERE clause or the parameters. The generated UI code should automatically build elements to capture and validate these parameters--very much like the Report Data window in the BI tools. These are very well done, and this metaphor should be leveraged to that end. IMHO, it's irresponsible to lead developers along the wrong path--even when dealing with novices--especially when dealing with novices. By asking for a WHERE clause, you help developers learn the right way to execute a SELECT query from the very beginning. Sure, developers can just skip over that step--as long as they have a note from their mom.

In that same vein, the Data Source configuration wizard should NOT permit developers to choose all of the objects displayed (as in the screen shot attached here). Doing so generates strongly typed DataSets with no WHERE clauses for ALL of the tables in the database--even if there are thousands of tables with millions of rows. Again, developers should always be encouraged to use best practices when building code. While asking for all of the tables in the database might make sense in a demo, it rarely makes sense in a real application. Don't dumb down the wizards to accommodate toy or sample databases. Assume that the application being built is a serious production application with millions of rows stored in thousands of tables, not an Access replacement or a simple app for a two-user home business. Even then, if the motivation is to make things easier, then help the developer learn the right way to solve the problem.

So, when does Microsoft plan to address the age-old problem of an evolving schema? The Entity Framework and the proposed drag-and-drop metaphor (the same one we've seen since the dawn of time in the RAD languages), makes an invalid assumption; that the database schema is cast in stone. In reality, the schema is almost always in flux while an application is being developed and long there-after as the development team's understanding of the business problem evolves over time. The UI developer rarely gets to change the schema, but in the current drag-and-drop metaphor, the developer has to do all of the work again when it changes. This all too often makes use of the drag-and-drop (that demos so well) impractical to use in a production shop. IMHO, Microsoft needs to AUTOMATICALLY change the generated code to reflect schema changes or at least mark code that's invalidated when the schema changes so developers can fix it. This is more than simply noting in the data model where changes have been made. The generated code must also be morphed to reflect these changes.

In addition, we still don't have a mechanism to manage or apply meta-data to the data code generated by the tools. Properties such as description, min, max, default, mask, acceptable values, value expressions, mask and many others all need to be managed and incorporated in the generated code. The code needs to automatically build exception mechanisms that deal with metadata validation issues. The interface needs to permit the developer to name and manage their own business rules to feed criteria expressions associated with each database object from the column on up through the server instance.

It seems that unless we act, Visual Studio tools are still going to generate code that does not reflect normal, everyday business practices, best coding practices and they provide no mechanism to automatically adapt itself to these evolving business rules. It's naïve, simplistic and generally a waste of Microsoft's time to keep working on this paradigm when it does not really help people learn best practices or build applications that will scale or hold up under the rigors of a real-world business environment.

As I see it, the data code generation paradigm has gone static or been distracted by implementing WPF or EM technology instead of working on the fundamental problems we've been talking about for over a decade. We have not seen substantive change since 2003 when the TableAdapter was introduced. These oversights in Visual Studio raise the question: Is Visual Studio and its data access code generators and binding mechanisms intended for serious, scalable production applications or are they just to help novices knock out an example to get the feel of the interface?

• I think we need an SDR that includes the heavy-hitters from the Visual Basic Insider's list as well as their equivalent experts in the C# MVPs. This needs to be done very soon--before the data access team has solidified the plans for 2010--if it's not already too late.
• I also think we also need a "Data Access Insiders" list to promote discussion of these issues long-term that seem to be ignored or misunderstood by the teams at Microsoft responsible for creating these technologies.

There are many of us out here that are passionate about Microsoft technologies and want to help build better tools and applications using those tools. Give us a chance to help Microsoft do that.