 |
The "VB App" in this scenario refers to a "FAT CLIENT". It contains all classes, forms, and modules necessary to communicate with the remote database.
 |
The "VB App" client in this scenario is a stand-alone EXE containing only user interface components (forms). It therefore loads faster than the preceding example. The "ActiveX Server" contains all classes and modules necessary to communicate with the remote database. It encapsulates the details of any business rules and data access. It is also reusable with other user interfaces on the user workstation, such as another VB application or a Web page. The "ActiveX Server" can be compiled as a DLL or as an EXE. As a DLL, the ActiveX Server launches in the same process as the client EXE and therefore runs faster than a stand-alone EXE. As an EXE, the ActiveX Server launches as a separate process, so the ActiveX Automation uses "cross-process" access.
 |
As with the prior scenario, the "VB App" client in this scenario is a stand-alone EXE containing only user-interface components. Likewise, the "ActiveX Server" contains all classes and modules necessary to communicate with the remote database and encapsulates the details of the business rules and data access. Launching on its own server computer, the "ActiveX Server" is now reusable across multiple users. In this configuration, the "ActiveX Server" must be compiled as an EXE, so DCOM replaces the ActiveX Automation and uses "out-of-process" access. However, the client must make multiple calls across the network to the "ActiveX Server" to access class properties and the "ActiveX Server" must call across the network to access the database.
 |
This configuration is similar to the prior configuration, but it eliminates network traffic between the "ActiveX Server" and the database. However, the client must still make multiple calls across the network to the "ActiveX Server" to access class properties.
 |
In this situation, an "ActiveX Server" is designed for both the user workstation and the server computer. The "ActiveX Server" on the user workstation allows for packaging multiple class properties into an array for transmission across the network while relieving the VB client of the necessity to know how to package these properties. The "VB App" can then access simple properties and methods in this component. The "ActiveX Server" on the server computer receives the array of properties and provides the code to write the values to the database. It also knows how to receive query requests from the "ActiveX Server" on the user workstation, retrieve the data from the database, package it back into an array, and send it to the user workstation.
This seems like the perfect approach. However, there is one issue that was not discussed in any of these scenarios. When an object is first requested from the "ActiveX Server", the ActiveX Server EXE on the server computer must be launched. This, as you know, has a significant performance delay. This server terminates once the client releases its object references, unless the client keeps code to maintain a persistent object reference. That is where the next scenario comes in...
 |
The "Pool Manager" on the server keeps references to the "ActiveX Server" and ensures its persistence. You can create your own Pool Manager, or use Microsoft Transaction Server (MTS).
 |
Finally, one cannot work on an application anymore these days without giving some consideration to the Internet or Intranet. In this final scenario, the user workstation has an internet browser (IE 3.0 for best results!). Active Server Pages on the server side can collect data and dynamically generate HTML files. (These HTML files are simple HTML files - so can appear in any browser.)
To display Visual Basic forms in a browser, you can create an ActiveX document. This runs on the user workstation and does require an ActiveX document-compatible browser, such as IE.
Thanks to Mark Hammond for help on this page. He did the first version of this page based on his notes from the InStep Technologies seminar on Object-Oriented Design and Development with VB5.)