Why You Need to Learn Visual Basic .NETWhile classic Visual Basic is a powerful and relatively simple programming language, it has reached a "glass ceiling" in addressing the requirements of current technology. For example, classic Visual Basic provides no direct access to underlying APIs, nor does it provide inheritance—the ability to incorporate functionality from another class. Classic Visual Basic programs are also difficult to fine-tune because they are far removed from the underlying mechanics of what's going on.
In addition, classic Visual Basic works fine for developing software for the Windows platforms because Windows 95, Windows 98, Windows Me, Windows NT 4.0, and Windows 2000 all rely on the Intel x86 architecture. But today's developers simply need more horse power, for more horses.
Visual Basic .NET is an entirely new way of developing software. It will let Visual Basic programmers address the advances in hardware, communications technology, miniaturization, and the Internet, which are all converging at a breakneck pace. I for one don't want to go through again the sort of development issues encountered when PCs moved from 16-bit to 32-bit architecture and two separate executables had to be tracked and managed depending on the platform a customer was using. In the next year or so, this management nuisance will seem like good times by comparison to the array of different platforms we will have to program for. The new 64-bit Windows is right around the corner, and more and more companies are relying on the Internet to distribute information and services. These companies want to distribute information to cell phones and wireless hand-held devices. Newer smart devices and appliances are also being developed daily. These wireless devices, as well as Windows CE, which is used in Pocket PCs, all run on a non-Intel x86 CPU—and let's not forget about the Palm OS based on the Dragonball chip. The obvious problem is how can a Visual Basic developer build software and distribute it to all of these disparate devices. With classic Visual Basic, that's impossible.
Instead of having to learn new techniques to optimize programs for specific hardware and operating systems, use separate architecture-specific compilers for each new (or yet devised) platform, and then track each and every version, developers can use .NET. At the center of this new approach is the common language runtime (CLR). The CLR (which I'll describe in more detail later in this chapter) provides many benefits to Visual Basic programmers, not the least of which is the means to program in any .NET language—Visual Basic, C++, C#, or one of 17 others that target the CLR. Components written in Visual Basic .NET can be called and used by those written in COBOL .NET, for example.
![]()
![]()
![note]()
Don't get the idea that Visual Basic .NET is designed exclusively for developing applications for the Internet. To the contrary, while Internet services and code reuse are now available to us, Visual Basic .NET makes developing stand-alone Windows programs easier than ever as well. Microsoft has devoted lots of resources to ensure that you can continue to build robust and fast Windows-based applications. We don't lose our classic Visual Basic expertise. Instead we gain functionality and power.
![]()
![]()
When you program with Visual Basic .NET, most applications can be deployed with zero-impact installations; in other words, installing an application is guaranteed not to affect applications already installed on a system. One of the immediate benefits you will reap is the ability to simply use XCOPY to install your entire application. You no longer have to write complicated and error-prone registry entries. You don't have to use regedit32 to register components. And, one of my personal favorites, you don't have to contend anymore with conflicting or out-of-date DLLs. How many times have you installed a new program only to find that programs that were working now don't? Often this error was caused by an older or incompatible version of a DLL being installed over the current file by the new program. This problem alone caused countless hours of sleuthing, at least in my experience. The Microsoft .NET Framework puts an end to DLL Hell once and for all.
In most cases you simply install your Visual Basic .NET application and all the files associated with it in a directory, and you're done. At first blush, this approach might sound unbeatable, but there is more. Consider when you have to uninstall a classic Visual Basic program. The results are often unpredictable. Many times the client machine is left with orphaned files and registry entries. With Visual Basic .NET you simply delete the contents of a directory (or directory tree) and the application is completely removed from the machine. Help Desks everywhere will love this.
From COM to .NETAs you probably know, Visual Basic and Visual C++ have separate run times, each with its own distinct behaviors. C++ revolutionized software development by making object-oriented programming widely used. However, C++ objects could only be used by C++ code, which didn't benefit most programmers; the majority don't use C++ as a result of the steep learning curve required to understand it. In order to solve the problem of interlanguage communication, Microsoft developed COM.
COM is really a contract, a set of laws that determine how to build a COM component. If your component follows the COM rules, it can work with other COM components no matter which language they are written in. When you added a new tool to the Visual Basic 6.0 toolbox, that .ocx file was probably written in C++, but you didn't need to know or care. You just wanted the functionality the control provided.
COM deals primarily with interfaces. Not graphical user interfaces, but application programming interfaces. In fact, a COM object is primarily composed of interfaces. If a component adhered to the COM blueprint for how to lay itself out in memory and provided a set of standard interfaces, other COM-compliant software could reuse the component.
COM acts as a binary object–interoperability standard. A COM software component is a piece of reusable software in binary form—a self-contained block of functionality such as a grid control or a text box. COM components register themselves in the Windows registry, and any program that knows how to find them can use them. While this approach has, for the most part, worked well, inadvertent version or interface changes by an unwary programmer have caused occasional problems. And when you wanted to spawn a process on a remote machine across the Internet, things rapidly became tricky.
Distributed COM, or DCOM, attempted to solve this problem. Unfortunately, DCOM is difficult to configure and set up and works only on Windows machines. In order to accept marshaled DCOM data, a port in the firewall had to be opened and therefore exposed to hackers. This requirement made more than one corporate IT manager raise an eyebrow. CORBA was developed as a competing but incompatible approach to interoperability in the UNIX world.
As the corporate world becomes more comfortable with the Internet and relies on it for mission-critical system needs, a better solution than DCOM is needed. Businesses all over the globe are setting up shop on the Internet at a breakneck pace. Electronic Data Interchange (EDI), the scheme born in 1985 that's used for ordering, invoicing, payments, and updating back-office systems, is experiencing a renaissance of sorts with the Internet. If business-to-business e-commerce is going to reach its full potential, a platform-independent and language-independent standard is needed. The .NET Framework provides the pieces to make this level of interoperability a reality.
The .NET WorldThe raison d'etre of .NET is to provide users with access to their information, files, or programs anywhere, anytime, and on any platform or device. Users should not have to know where the information is located or the details about how to retrieve it. For example, over the next several years Microsoft and other companies will phase out delivering software on CDs. Instead they will deliver the functionality that users get today from software installed on their desktops via Web Services delivered over the Internet. Consumers of those services will no longer buy software, install it on a machine, and then maintain it. Instead they will license the functionality as an on-demand service. The software bits will be downloaded, installed, and maintained by a Web Service. Updates and patches will happen automatically via the Internet. If you need to use a particular piece of software for a project, such as an expensive CAD/CAM program, but don't want to purchase it, you'll be able to use it via a Web Service and be charged by use.
As you can see, this is a large vision that considers the technology and business horizon in the not too distant future. Learning Visual Basic .NET not only puts you on the forefront of this exciting and revolutionary vision, but it also permits you to be more productive with today's applications. Bill Gates summed up things nicely when he told a group of developers recently, "Today, we have a world of applications and Web sites. In the .NET world, everything that was an application becomes a Web Service." Web Services means the sum is greater than the parts.
A .NET ExampleI always find understanding a new concept easier with a concrete example. Let's say you're charged with developing a program that moves funds across different currencies for a financial institution. Designing this program requires that currency conversion rates be calculated in real time, which allows a customer to send a dollar-denominated wire transfer and have it converted to deutsche marks (DM) for payment to your branch in Berlin. The customer of your service would have to know, in real time, how many dollars are required to pay the bill of DM10,000 the moment the wire was sent. You could try to figure out how to create a real-time currency conversion program, but where would you start? How do you get the rates? What is the risk of getting it wrong? How timely is the information? And on and on.
Programmers might spend months or more just writing the specifications and the code for a program like this. Then there is testing and debugging, which will take another few months. My company, however, offers a Web Service that provides real-time currency conversion rates. My Web site provides a service, and your Web site consumes it. When a customer logs into your secure Web site, behind the scenes Visual Basic .NET code makes a request for conversion rates from my site using a protocol called SOAP (for Simple Object Access Protocol; more on SOAP later—for now, trust me). You don't have to know or care whether my site runs on Windows 2000, Solaris, UNIX, or whatever.
The .NET strategy permits us to do away with DCOM to get information from another computer platform anywhere on the globe in a secure and efficient manner. Your Web Service consumes my Web Service in a method that is completely secure and transparent to your customer. You might also sign up with another Web Service provider that offers the best arbitrage rates on currency and yet another provider that validates and stores customer security information. When your Web Service consumes several other Web Services to provide a customized product or service, that is known as a federation of Web Services. Your customer does not know that you are using a federation of Web Services, built and maintained by others, to provide your end product. By using various Web Services (secure, transparent, functionality providers), you not only outsource the development by using their code but also outsource the risk because the service providers have domain experts on staff and have the various government certifications and insurance. You simply consume their secure Web Services and add the results to your own service. This scenario is the ultimate in code reusability because it's on a global scale. Your development team is free to spend precious time and resources on developing applications to meet the needs of your customers by consuming Web Services from experts in various domains and assembling them in customized ways.
But let me stress that if you write any Windows software, Visual Basic .NET will continue to provide current and additional functionality. Your software will also be able to run on non-Windows platforms, very much like Java.
![]()
![]()
![note]()
Most people know the Java language mantra "write once, run everywhere" from a few years back, referring to the Java Virtual Machine. After working with early renditions of Java, some developers used to joke that the phrase should really be "write once, debug everywhere." The designers of the .NET Framework certainly got the "write once, run everywhere" concept right.
![]()
![]()
Wahana Programmer Groups Links
<*> Untuk mengunjungi sponsor milis ini, klik link berikut:
http://wahanaprogrammer.net
<*> Untuk menghubungi owner milis ini, kirim email ke:
[EMAIL PROTECTED]
<*> Konsultasi pemrogramman bisa chat disini:
Yahoo! Messenger: wahanaprogrammer
| Programmer | Indonesia | Basic programming language |
| Computer programming languages | Programming languages | Java programming language |
YAHOO! GROUPS LINKS
- Visit your group "Programmer-VB" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
