Why Create YADAI?

The "DataWorks" team at Microsoft (the folks who invented ADO.NET) has been hard at work reinventing ADO.NET (again), and, yes, they managed to create yet another data access interface (YADAI) for Visual Studio 2005. To be fair, the DataWorks team feels the need to build data access and user interfaces to help developers from all levels of experience, from rank amateur to front-line professional. While the classes I discuss in this chapter won't help everyone, they can help some developers as they try to build many basic-to-intermediate applications. If you delve into SQL Server Everywhere you'll also find that these wizards and classes are an almost perfect fit. That's because the SSEv engine is designed to support small, single-user databases. Sure, developers (and applications) might outgrow these drag-and-drop and pick-from-a-dizzying-list-of-options UI code generators, but until they do, it's best to understand how they work, what they are capable of doing, and (most importantly) what they can't be expected to do. And, yes, these tools can help build serious applications, but with a number of limitations that I discuss throughout the book.

The DataWorks team has been struggling with a number of problems. Some of these include:

• The DataAdapter Configuration wizard generates code that simply populates an untyped DataSet. Microsoft wants developers to create strongly typed DataSet and DataTable classes. They tell us that strongly typed data structures with their "type-safe" data elements are more secure and easier to work with.

• The inability of the DataAdapter to support custom (developer-defined) Fill methodsespecially those that accept parameters. This makes it difficult to use the DataAdapter to return rowsets from other than the one (and only) SelectCommand SQL query.

• The DataAdapter Configuration wizard did not provide enough flexibility for a number of scenarios. The most important of these issues is the inability to determine how collision detection is to be performed.

• The Update method makes a round-trip for each row in the target DataTable that's added, changed, or deleted. Round-trips are expensive, and this approach degrades performance.

• Developers wanted to be able to alter the code generated by the DataAdapter Configuration wizard (DACW) but were thwarted, as any customization made to the generated class code was overlaid if the DACW was reexecuted.

• The inability of the DataTable to be serialized or support DataSet methods needed by some developers. Many developers have felt that the DataSet imposed too heavy a burden when a single DataTable would have sufficed.

• In theory, Visual Studio 2005 permits developers to generate code sourced from XML Web Services, custom business objects, as well as traditional relational data sources. Any new data access interface must support all of these sources.

• ASP.NET Web Services and business objects are a growing source of data, and the current tools don't adequately help build applications to expose their data.

• The new ReportViewer and other bound controls needed an easier way to define a Connection, queries, and rowsets needed to populate the reports and controls.

Do the Data Source Configuration wizard and TableAdapter address these problems? Yes, they doat least, to a large extent. Many of the other issues are dealt with by fundamental changes in the .NET Framework and the CLR languages.

Consider that Visual Studio has evolved over the last 8 years (or so) from a COM-based linkage builder to a code generator. In the Visual Basic 6.0 days, developers were encouraged to drag and drop (just as they are today), but the IDE was charged with connecting user-written code to the properties of canned (black-box) COM objects like the Data Environment Designer. The VB6 Data Object wizard (DOW) was the first prototype of the DataAdapter Configuration wizard, which further evolved into the Data Source Configuration wizard and TableAdapter code generators. Today, Visual Studio 2005 is a sophisticated code generatorthe volume and complexity of the code it generates is startling (and often intimidating). Fortunately, Visual Studio 2005 does a passable job of keeping this auto-generated code, hidden, correct, and protected from changes you make to other parts of the project.