William (Bill) Vaughn's Musings

I just started working with Orcas Beta 2 again after a long hiatus so I am finding new issues all the time. There are so many UI issues I’ve mentioned over the years that are still not addressed. Off the top of my head these include (but are not limited to):

• Auto “imports” for object references as is done in C#.
• Extensible New constructors for those cases where the new constructor does not include the right set of options. These extensions should have a mechanism to be automatically loaded when Visual Studio starts.
• The ability to insert SQL directly into a text string in the code editor. I’ve been asking for this for years with still no change.
• The ability to insert a prompted provider-specific Connection String directly into the new Connection constructor. This is new—an idea that just came to me. Given the number of people still having problems building Connection Strings and how much UI is already built to do this, it seems to me that it would be possible to right-click and let one insert the results of the Connection dialog editor.
• I would like to see “smarter” intellisense that does not show properties, options, events etc. for objects where the class does not support them. Case in point: SqlCe namespace does not support stored procedures, but it appears in the list of available options in the CommandType intellisense.
• Spell-check for all string literals. Every person who has shipped an application only to discover that they misspelled a few critical words knows why this is needed.
• Auto-hookup in the Data Source/TableAdapter paradigm for many-to-many hierarchical data. One-to-many seems to be nailed down except for use of SPs and parameter-based queries—these require quite a bit of extra code. Remember folks, addressing an entire table is not how you build a scalable application (unless it’s for the church roster).
• Default behavior of the Data Source config wizard needs to disable choice of “Tables”, “Views”… That is, developers should have to manually choose all of the tables in a database to be used to create ST TableAdapters—not just check one box. 90% of the time this is just wrong. Don’t help inexperienced developers make mistakes from the beginning.
• When creating a TableAdapter, one should be permitted to provide a Query-builder interface to limit the rows during initial configuration instead of having to go back and reconfigure. If not QB, then some interface to help construct the WHERE clause. Returning all rows from a table (the default behavior) is a very poor practice. Again, help them build correct applications from the start.
• When using D&D to display data in a DataGridView (thanks for not changing the name again), those columns whose control designation is “none” should not be displayed. For example, TimeStamp columns are automatically marked as None. This works fine for discreet controls. This is just a bug that should have been fixed for some time.
• Better mechanisms need to be added to help developers build hierarchical one-to-one, one-to-many and many-to-many UI-based applications—with and without direct table access (as when using stored procedures).
• We still don’t have a clearly defined mechanism to refresh the generated code once changes are made to the underlying schema. Give us a “regenerate code” button that (at least tries) to walk the referenced data and rebuild the TableAdapter classes.
• Why can’t I “join” two Data Source DataSets by dragging a table from one to the other?
• For consistency, the Data Sources window should be listed under the top View menu.
• The project references pick list has not been fixed since the first launch despite being mentioned as many times as an issue. Due to the (to be nice) “challenged” design (the UI looks like a throwback to VB2), and the fact that many Component Names are so long, you can’t tell one from another. This is UI 101 and should have been fixed long ago. IMHO it should have a filter setting to help locate references as you do with the Toolbox customization dialog (which is slow, but nicely done).
• The Add New Item dialog needs to have a simple import facility to permit developer to import RDL reports into a project.
• Refactoring should be built in—not added on.

Perhaps they would be fixed by the version after 2008. I'm not holding my breath.

Bill

Posted by William Vaughn at 06:04 PM | Permalink | Comments (0)

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.

Posted by William Vaughn at 06:01 PM | Permalink | Comments (1)

This entire security paradigm makes a grossly invalid assumption: ordinary people actually know what to trust, that they actually know what they are doing and know how to protect themselves. The vast majority of consumers treat their systems like a trusted home appliance. They assume that it should work and keep working as long as it's plugged in and they pay their broadband bill. They have no clue about how their systems are subject to attack from all sides--they simply trust Microsoft to protect them. Putting the responsibility for their own security entirely in their hands is a truly ludicrous idea.

I just build up a system for my granddaughter (age 5). She was able to connect the keyboard and mouse (color-coded cables) but when we visited a trusted web site that had a PDF file, the trouble began. For some reason Vista does not have the Adobe Reader installed. (Incidentally, one MUST have UAC enabled for it to install.) In the process of getting the file read, we must have had to click "OK" to a dozen (literally) dialogs warning about one thing or another. Try to explain that to an ordinary person--much less a 5-year old.

Should parents expect their children to come and get them when they see these dialogs? How are parents to know which are real threats and which are not? Since the parents or someone they trust told them that it was okay to click through the message, why hasn't the system learned that this action is safe? No, this system is totally, 100% unworkable. Why? Well, people will get so tired of these constant security popups that they will disable the feature and then what? Since the security scheme assumes these attacks will be prevented by UAC, once it's disabled, they're pooched.

I think that Microsoft has really failed the world's computer users--they've had a decades to get this right and they still missed the mark. Frankly, I think it's insane to build better and better filters when the problem is polluted water. MS and the worlds internet service providers need to rebuild the internet so those who have no regard for the law can't prey on the most vulnerable--our wives, children and the elderly. They need to stop talking about fixing the problem and just do it. Microsoft has the money. Just do it. And stop foisting off the job on the consumer.

Posted by William Vaughn at 10:04 AM | Permalink | Comments (1)