Lisa Feigenbaum says the Visual Studio team at Microsoft is asking for ideas for Visual Studio 2012 (the version after the now cast-in-plaster VS 2010). I did a search against my archive of suggestions I made awhile ago (okay, in 2006) to see which of the issues I raised then have been addressed and which make sense to be addressed in some future version. Ideally, Lisa will respond to say “Oh, sure. Those have all (or mostly) been addressed in the 2010 version.” but I’m an optimist.
Here’s the list. Consider that the Data Access team is at least influenced by the Visual Studio team and while these are not necessarily “language” issues per-say, they are developer issues that have yet to be addressed:
Where the Visual Studio Team Should Be Focused (IMHO)
- Help developers access existing relational database data sources. By their own admission, Microsoft tells us that most (by far) of the data access done today is against relational data stores. In addition most shops still use stored procedures to protect access, improve query performance and manage large, complex projects. Over the last 15-20 years the industry has embraced relational data sources and built infrastructure to support them, train developers and DBAs to use and manage them and spent countless billions of dollars doing so. Any strategy that does not leverage this considerable investment is a non-starter.
- Leverage existing SQL Views, Indexed Views and Updatable Views. Views are also used to “map” the data so focused applications can “see” and update data that they need. SQL Server has a number of innovations in this area that make this metaphor even more powerful. In a general sense, SQL Server has implemented a number of exiting new features—not all of which are leveraged behind the scenes by ADO.
- Working with stored procedures, parameters and parameter value validation—this is far more than simple type checking. The vast majority of SQL Server, Oracle and DB2 developers use stored procedures to execute the complex sets of statements required to fetch (and more importantly) update the database. Nothing we have seen in Visual Studio so far shows how updates will post data changes to multiple tables in a single transacted operation. Not only do these stored procedures update tables, but they return informational messages to report on “exceptions” that are not errors, they protect the data in sophisticated ways, implement business rules, protect referential integrity and much, much more. Any ADO.NET layer should be aware of these operations and their complexity. Anything the tools can do to make these easier to write (and write correctly) makes sense.
- The Data Source configuration wizard that currently generates the TableAdapter is still incomplete. It does not give the developer an opportunity to focus the query on a parameter-driven subset of the data because it still does not ask for a WHERE clause—it should.
- ADO should fire an event when an improperly typed (or ranged) value is assigned to a Parameter. As it is, we don’t know that a Parameter Value is incorrect until the query is executed. This wastes a round trip and requires far more complex exception handling.
- ADO.NET should fire an event when a value does not match the business rule(s) defined for a Parameter. As it is, developers have to design, code and implement their own.
- ADO.NET should support definition of business rules on server-side columns. These could be a simple as a Regular Expression but should include (at a minimum max, min, default, mask (a regex), and user-definable rules. Okay, these are already defined for T‑SQL (they are implemented as Rules and Constraints) but not for other data sources. Unfortunately, TSQL rules are deprecated and Constraints do not apply to an aliased type (UDT)—just specific columns—a move in the wrong direction. These same business rules should be mapped (or mapable) to UI element restrictors on the client/middle tier or otherwise exposed via ADO.NET. This should not require that the developer or DBA redesign their existing databases or schema—simply add additional metadata to the existing schema.
- ADO.NET and Visual Studio should help manage rights, schemas and ownership. IT managers and DBAs spend considerable time to prevent unauthorized access to the data and the database schema. Developers need to have gated access to the data with cooperation of the DBA. Any tool that’s built by the ADO.NET team should deal with the rights of the objects at all levels.
- ADO.NET and the Visual Studio interfaces still can’t update hierarchical rowsets. This needs to be addressed.
- Working with data schema changes and keeping application interfaces in sync. While some versions of VS can make changes to the schema, these are not propagated to the applications. Currently, there is no mechanism that records the dependencies between applications and the stored procedures or table schema upon which they depend. This means when the schema changes (as it always does), developers must repeat the tedious (and error-prone) drag-and-drop operations to resync the generated code with the schema. Figure out how to automatically morph deployed applications to deal with data schema changes. Identify applications that can’t be morphed automatically. Help DBAs understand the impact of their changes.
- Work more effectively with business rules and client/middle-tier validation.
- Provide additional data source device drivers – flat file, delimited file, CSV. The Framework includes all the needed functionality to access unstructured and semi-structured files. There should be a lightweight (as in NON-JET) CSV providers that work with both 32-bit and 64-bit platforms.
- Figure out how to tell applications (and developers) why operations don’t work. This is especially true for connecting. Generic error messages don’t really help.
- Figure out how to let ADO.NET to get out of the way and let developers execute SQL syntax without having it wrapped in sp_execute that prevents some SQL to even execute.
- CommandBehavior should be added to all of the DataReader methods that require a connection. As it is, if I open a connection in a function that executes a non-rowset-returning query (ExecuteNoQuery, ExecuteScalar, etc.) there is a chance that the connection is orphaned.
- Fix bugs. There are still a wealth of serious bugs that need to be fixed before a single new feature is given manpower. Many of these issues must be fixed even if you do have to step the framework.
As I see it, there is so much work to be done on ADO.NET, that branching off and defocusing some of the brightest minds in the group just to appease a noisy minority (the OR Mapping fans) does not make sense. I almost seems like a way to justify their existence. Based on what I have heard, there is not a consensus between the product teams (Visual Studio, SQL Server and ADO.NET to name a few) on the Entity Framework implementation(s) being proposed. I know there is a need to provide ORM to the industry but those that are crying for it have several established, functional (and as I hear it) far superior products from which to choose.
The EF might be needed by some subset of developers, but mainstream developers need support too for existing architectures.