The Right Time to Migrate

Dino Esposito

February 8, 2001

Welcome to Diving Into Data Access, a new column dedicated to examining data access issues and solutions.

I'm Dino Esposito and, according to my business cards, I'm a trainer and consultant based in Rome, Italy. My previous life includes stints working on some of the very first Windows DNA implementations, and a key role in the development of Europe's first online image databank in the pre-Internet era.

In my current life, when I'm not writing the Cutting Edge column for MSDN Magazine, I normally write and teach ADO.NET and ASP.NET classes for Wintellect and spend most of my time helping companies plan migration to the .NET Platform.

In distributed systems, the data tier is often the one that people care about least. In fact, both at design and at implementation time, much more attention is reserved for seemingly bigger issues, such as scalability, performance, and interoperability.

The subliminal message that developers often receive is, "Don’t waste your time with databases—we've just hired great DBAs. Concentrate your efforts on components." But when it comes to taking concrete measures to improve performance, scalability, and interoperability, the data access layer turns out to be the first element you have to look at.

So twice a month, I'll be delving deep into this intricate forest. To start off, I'll touch on a topical subject: How (or if) the advent of ADO.NET will change your life.

The Good and the Bad

There are good and less-good things about ADO.NET, and I'll be exploring and investigating those issues in this column. In the meantime, here's a story to illustrate my point:

An IT manager passes away and knocks on Heaven's door. Once logged on, he is given a hard choice: Hell or Heaven. He negotiates and manages to get one day in Hell and one day in Heaven before he has to make his final decision.

During his stay in Hell, he meets a lot of colleagues and friends who have passed away. They play golf, eat in good restaurants, and spend the night jumping from one party to the next. In person, the devil seems like an easy-going, nice guy. Not too bad, the IT manager thinks.

During his stay in Heaven, he enjoys celestial music, flies with angels, spends time jumping from cloud to cloud, and relaxes. Too boring, he thinks, for all of eternity.

Overall, he reckons that he had a much more enjoyable time in Hell. So he asks to go there and takes the elevator down. But when the doors open, he sees the real Hell. The devil has a much less reassuring face and behaves as expected.

"Why this sudden change?" the IT manager asks. The devil replies: "Yesterday we were hiring you. Today you're part of the team."

Is there an ADO.NET lesson we can learn from this?

ADO.NET is neither Heaven nor Hell. What appears like Heaven today can soon become a nightmare if you embark on the wrong project or approach the project in the wrong way. And vice versa, of course.

As an IT manager, a lead developer, or just one of those too often underestimated data access people, don't let appearances fool you. Take more than one day to form your own project-specific idea of the benefits and the issues that ADO.NET can put on the table.

As with many other new technologies, ADO.NET is often presented as a way to change, or even save, the world. In the past, we've perceived ODBC as a revolution, RDO as a great step forward, and ADO as the final phase in the evolutionary process of simplifying, while empowering, data access. At this point, ADO.NET might reasonably appear as the umpteenth data access layer you upgrade to just because it is in the natural order of things.

Migrating to ADO.NET is not a step to take lightly; it's an integral and consistent part of the .NET Framework. You don't choose ADO.NET for your data access needs. Instead, you opt for .NET as your platform and use ADO.NET for your data-handling code.

Waiting for the Right Time to Migrate

Changes in seasons are always a good time to migrate. This applies to information systems as well as to birds. Birds, though, have a built-in mechanism that tells them when it's time to port themselves toward warmer platforms. Unfortunately, this is not the case with information systems and Web applications.

I don't think there is one right time to migrate. And even if this time existed, it could not be determined algorithmically. Don't hurry to move code that today runs fast enough and fulfills at least a large part of your client's expectations.

On the other hand, you can start to prepare yourself for .NET. When it comes to deciding about upgrades, consider what you can gain and what you can lose. With .NET, you also cannot afford to forget to weigh the time it will take to upgrade. Data access is only one aspect of an information system—but it is also the aspect that all applications worldwide have in common.

