We have been helping customers convert Visual FoxPro systems to different platforms (mainly .NET and SQL Server, but there are others) for the better part of two decades. During that time, we have provided numerous articles, presentations, and training classes. Articles range from high-level road maps to in-depth, detailed technical articles. As time has passed, VFP conversion techniques and options have evolved. With that, we feel it is time to take a look at the big picture once again.
Modern Systems and Architecture
Modern business applications differ quite a bit from systems built several years ago. Modern applications usually have to take technologies and scenarios such as HTML-based web applications and mobile devices into account, although Windows Desktop applications are also of significant importance and will remain so for some time to come. Even applications that are currently targeted at only a single environment will have to remain open to an ever-changing scenario, as systems have to flexibly adjust to new needs. For instance, it isn’t acceptable anymore to require a large, time-consuming, and costly re-write when an application that was previously implemented as a Windows Desktop Application needs to be augmented with a mobile or web interface.
The modern system landscape is an ever-changing beast. Currently, business application developers have to create client applications based on Windows, WinRT, Windows Phone, Apple iPhone & iPad (iOS), Android, HTML5, and a few other technologies. The middle tier (“business logic”) is typically implemented as a generic layer that can be created in a variety of technologies and languages, and accessed using a variety of standards. Database back-ends can be conventional relational databases (often Microsoft SQL Server among other database technologies) or an alternative paradigm, often referred to as “NoSQL,” “document databases,” “blob storage,” or “Big Data.” Deployment of applications ranges from simple single-workstation systems (such as an entire application installed on a single laptop) to cloud-based web farms distributed around the world.
While things have settled down a bit, and the choices aren’t quite as plentiful and unknown as they once were (example: supporting Blackberry isn’t a big consideration anymore), things are still changing rapidly. Developers not only need to come up with a strategy that works for all of these scenarios (or one that could adjust to these scenarios if the need arose), but the chosen architecture needs to be open to unknowns and adjust flexibly as well. A failure to do so will inadvertently lead into further expensive and time consuming re-writes, which are unacceptable.
Luckily, while there are many unknowns, it is well understood which architecture works in such scenarios. A well thought-out system and application architecture protects from future re-writes and makes developing these applications much less expensive. Such an architecture also means that problems (which will inadvertently occur as developers venture into new territories or try to plan for the unknown) will be localized and can be fixed without much overall interruption and hardship. Hence, it is of utmost importance that the chosen architecture is correct.
In the big picture, architecture of modern systems is still built on the same fundamental principles that have been used for over 20 years. Systems are three-tiered (or “multi-tiered”) with distinct layers for the user interface, the middle tier, and the database. The main difference is in the details.
Middle tiers (the “business logic”) have evolved to encapsulate the application’s entire logic and make that logic available in a variety of ways. The middle-tier can be accessed as simple objects, or (more likely) is accessed in some standardized fashion that is available to just about any platform and technology. Such a setup is often referred to as “Services” or “Service Oriented Architecture” (SOA). Since this layer encapsulates all the logic and functionality that define an application, we have come to refer to this part as “the application.” For Visual FoxPro systems that are to be migrated to a different technology, this setup turns out to be fortuitous, since it enables a conversion that is more gradual than was previously possible (more about that below).
Of course the middle-tier (“the application”) is not in itself very useful to users, since there is no direct way to interact with it. From a VFP point of view, it would be like handing users some VCXes (or other VFP classes) and expect them to be able to do anything useful. Instead, the system needs to provide a user interface. Or, in many cases, more than one kind of user interface (either right away, or over time). Today, we often refer to these “user interfaces” as “clients.” In modern systems, different clients can interact with the same middle-tier. This is what enables us to quickly switch from one client to another, extend individual clients, or add new ones. A Windows Desktop client may be used in the office, but mobile clients may be used while on the road. Customers may interact with the same system using HTML-based clients, and so on. All of these clients access the same fundamental application and are governed by the same rules and behavior.
Finally, the database handles storage needs. This part is perhaps the least changed of them all. Many applications use relational database technologies such as SQL Server (perhaps the most common choice for former VFP systems) or Oracle. A transition to these databases is generally painless (although one should always beware of the details!). Some systems can also benefit from NoSQL databases that are better suited to store less structured data. While one should not underestimate the task of converting data, this is also one of the best established and best understood areas involved.
Services and the Middle-Tier
The middle-tier and service layer represents the heart of a modern system. It provides a well-defined set of components that encapsulates the application’s functionality. In more concrete terms, the middle-tier is usually a set of objects with methods that accept certain input parameters and returns corresponding results. For instance, a customer management application may have a service object that supports searching and editing customers (among quite a few other things). To search for customers, a well-defined set of input parameters is sent to the service method, which then retrieves the appropriate result and returns it in a well-defined format.
These “well-defined” aspects of the middle-tier are usually referred to as an “interface” or “contract.” In systems such as .NET, these are often created as actual C# or VB interfaces or classes. Client systems can use these “contracts” either as standard objects, or (more common in modern systems) through some kind of service standard such as REST, SOAP, Binary TCP/IP, or one of many other protocols. A well-architected system should be able to adjust to these standards through simple configuration and allow clients to use the most efficient approach applicable. With modern development technologies, creating such a setup is just as efficient and productive as it is to create less formal objects, and in fact it is often more productive.
From a Visual FoxPro point-of-view, the need for such a service layer is a very fortunate development, as it often enables gradual conversion. In the customer example, once the service interface (the exact set of methods, parameters, and return values) is defined, developers have a wide range of options. For instance, it is possible to create an implementation of that service standard that communicates either with Visual FoxPro COM components, or even directly accesses DBF files or other VFP data directly. This may not be the ultimate goal of the conversion, but it may suffice as a first step. As time goes on, services can then be migrated one-by-one until a complete conversion and the ultimate goal are achieved.
This kind of a scenario has the obvious advantage that one can take some initial shortcuts to make conversion more feasible, while not compromising the overall quality and architecture in any way. It also has further advantages; for instance, it is possible to convert only certain modules of an application. Perhaps an older VFP system has some features that need to be made available through mobile clients. In that case, a small part of the system can be implemented in this fashion while still accessing the older components. This kind of setup also protects the overall system from implementation errors. It is unlikely that developers who just moved from VFP into this new setup will implement every scenario perfectly in the best possible approach for the new technology. With this setup however, it is possible to fix issues on a case-by-case basis without putting the overall system in jeopardy or causing the need for large amounts of re-writes and changes. A further benefit is that once more services are moved to a new system or database, one can compare the two versions of the service for quality control.
This new service-oriented approach is extremely popular in VFP conversion projects and has been used in numerous projects with great success, no matter whether the goal is to gradually move components and put small sub-systems into production, or to migrate large systems in a structured and predictable fashion. Using this new approach has drastically changed the face of VFP conversion projects in very favorable ways. This type of conversion approach simply wasn’t available, even a few years ago.
Clients (Windows, Web, Mobile)
The Client apps (the “user interface”) is a very important part of every conversion project. There are now several different options to consider. They fall under the big categories of “Windows,” “Web,” and “Mobile” applications.
Windows applications are a widely used option. Windows applications are generally built as .NET applications with WPF (Windows Presentation Foundation), which has become the de-facto standard for Windows Desktop Application Development. While mobile devices and HTML applications may be the “new kids on the block” and thus receive more attention than WPF these days, businesses tend to put a lot of emphasis on WPF (and it is a very important technology indeed!). WPF is an extremely powerful technology that enables developers to create high quality business applications in an exceptionally productive fashion. (Note: WPF is also useful for consumer applications, but its core strengths are most obvious and useful for business applications.) When employed correctly, WPF is the most economically sensible approach for business application development. The importance of this aspect cannot be overstated and will not be lost on managers, developers, and decision-makers alike.
With that said, HTML-based web applications are also very interesting options. There are now two main approaches to web application development. One option is the “conventional Web approach,” with web sites composed out of many individual pages the user navigates page-by-page. A majority of eCommerce web sites (such as Amazon.com) fit this description. This approach is very applicable for all typical Web sites.
The other web development approach is referred to as “Web Applications.” These are based on HTML5. Their most defining characteristic is that entire apps are encapsulated in a single page (which is why these web apps are known as “Single Page Apps” or “SPAs”). A SPA loads additional UIs into its core page on the fly as needed. JavaScript is used extensively on the client, paired with other technologies such as CSS. The characteristic of such a HTML5 app is more comparable to that of a Windows application than a Web site, both in terms of development as well as in behavior and feature set perceived by the user. In such a scenario, HTML5 has been transformed from a thin-client technology to the new rich-client standard. It may not be obvious for many former VFP developers who are familiar use with conventional Windows development, but these kinds of apps are to be taken seriously as alternatives to Windows apps. It may still be a bit harder and time-consuming to build these apps (and some of the underlying component technology is more in flux than the Windows counterparts), but these apps also have the advantage that they can run cross-platform on almost any modern system or device.
Finally, there are the mobile applications. For phones, Apple and Google split the majority of the mobile market with their iOS (iPhone) and Android operating systems. (Microsoft is a distant third rank at the time of writing.) While Android has a larger number of installed devices (since numerous third party hardware vendors use Google’s free operating system), Apple’s users tend to consume more and use their devices more. This results in both platforms being equally viable choices. For tablet (slate) devices, Apple has the upper hand with the iPad product line, although Google’s Android offering also has some viability for slates. (Again, Microsoft is a distant third with the WinRT version of Windows 8x and its Surface devices as well as third party hardware offerings.)
Development for these kinds of mobile devices is the largest growth segment the industry currently has to offer. While it may not appear intuitive to developers who have grown up in a Windows world, mobile devices are rapidly breaking into many usage scenarios that would previously not have been considered feasible for devices. Especially for the younger generation of users, mobile devices often replace conventional desktop or laptop computers. The significance of this development and the size of this opportunity cannot be overstated. Think of it like this: just about any application ever developed for PCs now requires a counter-part for mobile devices. Plus, there are many new opportunities.
Development on mobile devices can be done in various ways. HTML5 enables some cross-platform development that allows targeting multiple platforms at once. Another option is to specifically target individual platforms. Apple’s iOS operating system can be targeted using Apple’s Objective-C language and Cocoa framework. Android, on the other hand, is based on Java. Those options have the advantage that they target individual devices specifically in “native” fashion, which means that apps built that way are most efficient in taking advantage of the individual systems and create the best experiences. The downside is that these systems require separate development efforts for multiple platforms and thus the effort is multiplied as well. This particular issue can be addressed with Xamarin (formerly known as “Mono Touch”). Xamarin is a technology and development environment that enables developers to use familiar languages (such as C#) to create a single code-base that can be compiled as native mobile apps (in many cases, only the user interface changes between platforms). This combines the advantages of native development with the advantage of cross-platform code reuse (especially for logic components). Not surprisingly, Xamarin has become very popular and is an option that developers should seriously consider.
Looking at all these options, Client development can seem daunting and overwhelming. Things are not as bad as they seem at first, though. Most UI environments now share key characteristics. For instance, UI development is now split into distinct tiers, with a layer that encapsulates the logic, another layer that defines the elements (controls) used by the UI, another layer that defines the UI “style” (the actual “look” of the UI, such as colors, fonts, layout, and more), and “binding” to tie all these parts together. This simplifies UI development and makes individual UI elements highly reusable and testable. When done correctly, this approach can drastically speed up developer productivity, regardless of whether the UI is built using XAML, HTML, or other technologies.
Technologies and Languages
Many of the concepts laid out in this article so far are applicable to VFP Conversion projects regardless of implementation technology, language, or platform. There are several good choices. For instance, VFP projects have been converted successfully to Java-based systems. With that said, it is no surprise that Microsoft’s .NET platform is very popular and used with great success, and perhaps the most obvious and popular choice for former VFP developers.
When using .NET, most developer’s language of choice is C#. It isn’t unthinkably difficult for VFP developers to learn C#. The same is true for Visual Basic; however, C# has turned out to be more popular. Also, C# is closer in nature to languages such as JavaScript, Java, and Objective-C, which are also likely additions to a developer’s toolbox. (This is especially true for JavaScript). Thus, staying in the “C-like” language family makes sense for a lot of projects. (Nevertheless, Visual Basic also remains a viable option for developers who find that type of programming language to be the more comfortable and familiar choice.)
When it comes to languages, paradigm is often more important than language syntax. The paradigm followed by Visual FoxPro is that of an object-oriented and “somewhat dynamic” language (VFP supports several dynamic features, but lacks others). C# (as is similar with many other .NET languages) is an object-oriented and static language (meaning it is somewhat stricter than Visual FoxPro). This is generally considered a good thing and improves quality and performance. However, C# can also explicitly invoke dynamic features. Thus, developers should understand dynamic as well as static paradigms. (This tends to be a relatively simple hurdle for Visual FoxPro developers.)
Other languages (especially JavaScript) are entirely based on dynamic paradigms and aren’t truly object-oriented, but just “object-based” (there are no classes). This may seem odd to VFP developers, but time should be taken to understand when and why this is beneficial or detrimental. (Note: JavaScript is a language all developers should have at least a rudimentary understanding of, at this point.) Furthermore, JavaScript incorporates some functional language concepts, or at the very least, treats functions as “first class concepts.” The same is true for C# (mainly through “lambda expressions”). Therefore, developers should also acquire an understanding of basic functional concepts. Since these paradigms are used in a variety of languages, it will be relatively easy to translate this understanding into different languages. Therefore, understanding the paradigms is often more important than understanding the syntax of individual languages.
Conclusions
Visual FoxPro 9 was the last release of Visual FoxPro (with Microsoft’s support window being limited to 2015). A lot has happened since then. Even more has happened since the last major feature and paradigm upgrades have been made in VFP, which goes back to even earlier version. Not surprisingly, the software industry has undergone major shifts since then. While Visual FoxPro is a development environment mainly geared at Windows Desktop application development (with Web features being added mainly through third party tools, including our own). Major new trends since then include several generation of Web/HTML site and application development, mobile development, distributed Windows Desktop development, Cloud development, and more.
This means that Visual FoxPro developers now face quite a number of different new technologies, paradigms, and platforms that need to be mastered. While this may appear a daunting task indeed, things aren’t quite as overwhelming as they may appear at first. Most projects can focus on specific sub-sections (such as building only a Windows app, or building only a Web app, at least initially) and solid overall architecture, which narrows the load and flattens the learning curve considerably. Furthermore, the industry, after having been in extreme flux for several years, has now stabilized to some extent, with certain technologies and platforms emerging as clear winners, and certain paradigms and languages settling on patterns that are applicable on most, if not all environments. Therefore, new techniques learned in one area are often applicable in others, which also simplified matters significantly.
The most important overall aspect in all modern projects (and perhaps even more so in VFP Conversion projects) is getting the overall approach and architecture right. This puts projects on the right trajectory and allows for flexible implementation and for greater tolerance for errors and the ability to fix those without putting the entire project at risk. It also allows for gradual conversion, which increases project feasibility.
There are a lot of new technologies and paradigms. Thankfully, some of them mean that VFP Conversion projects are now more approachable than they have ever been.
How VFPConversion.com Can Help
VFPConversion.com provides a wealth of knowledge revolving around converting VFP applications to other environments. Much of that information is available for free. For instance, there is a large list of free articles geared specifically toward VFP developers who want to understand how their VFP knowledge translates forward.
VFPConversion.com also offers training video and other training options (such as live classes that can be attended on-site or online). Furthermore, VFPConversion.com offers individual as well as customized training and mentoring.
For those who need help with conversion projects, VFPConversion.com offers consulting and mentoring services at any level, ranging from one-hour mentoring and consulting sessions, to project and architecture guidance, to staff augmentation and even projects done largely or entirely by VFPConversion.com staff. We can help you with the largest and most complicated projects, but we are just as happy to help with the smallest of tasks.
