Visual FoxPro is still considered one of the most simple, powerful, data centric, object oriented languages ever to come out of Microsoft’s stable. Ironically, Visual FoxPro was forsaken by Microsoft itself in favor of some of its home grown products. No other language could match its sheer diversity when it comes to writing code (be it OOPs or otherwise), its superlative data related activities (pointer based record operation) and it amazing versatility in developing rich, distributed client/server and even Web applications (with limited capabilities though).
Visual FoxPro got its name in 1992 when Fox Technologies merged with Microsoft and brought out their first joint release with a “Visual” flavor; distinctively flamboyant from its rather sober predecessor FoxPro v2.6 which was more akin to other products from the “xbase” language camps.
Visual FoxPro saw steady & rapid rise in popularity among developers and by 2005, became the number one favorite language for developing high-performance desktop, rich distributed client/server applications.
. In 2007, when Microsoft rolled out its Application Development Road Map, there was no place for Visual FoxPro in the Visual Studio suite. In March of 2007, Microsoft announced that there would be no future releases past its then current release 9.0. Microsoft announced that they would continue to support the Visual FoxPro core until 2015 with standard support through January 2010 and extended support through January 2015 via the developer tools life-cycle support plan.
All this hasn’t really affected its die hard developer base, who still continues to develop and maintain applications in Visual FoxPro and vouch for its flair, speed and convenience as a rapid application development tool.
Ever since Microsoft sounded the end for Visual FoxPro in 2007, its earnest community has been trying their best to keep the product alive; by extending capabilities through various web enabled plug ins or sharing code though CodePlex etc. But one thing was very clear in the minds of Visual FoxPro users; the end was imminent and any extra effort will still only delay the inevitable.
To make things worse, Visual FoxPro had other ailments like, rapidly dwindling numbers of developers, increasing costs in maintaining legacy systems for its clients and the incapability of extending the existing legacy application to embrace new technologies and IT trends like Web and/or Mobile computing.
This has left customers with very little choice but to either go in for a total Rewrite of the entire application in a new technology that would better suit future needs and/or demands, hunt for a new enterprise solution altogether with commercial off-the-shelf (COTS) software, or migrate their existing application into a new technology that would allow them to expand the applications functionality user base and delivery platform.
Visual FoxPro’s affinity to .NET is natural as they are both products of Microsoft and have many things in common, thereby making.NET the most ideal and instinctive choice when it comes to modernizing a FoxPro application.
Having said that, there is no denying the fact that .NET is far more superior and is laden with features and capabilities for user interface, data access, database connectivity, web application development and network communication, which makes it even more suited for modernizing FoxPro application.
For modernization, a Visual FoxPro application could either be moved in the same client/server enterprise setup using Win Form of .NET, or be made Web enabled by opting Web Form of .NET.
The biggest drawback with Visual FoxPro is its limited accessibility to Web (not intrinsic though) that makes writing applications with global reach difficult, a thing modernization of Visual FoxPro application(s) to Web Forms can provide with ease.
Once on the web, users from any part of the globe will be able to access the application through a web browser. Web forms resemble paper or database form, on the net, similar to input templates which when filled in by users, is sent to a server for processing.
MVC, Model/View/Controller is a software architectural pattern that “isolates” the domain logic from user interface, thereby permitting independent development, testing and maintenance of each component.
Over the years, MVC has taken the software development writing community by storm and many frameworks have been designed using its patterns and guidelines.
Once the MVC separation is implemented in an application, it provides a platform to modify the business logic, whenever required in the future, leaving the other application functionality intact.
Migrating to WebForm using MVC, apart from the separation of distinct layers, is no different from migrating to WebForm without MVC and provides global accessibility as in a normal web-based application.
WinForm, part of the Microsoft .NET framework, is an event driven application and provides access to native Microsoft Windows interface elements.
Using Win Form, the modernization of Visual FoxPro application(s) to Windows Form Client/ Server application(s) can be done providing the same look and feel, usage and flexibility of the legacy application
Microsoft Visual FoxPro dwells in data, since it is designed keeping data primarily in mind. Almost all of its controls are data centric, highly intricate input, output and processing can be done right away just by merely setting a few properties. To supplement this, Visual FoxPro also offers total compatibility to “xbase” style coding syntaxes for data manipulation.
Prior to version 3.0, Visual FoxPro would support only its native data flavor namely, DBF. In later releases, Visual FoxPro included the ability to interact with other databases especially RDBMS through ODBC, giving users a choice to stay with native DBF or move ahead and take advantage of RDBMS.
RDBMS has several advantages over DBF –
Although it’s not mandatory to move to RDBMS, sagacity suggests that it is always prudent and wise to scale up data so that you can:
Apart from these moving forward, data upsizing performed today would come handy in the future as it is the foremost step while migration of Visual FoxPro application to new technologies.
Data upsizing has an impact on the code too, Visual FoxPro being a data centric language with most of its code data oriented in one way or the other.
The impact on code would vary depending on the style and degree of usage of syntax based code as well as other data processing operations. Typically, change could be for a simple statement such as USE or a full- fledged data operation involving multiple files. For all these, code will have to be changed in individual places to supplement upsizing of data.
In-house custom built tools will be used to upsize data taking into consideration –
ZSL’s Visual FoxPro application maintenance service offers exciting value added services to its maintenance program wherein clients having native DBF backend could get DISCOUNTED (even FREE) data upsizing (for both data and relevant code) as a value added proposition to the contracted maintenance service.