Building your client-side: Page 2

(Page 2 of 2)

Implementation Language

The choice of client implementation language or tool is likely to strongly influence hardware selection. It is also a relatively complex issue that must be weighed by the developer organization. Factors include:

  • Developer experience
  • Tool cost, both for developer license and training
  • Hardware
  • Software selected for other portions of the system
  • Whether the client will be thin or thick
  • Project vision also comes into play to a certain extent as well. Visual Basic might be chosen for a relatively small, minimal functionality system with limited growth potential. If you know up front that the client is a starting point that eventually will expand to every desktop in the organization, then a more robust and faster compiled language such as Delphi or Visual C++ might fill the bill in the long run better.

    Developer experience should also enter into the language selection equation. Never choose a language that no developers have any experience with. Even one experienced developer will significantly shorten the learning curve for the whole staff. Plan on training when a new programming language or tool is used.

    One last point on choosing a client implementation language; choosing a language or tool ties you to that vendor for the life of the project. Choosing Visual Basic means dealing, either directly or indirectly, with Microsoft. Choosing PowerBuilder ties you to Powersoft, etc.


    Dynamic Link Libraries (DLLs) issues only apply when the client is Windows (either Windows 3.1, Windows For Workgroups, Windows 95, or Windows NT). The proliferation of system DLLs over the past few years has made DLL selection an important issue in the client selection equation.

    DLLs typically contain generic system libraries, such as the Visual Basic runtime module. Application programs generally distribute the DLLs they need to run. Frequently distributed DLLs include:

    • Visual Basic runtime
    • ODBC drivers
    • Winsock
    • Graphics conversion library
    • Application modules

    The problem is one of configuration management and user support. Assume a user’s PC functions properly. Suppose a new package is loaded with a newer ODBC driver. The updated DLL overwrites the existing ODBC driver used by another program. Now, some of the old applications no longer work because of DLL differences. DLLs often are not completely backward compatible. Applications may work in conjunction with a DLL bug and often do not work when the bug is corrected in the driver. There also may be subtle differences between driver DLLs from different vendors which may also affect an application.

    There is not a great deal that can be done about the multiple DLL version problem beyond being aware the potential for problems exists. The knowledge will provide some hope of identifying such a problem when it happens. Working with vendors is often necessary to solve DLL incompatibility problems. Keeping Windows applications up to date tends to minimize this type of problem.

    Thin or Fat

    The thin or fat client issue keeps surfacing. The decision must be made early on because it influences tool selection. The thinner the client, the less critical speed and memory considerations become. Rapid application development (RAD) is often traded for performance. Interpreted Visual Basic falls into this category of tool. (Visual Basic 5.0, with code compilation, should be available by the time this is published.)

    The fatter the client, the more critical speed and memory usage become. The tradeoffs of RAD and performance swing in favor of performance. Client-server tools are evolving to provide both RAD and performance.

    Factors that affect the thin versus fat client quesion include:

    • The client hardware; low-end client hardware points to thin client software
    • The network; a heavily loaded network favors the fat client

    Whatever the client makeup, it is important to at least plan the approach up front so the client decisions can be factored into other development decisions.


    Thinking about application deployment may seem strange during initial planning, but is very important especially when a large number of users are involved:

    • How much installation is required?
    • How are updates handled?
    • Is there a standard client hardware configuration and what is it?
    • What is the standard client software configuration?
    • Are there known DLL incompatibilities?
    • Can client installation be staggered?
    The list of development related questions goes on and on.

    Automated client installation is practical. Many installation utilities are available today that can be used for any size application. Another possibility to consider is network installation. Fat clients may also require control or table files that require frequent update. Again, knowing the client makeup plan up front can prevent much pain later during application development.


    The point is not necessarily to answer every development question up front. Some of the answers will be obvious; some are tough. Asking the question makes people think about the issues. Some issues about other project areas may have different solutions when deployment issues are considered than when the issues are totally ignored.

    About the author:

    Norman E. Smith has 25 years programming experience and is a senior systems analyst and programmer for Science Applications International Corp., in Oak Ridge, Tennessee. He is the author of the highly successful Practical Guide To SGML Filters and the Practical Guide to Intranet Client-Server Applications Using The Web (Wordware). Smith has been developing WWW applications since 1993 for SAI and has developed several Intranet applications using Web-based tools.

Page 2 of 2

Previous Page
1 2

0 Comments (click to add your comment)
Comment and Contribute


(Maximum characters: 1200). You have characters left.