Wiki Home

Vfp NTier Apps Through Web Services

Namespace: WIN_COM_API
VFP n-Tier Apps Through Web Services

A model for designing VFP distributed applications in a way that would allow future integration with the Visual Studio Net framework is proposed here.

See also in Vfp Apps In The DotNet Era: motivation, pros and cons, and additional discussion of this model.

Layers on the client side (Win32 app)

  • User Interface Layer VFP forms, just for managing the interface (don't place behavior code on them or you'll be blamed by the experts -- see Vfp Rookie Mistakes). Forms communicate only with the Behavior Layer

  • BehaviorLayer VFP classes, either State Ful -my choice on the client side- or State Less. This components should have "thin" logic, or rather act as "proxy" objects, which in turn call Web Services -on the intranet or internet- for the real work. Enter Soa P.

  • Layers on the server side (Web services)

  • Web Services Interface Layer (a made-up term) With today's tools, this could consist either of ASP wrappers for calling VFP COM components (wrappers built with Microsoft SoapToolkit wizard for the server side) or the Web Connection framework with the new SOAP extensions.
    The first option should require some minor changes to the generated pages if you are running on a IIS4 server.
    IMO the latter option is better (more robust and powerful). Actually, when running Web Connection in development mode (VFP app), you get much of what the .Net Asmx pages will deliver: some runtime managed code (VFP in your case) catches the web service request, and instantiates a native class labeled as Web Service (your VFP class, based on Rick's wwWebService) then invokes the appropriate method. Integrated debugging? It's already there. Related functions for manipulating the XML I/O? You've got them. A "COM component" building switch is also available so that you can package the final code into multi-threaded, more scalable components.

  • BehaviorLayer VFP classes (full OOP ammunition here), "outer" components exposed either as COM or VFP native classes (this option is only available with the Web Connection previous choice)

  • DataLayer VFP "data access" classes, which communicate with SQL Server or other DBMS - I wouldn't use DBFs here - through ADO (ADO+ ?), or SQL Pass Through. The "XML output" feature of SQLServer2000 would be a nice choice.

  • As you've probably noticed, the key of this design is to split (not to replace) the good old 3-tier model with a "SOAP protocol decoupling" of the client and server components, thus allowing for interacting / extending / replacing some of its components with .Net components or a WebForms front-end.

    See also in Vfp Apps In The DotNet Era: motivation, pros and cons, and additional discussion of this model.
    What's the compelling reason for using VFP on the client machines for the user interfaces and the desktop? If you're looking to move into the .NET world, using VFP for the UI is the last thing I would consider. Why would you want to create a distributed architecture and still be saddled with having to put the VFP runtime on every client machine and limit your apps to fat client? Win Forms seem like a much better choice here. VFP in the Web Services Interface Layer, Behavior Layer (the second one you mention, on the server side) and in the Data Access Layer all seem like better choices than in the UI. This limits the need for installing and managing VFP and VFP Components to the servers which is much more manageable than all the clients. This approach looks like someone trying to find a way to use VFP nearly everywhere in the .NET world, but the reasoning seems solely to be based on that, vs. a strong reason to use VFP in all of these layers. The only benefit I can see to this approach is it would possibly eliminate the need for DCOM, but that can be done with a web interface (or VB/C# using the CLR) without the pain of putting VFP on every desktop. It still looks like the only good fit for VFP in all of this stuff is on the servers. -- Mike Feltman
    How about because Win Forms is not ready yet? As of right now, (and the next 2 years AFAIC), .NET is not ready. Even when it is, the CLR won't be installed on the most common OSs yet, so you have an even worse distribution problem than the VFP runtime. -- Erik Moore

    What about using a .Net linker to create a .EXE that doesn't need the CLR. -- Bob Archer
    Contributors: Jose Marcenaro Mike Feltman Erik Moore
    Category DotNet
    ( Topic last updated: 2004.03.11 06:02:20 PM )