VSLive! Speaker Interview—Bill Vaughn

VSLive! San Francisco is proud to have Mr. ADO himself, Bill Vaughn lead the sessions From ADO to ADO .NET: Migration Made Easy and ADO .NET and Exception Handling. As a sneak preview we asked Bill some of this thoughts on ADO .NET. Though an enthusiastic user of Microsoft tools for many years, he believes that love isn't blind—just accepting. As you'll see from this VSLive! speaker interview.

What's it like working with Visual Studio Beta2?
The Beta 2 is an order of magnitude more stable than Beta 1, and the objects, properties & methods I work with make a lot more sense than they did in Beta 1. Moreover, the philosophical directions have been cleared up—they seem to make sense, even though I don't necessarily agree with all the approaches taken.

What makes sense?
The way that ADO has been reinvented. It makes sense in the light of the kinds of data structures they want to pull back. They want to leverage their new disconnected or disjoint recordset architecture that they really started in COM-based ADO, which I call ADOc to avoid confusion . ADO .NET leverages the years of development Microsoft poured into DAO (Jet), RDO, and ADO, the jet engine, the shape provider that they got from FoxPro, the ADOMD (multidimensional extensions) and the ADOX extensions—they put the best parts of all of these into ADO .NET.

And what doesn't make sense about ADO .NET?
I think they chose the wrong name—that it would be clearer if they called it XDO, because it's based on XML behind the scenes, and because it uses a whole new XML-based paradigm. It would be easier for COM-based ADO developers if they realized it's a whole new interface. It doesn't look like COM-based ADO, doesn't code like it, doesn't behave like it. It's not bad—just different. So developers are initially going to struggle with ADO .NET. They can open a connection,—it won't be that hard to open a connection. But instantiating the queries, constructing and executing queries, and getting a result are all different, even though what's going on behind the scenes isn't. I think if they called it XDO, developers would say Oh no they've given us another TLA. And Microsoft could have said "But we didn't want to confuse you by calling it ADO." And it would blow over.

Anything else?
Some of the documentation and Microsoft speakers have said that ADO .NET this object or that object was equivalent to a Recordset with an open method, a move method and a fields collection. But there is nothing you can use an Open method against that can get data. The MoveNext and the associated rowset navigation is all gone. It has all been replaced with other objects/methods/techniques for getting data.

What are some of your favorite ADO .NET innovations?
One of the most powerful features of ADO .NET is being able to deal with multidimensional queries from the outset. COM-based ADO uses a flat model: you get back one result set and deal with it. But the ADO .NET architecture lets you pull back multiple result sets and manage them in the new DataSset objects as related entities. So ADO .NET embodies another paradigm shift, with a new multidimensional way of looking at and managing data built into the architecture instead of tacked on, as it was in ADO.

Is anything missing from ADO .NET that we had in ADOc (COM-based ADO)?
ADO .NET has no server-side data providers at this point. This means no server-side cursors, no pessimistic locking no server-side state management. However, nothing in the architecture precludes creating these. So I assume they will appear by version 2—probably in conjunction with the next version of SQL Server. They've already laid the ground work for this enhancement by naming the SQL Server managed provider "SqlClient".

How can you work around the absence of server-side providers?
You could just bypass ADO .NET completely and use the ADOc through COM interop. However, you pay a penalty: having to go through the interop layer each time you make a reference to the ADO COM objects. To get around this you're going to want to take your ADO COM objects and encapsulate them in a class or DLL that has one entrance and one exit. That way you go to the COM object, do the work (including any ADO work you have to do), then return to your .NET app. This avoids having to spend all your time switching back and forth. Of course that approach would also often require a dramatic rewrite of your code, so it's probably out of the question. You have a choice of using ADOc with the performance penalties or encapsulated with the development penalty. The question is just how much is this COM interop transition going to cost performance-wise, or the encapsulated re-architecting development-wise.

Can you measure performance at this point?
Not with the Beta 2 still full of debug code working behind the scenes. Saying it's faster or slower now is meaningless. You can only say that it's clear the interop layer is going to have some impact, which you can minimize through architectural changes in your app. It reminds me of what happened when we moved the code from in process calls to out of process calls with MTS, and used DCOM instead of COM to access the components. Suddenly it took longer going to/from the remote COM component than it did to run the code itself (or so it seemed). Which means if you've designed a COM component for MTS it may work just fine for ADO .NET, because it's already encapsulated.

What can we do with current development to prepare for porting to VS.NET?
If it ain't broke don't fix it. But that doesn't mean that you shouldn't be studying the .NET Framework and learning it and seeing where this new architecture best fits to solve emerging problems. Then again, if you're coding Winforms this won't mean as much as if you're working with VB Script and Active Server Pages, which is a terribly slow combination. The.NET technology directly addresses the issues associated with ASP development. If I were writing ASP code today I'd certainly be thinking about re-engineering it and getting ready for .NET. There are many, many Winforms developers that have perfectly good architectures running perfectly good apps that don't depend on the public Web at all. So they'll be hard pressed to see the advantages of .Net in terms of converting existing apps. However, even these platforms will eventually come around to the other benefits of the CLR and XCopy deployment—just not as quickly.

