By default, the TableAdapter/Data Source drag-and-drop paradigm generates some fairly clumsy code to bind rowsets to the UI. As it is, the wizards (more like Dark Lords) encourage developers to select all columns from a base table with no WHERE clause. The developers is given no opportunity to do anything to limit the rows returned—not until they manually reconfigure the queries or use SPs using the TableAdapter designer. The wizards repeat the same table-based query for each table selected in the Data Source. If the developer blinks (does not know better or has watched one of the demos we’ve all seen) and chooses “Tables” in the initial dialogs, a ST TableAdapter is created for each and every table in the database which can add thousands of lines of useless code to the application. Microsoft needs to disable this option.
Ok, suppose the developer wants to create a true hierarchical parent-child UI application. They have to manually wire up all of the parameter queries (those that choose the focused parents and related children), as well as the new navigation routines to navigate to a new parent. The wizards also don’t differentiate between columns that are RO (because of selective criteria) or have restrictive value constraints. This approach is not much easier than doing it all from scratch… it could be so much more.
Of course, many DBAs don’t expose base tables so in disciplined shops this is not as serious an issue, but the developers are not encouraged to take the right course (use parameter-based SPs) nor are the tools there to help make it work. In shops where the developer is the DBA or is building a prototype to be integrated into the production system, this paradigm can waste countless hours of time. The wizards should help developers build best-practice code that will scale and deal with real-world database designs and security implementations.
This paradigm is doubly difficult in the very common situation where the database is still in flux. That is, when the schema changes, there is no clearly defined mechanism to rebuild the generated code to reflect those changes. There is no mechanism to reflect the changes in the TableAdapter to those references to it in the developer-written code. Developers need to get this before any (ANY) new features.
To add to the issues, Visual Studio still does not have a single element to help developers setup or manage security. All of this is relegated to SQL Server Management Studio which uses a different UI for many of the same functions. Has anyone seen any Visual Studio examples that discuss security issues or best practices?
IMHO, this scenario is far more common than any LINQ scenario I’ve seen demonstrated. It might not be as sexy but it is needed by far more developers. Does LINQ do it right the first time or simply incorrectly assume that developers have rights to base tables and columns? Does LINQ encourage developers to focus queries on reasonable subsets and populate just related rowsets? Does LINKQ automatically morph when the schema changes? If these are not all answered “yes, we thought of that” then you’ve just created another way to create toy applications.