| |
|
Visual Foxpro versus .NET - An Obvious
Choice? Not necessarily.
In March of 2007, Microsoft announced that Version 9.0 of Visual Foxpro
would be the last full release; there would be no subsequent versions.
Directly or indirectly, Microsoft has encouraged developers and businesses
alike to pursue the use of applications that utilize the .NET framework.
Microsoft will continue supporting Visual Foxpro until the year 2015.
That doesn't mean that VFP will stop working, or that there won't be anyone
available to provide support for the myriad of VFP applications that will
likely be up and running at that time.
So what's a savvy business manager to do? The answer is, "That
depends."
Consider the following scenarios:
| 1 |
ABC company has developed a custom order entry system
from the ground up
over the course of the past 15 years. They started with Foxpro for
DOS, and continued upgrading to take advantage of the enhancements each
successive version of VFP offered. Today, their application
encompasses several hundred thousand lines of code, and serves as the
backbone of their business. Management is hesitant to jump ship to
another platform. Their philosophy has been, "if it ain't broke,
don't fix it." |
| |
|
| 2 |
John and Joe Wilson, two brothers who launched a family
business a few years ago, have recently started franchising their
operation. They've decided they need software to manage sales,
marketing and personnel data coming from multiple franchises. |
| |
|
|
|
|
For die-hard VFP programmers, the VFP-vs-.NET question used to be a
no-brainer. VFP could run rings around earlier versions of .NET both
in terms of functionality as well as speed. With the advent of .NET
version 2.0, data handling became much more robust. And the developer
environment has become increasingly more developer-friendly. Perhaps the
best answer for customers and developers alike is, "be flexible." As
newer 64-bit equipment and operating systems become more commonplace, it
makes sense to start migrating VFP applications over to the .NET
environment.
Most large applications we've seen are usually comprised of several
smaller building blocks. Perhaps it would be wise for management to
map out a plan to migrate individual components to .NET over a period of
months, or even years.
This article doesn't purport to serve as the be-all, end-all answer to
the question. But hopefully it has provided some food for thought.
|
|