There are good reasons for migrating as soon as possible, and as many good reasons to wait. In any case, what matters is that you learn as much as you can about .NET in general and data access in particular.

Data access is critical to any real-world application. Furthermore, data access in .NET is not exactly backward compatible. For example, transforming existing Active Server Pages to corresponding ASP.NET pages is relatively easy. The adaptation process requires only minor changes to make it work. (And if you're using server-side JScript, chances are that you also observe significant performance improvements. This happens because of the JScript.NET option(fast) switch.) However, existing ADO code can hardly become ADO.NET code. It can only become ADO code working in the context of .NET applications.

Real-world applications use COM components. They work against a data provider and write directly to the ASP's output streams, or return data through recordsets or XML strings. This code can be adapted to survive the .NET transition without too much effort. It suffices that you import the component's type library and it'll continue working thanks to the COM Interop bridge that .NET generously provides.

Does it really make sense to migrate this way? To exploit .NET to its fullest, you must understand its internal architecture and accept a new way of thinking. Actually, the .NET way of thinking is not much different from the well-known COM way, although it requires that you manage different objects and think of them following different rules.

How to position yourself well for .NET in general and ADO.NET in particular? Here's my three-step guide:

1. Forget about ADO objects.
2. Rethink and rewrite your code employing the ADO.NET philosophy and objects.
3. Refine and optimize your code in light of your previous ADO experience.

In other words, forget the details of ADO and OLE DB coding, but retain and revalue the concepts running behind them that you have learned over time. Rethink them in light of ADO.NET. You'll realize that ADO.NET is inherently elegant, consistent, and much more general-purpose than ADO. It is as flexible as OLE DB, but no longer limited to expert and scary-smart C++ developers. You'll discover that ADO.NET is also much simpler and at the same time more specialized than OLE DB.

Take some time to understand ADO.NET. Compare it to ADO and see how you can change and improve things in your own specific context.

Reasons to Migrate

The compelling reasons to migrate to ADO.NET and ASP.NET are performance, and ease of development and maintenance. Both ASP.NET and ADO.NET take some common best practices and integrate them into an all-encompassing and consistent framework.

When you rewrite your Web applications, you soon realize that there's a component that does just what you were looking for. You have a session manager that acts as a service and survives Internet Information Services crashes. You have an object that embeds multiple tables of records. You can store objects in the ASP.NET Session object without bad surprises. You can do batch updates using your own stored procedures and against any data provider. You have a ready-to-use datagrid component that is also highly customizable. You don't experience any overhead to translate your recordsets to XML. You can change the XML schema at will. You can choose the navigation model that you like better to walk through your records.

Developing for .NET is easier at whatever latitude you consider: presentation layer, middle-tier, or data access. ADO.NET, moreover, provides you with a set of objects that remains the same no matter which programming model you target: Windows Forms, Web Forms, Web Services. As long as you have a data source in the back end, ADO.NET provides the same kind of help.

Moving to ADO.NET also means that you can disregard the dualism between ADO and OLE DB components. Today, direct OLE DB calls are possible only with C++. They are faster but more error prone, and they require special skills that are not available in all teams. ADO, on the other hand, has been specifically designed for ASP and Visual Basic developers, and offers lots of facilities that C++ programmers would also welcome.

ADO.NET terminates this dualism by exploiting the language neutrality of the hosting framework. It delivers the same set of facilities no matter the language and no matter the programming model.

Reasons to Wait

As I mentioned earlier, moving to ADO.NET is not a single-step process. There are no half measures. Either you leave your system as is, or you rethink it from scratch, defining a mid- or long-term migration plan.

You must redesign the core data access functionalities to exploit the new features and the new objects of ADO.NET.

Do you have the resources to maintain the current version of the system while you study .NET? Before putting your hands on the core system, you should have some experience with at least one pilot project. If you take the .NET challenge lightly, you risk going far beyond your budget.

In an ADO.NET project, you put your database, SQL, and ADO skills on one scale and try to balance the new object model and the new policies built into ADO.NET. You can build on your understanding of the problems and the data access strategies in your specific context. You can use your high-level knowledge of ADO and OLE DB. And you can depend on your experience with IIS and ASP if you're working over the Web.

Checkmate in Three Moves

To move an existing system to .NET, first install the .NET run time on at least one of your servers. Then you can start modifying your original middle-tier objects. You can force them to make calls into new pages and components running on a separate server that features .NET.

Figure 1. An existing system communicates with a new .NET system through the Web Service interface

Users will continue to invoke ASP pages, which, in turn, will continue calling into the same middle-tier objects. These objects, though, can now open new channels with a back-end .NET-enabled system. How can COM(+) and .NET objects communicate? Through a Web Service interface. To invoke a Web Service, you need only know its programming interface (what is now called the Web Services Description Language) and be ready to handle XML return strings. The following script code utilizes MSXML 3.0 to invoke a method on a Web Service from an ASP page or a COM object.

Set srvXmlHttp = CreateObject("MSXML2.ServerXMLHTTP")
Set xmlResult = CreateObject("MSXML2.DomDocument")
srvXmlHttp.Open "GET", 
"https://myserver/myapp/webservice.asmx/Method", 
false
srvXmlHttp.Send ""
Set xmlResult = srvXmlHttp.responseXML

The xmlResult object holds an XMLDOM document with the data the service returned.

An alternative approach involves the so-called COM Callable Wrapper (CCW) engine, which runs in the Common Language Runtime (CLR) and turns a .NET class interface into a COM-compliant interface. In other words, CCW transforms a .NET class into a COM object so that any existing COM client can call into it.

The second step of this mid- to-long term migration is illustrated below:

Figure 2. Presentation and data layer are now separated from the middle tiers

You can then start utilizing a smarter presentation layer that is capable of calling both ASP and ASPX pages. You don't need to do scary-smart things, but be aware of which functionalities are exposed by the .NET-powered subsystem and which are still outfitted by COM(+) components.

On the back end, the data providers remain unchanged. You use OLE DB in the unmanaged code, and the newer managed providers from within a .NET solution.

Finally, the third phase of this migration process requires you to merge the functionality of the two middle tiers into one business layer. To do this, though, you have to rethink the implementation of all of your business logic and data access strategies. When this happens, the migration process is complete. It's not easy to generalize about how to do this. Much, if not all, of it depends on the specific architecture and context you're working with.

Speaking ADO in the Land of .NET?

The main advantage of this progressive migration is that you can take the time you need to form and fine-tune your .NET skills.

Using ADO objects from a .NET application is certainly doable. You use the Run-time Callable Wrapper (RCW)—the COM-to-.NET counterpart of the CCW—to import the ADO COM objects in any .NET application. This done, you manipulate ADO recordsets, commands, and cursors through the native ADO interface.

This allows you to reuse some code you may have, but it might introduce unpleasant side effects. It is obsolete, inefficient, less functional, and doesn’t allow you to exploit the inherently more scalable and interoperable architecture of ADO.NET. In other words, just because you can do something doesn't mean you should.

So, to answer this section's question, should you speak ADO once you are in .NET territory? No, not unless it's strictly necessary. In my next column, I'll take a plunge into this specific topic.

For More Information

For more basic information, see Introducing ADO+: Data Access Services for the Microsoft .NET Framework.

Dino Esposito is Wintellect's ADO.NET expert and a trainer and consultant based in Rome, Italy. Dino is a contributing editor to MSDN Magazine and writes the Cutting Edge column. He also regularly contributes to Developer Network Journal and MSDN News. Dino is the author of the upcoming Building Web Solutions with ASP.NET and ADO.NET from Microsoft Press, and the cofounder of https://www.vb2themax.com/. You can reach Dino at dinoe@wintellect.com.