|
Berikut saya adalah sharing dari rekan kita Bung Purwedi
beberapa waktu lalu:
mungkin ini bisa dijadiin gambaran umum mengenai perbedaan
mendasar antara vb6/vb.net dan .net teknologi itu sendiri.
source: Coding Techniques for Microsoft Visual Basic .NET / ©
John Connell. / Microsoft Press 2002
Why You Need to Learn Visual Basic .NET
While 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.
|
![Right-click here to download pictures. To help protect your privacy, Outlook prevented automatic download of this picture from the Internet.]() |
| |
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. |
| |
![Right-click here to download pictures. To help protect your privacy, Outlook prevented automatic download of this picture from the Internet.]() |
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.
masih dari buku yg sama
From COM to .NET
As 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 World
The 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 Example
I 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.
| |
![Right-click here to download pictures. To help protect your privacy, Outlook prevented automatic download of this picture from the Internet.]() |
|
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. |
| |
![Right-click here to download pictures. To help protect your privacy, Outlook prevented automatic download of this picture from the Internet.]() |
Semoga bermanfaat.
Halo teman-teman yang ahli vb. Saya baru belajar vb
6, dan pengin tau
Apa perbedaan vb 6 dan vb.net
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
YAHOO! GROUPS LINKS
|