What about your own work with VB.NET?
Now that I've started working with VB.NET it's addictive. It's tough to go back to VB6 and see how crude it is compared to VB.NET. Just an entirely new dimension of sophistication. The VS UI is far easier to use and far more helpful. And the interaction with the data by way of the Server Explorer is far more sophisticated than the old Data View window. Moreover, the ability to integrate the development and debugging of stored procedures right into the UI is great.

Do you still have to code stored procedures in TSQL?
Yes. I don't think you're going to see a new language for stored procedures until the next version of SQL Server (which I haven't seen yet). But you can step into stored procedures directly from the UI and it works; in VB6 it never did, not really (unless you had your system blessed by a Brahman priest).

What else do you really like in VB.NET?
They've kind of combined the MDI child paradigm we had 4-5 years ago with a browser paradigm multitab approach where you can use a single window for several things, including text for stored procedures. I can select it at will. And it really knows how to leverage the space on the desktop better than VB6.

From my point of view the other real innovation in .NET is that for the first time since before Visual Basic we have a way to talk straight to SQL Server in its native tongue. In every version of VB before .NET we had to talk to intermediaries, such as Jet to ODBC or the ODBC driver. It imposed layers between us and the low-level protocols. VS.NET exposes the tabular data stream (TDS) almost directly using the SQL Client provider. This gives us the potential for having blazingly fast SQL Server apps, plus the potential of exposing features of SQL Server that can only be accessed through TDS. Potentially we'll have the ability to run SQLDMO-like functions (the APIs used to manage SQL Server itself—start/stop/attach/backup/restore databases) if they add them to the SqlClient provider.

What about accessing Oracle from VB.NET?
The same paradigm can be applied to Oracle because they can create their own native interface provider to ADO .NET. I think they're going to do it if Microsoft doesn't. When people start benchmarking these apps against the old fashioned OLE DB provider, you'll see a dramatic difference in performance. I have a feeling that Microsoft is already working on it.

Anything for FoxPro in the .NET world?
I thought there was a FoxPro implementation in Beta 1, but I don't see any evidence of one in the Beta 2. FoxPro remains an important player in Europe/Southeast Asia/South America. One way to cause a riot in Europe is to list viable database platforms and leave out FoxPro in a dev talk. It's entrenched in many non-English-speaking markets—probably due to having been localized and in the market some few months before Access was available.

What will be the main transition cost for .NET?
Much of it will be "people" expenses. We're going to have to "reprogram" those people to create good .NET apps. It will be a big job to reeducate the development community. Meanwhile the development managers have seen an outlay of millions/billions of dollars in training over the years, and they're wondering "How much of that is gone? Wasted? And will there be an end?" There are companies and divisions of companies with no public presence on the Internet. For example, JC Penny has a large public presence but also a large intranet-based infrastructure that doesn't expose its code to the public. They could use .NET for that but they don't have to. Others that are depending on the public Web will need to. I can imagine a company with offices all over the country that need to communicate with each other—they can use the public Web and depend on its infrastructure. Of course, companies are discovering that they intercommunicate on the Web at their own peril.

Do you see any alternatives to VS.NET for the VB 6 developer?
Microsoft is sensitive about how the product is spun by the press and perceived by the development community, and worried about VB 6 developers feeling disenfranchised. But all the alternatives are all more difficult than moving to .NET. Delphi represents another radical paradigm shift. COBOL might be easier… But it is about that much of a paradigm shift. Java is also a major paradigm shift.

Do you like Java?
There's not a darn thing wrong with Java that couldn't be solved by it not belonging to Sun. I think Sun has killed it. It's clear now that the language was developed to help hardware sales. They're in the hardware business. The language is a loss leader designed to help developers buy their boxes. It's like what Apple's done. And where is Apple today? In decline. Sun is also a powerful company, but there are cheaper alternatives now that don't require their kind of expensive server.

What about C# for VB developers?
C# and VB.NET are so similar—why bother? You don't get that much more and you lose every scrap of familiarity. It's not that hard to learn. I can read C# code fairly easily now. But why bother? I can do 150% of what I need to do in 20% of Visual Basic.NET—but I'm an old-fashioned kinda guy and focused on data access. C#, and to a somewhat lesser extent ,Visual Basic.NET is kinda like the latest version of Windows Word. It has a lot of features that the ordinary typist doesn't really need or understand the need for—but I use every feature that WinWord XP has and yearn for more. I expect professional developers will really dig their teeth into the Visual Basic.NET/C# development paradigm and yearn for more. The ordinary Joe or Jill will wonder what all that extra stuff is for.

What kind of hardware do you need to run the Beta 2?
I found in early tests that my CPU was pegged—perhaps because .NET recompiles at a drop of a hat. What I've found satisfactory for my development is a dual Pentium 1000 with 512MB of RAM. Even with this, I've watched the CPU task manager and performance meter and seen both CPUs pegged now and then. It's in the very nature of the beast. On the other hand, this machine only cost me $800 in parts, since I built it myself. Memory is the key here. Because you keep so much stuff in RAM. .NET seems to use every bit of available RAM—but not as much as PowerPoint that uses all the RAM on your system and every system within 40 feet of the podium.

So, are you headed to the store to buy a new PC to handle all this new stuff?
Well, the time it used all the RAM was when I was running a program to generate test data, which took eight hours or so to run. Normally it doesn't use it all. But just sitting here while we talk it's using about 256MB doing nothing except for running SQL Server in background. That means 256MB is immediately insufficient. I'd say 384MB absolute minimum.