Microsoft claims that Web developers can build more powerful Web applications faster with ASP.NET than they can in traditional Active Server Pages (ASP). The company's claim that Microsoft .NET enables "faster, more powerful, and more scalable Web applications in half the time" doesn't seem logical because new technology always comes with the high price of a learning curve. And in ASP.NET's case, Web developers face not only the technology's steep learning curve, but the need to learn two (and potentially more) new programming languages—Visual Basic .NET and C#.
But Web application developers who use ASP.NET can build more powerful applications dramatically faster than in traditional ASP. One reason why is the power of more than 6500 .NET framework classes, which constitute the .NET Framework built on the Common Language Runtime (CLR). You can compare .NET framework classes with the Win32 API available to traditional C++ Windows programmers. The Win32 API gives software developers access to the "plumbing" of the OS and surrounding systems without requiring that they write code. Using the Win32 API is not for the faint of heart; in most cases, Win32 API's complexity requires an expert-level software developer. Having more than 6500 .NET framework classes at your disposal in .NET gives you superior Win32-type power but with a simplicity that beginning or average-level Visual Basic .NET developers can handle easily.
Another reason why ASP.NET gives you an advantage over traditional ASP is the Visual Studio .NET tool, which is so far superior to its predecessor, Visual Studio (VS) 6.0, that comparisons can't be made. Visual Studio .NET has a learning curve, and I admit that I haven't come close to mastering it. Every day I learn something in Visual Studio .NET that simply amazes me. One of Visual Studio .NET's biggest advantages is automatic code generation. By letting Visual Studio .NET automatically generate a significant part of the code during application development, savvy Web developers can let Visual Studio .NET do most of their work. Automatic code generation is a great benefit, but relying on it too much can be dangerous.
Last February, when I went onstage with Microsoft Chairman and Chief Software Architect Bill Gates and Chris Flores from the Visual Studio .NET team at the Visual Studio .NET launch event in San Francisco, I had 1 hour to use Visual Studio .NET to build a fully functional Web application. People are still amazed at how much I accomplished in an hour. But I let the tool do all the work. I wrote only 50 lines of code on the server side and 20 lines of code on the client side. Visual Studio .NET did the rest by generating thousands of lines of code. I built a fully functional and very powerful data-driven Web application that had Microsoft SQL Server 2000 add/edit/lookup capabilities through a Web service that displayed the relationships between a customer table, a products table, an orders table, and the line-item-details table of each order in three data grids on a Web form. I also used the Microsoft Mobile Internet Toolkit (MMIT) to build identical functionality in a mobile form for display on wireless Internet devices, such as cell phones and Research In Motion (RIM) devices. You can view the launch event and see what I built by clicking Bill Gates' Keynote at the following URL:
http://msdn.microsoft.com/net/vslaunch
During a session titled "Building Cool Active Directory Applications with VB.NET" at the recent Visual Basic .NET Connections conference in New Orleans, I built a fully functional tool to manage the data in Active Directory (AD) that has superior features and is much faster than the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in that ships with Windows 2000 Server. Although I built the tool onstage in 1 hour, again, I wrote very few lines of code. I let Visual Studio .NET do most of the work.
What's the catch? Well, if you let Visual Studio .NET automatically generate much of your code, you'll lose control of your application's architecture. Such loss of control isn't a problem in prototype and pilot applications; Visual Studio .NET's code-generation features are unparalleled for such use because they help you build applications quickly. However, every enterprise-class Web application needs a componentized data-access architecture for a common, consistent, and powerful set of architectural tools that software developers use to access data. In my launch-event application, I used a strongly typed data set that Visual Studio .NET automatically generated. If I were to turn my 1-hour application into an enterprise-class application, I might decide that the strategy Visual Studio .NET employed wasn't the best strategy for my needs. In that case, I would need to pick another data-access strategy, build a set of components to centralize the access, rip out the data-access architecture that Visual Studio .NET automatically generated for me, and swap in the new architecture.
I hope this information makes clear why you can more easily build powerful ASP.NET Web applications faster than you can in traditional ASP. But remember that Visual Studio .NET doesn't replace a seasoned software architect. You still need experienced software developers to build enterprise-class applications from the bottom up. Still, between the platform and the toolset, .NET is giving the industry power that software developers never dreamed of when they began building traditional ASP applications.
Tim Huckaby, News Editor, [email protected]
