BFC is based on the Microsoft Foundation Class Library (MFC), which is an extensive framework for doing general-purpose application development under Windows. A framework is more than just reusable components, as would be found in a typical class library - it includes reusable designs, which form the basic skeleton for constructing entire applications.

With BFC, you have a starting point consisting of an overall structure, a set of base classes, and middleware designed for easy access to data, without regard to database vendor or location.

BFC provides the complete framework needed for building commercial quality, Windows database applications using Visual C++. BFC has about 100 classes and 2000 functions that have been designed to be reused. Almost all BFC classes are derived from MFC classes and add significant extensions to MFC. BFC includes:

• an integrated collection of utility, database, application, and administrative class libraries
• state-of-the-art screen controls easily connected to the database classes
• customizable Distributed Batch Processing Services for executing large-scale long running tasks in parallel over multiple machines
• integrated support for leading reporting and graphics packages, Crystal Reports and Pinnacle Graphics

How do you even start to construct a commercial quality, large-scale database application? Certainly, none of the Microsoft supplied samples even begin to confront the problems of building practical business systems. BFC is the first product to answer the question of how to build large scale, high security, database applications with Visual C++ and MFC.

The Base/1 Foundation Component Library provides Windows developers with a comprehensive set of tools for rapidly implementing large-scale, high security, client/server database applications. Applications built on BFC's core Database classes gain the benefit of portability between widely varying database types, currently including Microsoft SQL Server, Access, Oracle, IBM DB2, Sybase, SQL Anywhere, and MySQL.  Programming is simplified because BFC offers a streamlined interface that relieves the programmer from a tremendous amount of underlying complexity.

For Rich Client applications, Base One's database-centric architecture takes the concept of derivation to its logical conclusion. The concepts of inheritance are extended to include not just classes, but entire applications. Most often, Rich Client applications are derived from the Base/1 Foundation Application (B1_App.exe), which provides a working example of key class library (MFC & BFC) features plus useful sample code.

Application inheritance in BFC includes not only classes, but also applies to the "built-in" record types and database command files. Thus, both database and processing features are inherited.

The BFC Starter Application (ZZ_App.exe) is an example of a bare-bones application derived from the Foundation Application (B1_App.exe). The Starter Application uses the classes, resources and database command files of the Foundation Application as a base. The Starter Application illustrates the starting point for your own object-oriented application, which will easily accept upgrades of the MFC and BFC class libraries as new features are added.

Your application (let's call it YY_App.exe) will also be derived from the Foundation Application (B1_App.exe). You can, in turn, derive an application from your own application and override your base application's behavior to create an easy to maintain, custom tailored version.

You decide which Rich Client facilities to include and which to override and give a different appearance or behavior. This becomes the starting point for adding the business specific features needed to deliver the complete application.

When you create a new Rich Client application with the BFC Wizard, it automatically inherits nearly all of the features of the Foundation Application. And, if you trace back through the BFC class definitions, you'll find MFC classes underneath, as the base classes. However, the main menu, main resource file and the central lists of dialogs, form views, etc. are not inherited from the Foundation Application.

You can build anything with Visual C++. After all, Netscape Navigator, Lotus Notes, Corel Wordperfect Suite, as well as Microsoft's Internet Explorer and Microsoft Office were all built using Visual C++. Microsoft also reports that the NT database servers, from Oracle, Sybase, Informix and Microsoft were all built in Visual C++. Furthermore, database vendors like Oracle, Sybase and Microsoft provide their highest efficiency, most flexible direct interfaces through C++.

Not only has Microsoft written most of its application software products using Visual C++, Windows NT, 95, and 98 are themselves mostly written in Visual C++. In fact, Microsoft has always maintained that Visual C++ is the general purpose, efficiency champion for client/server programming, and that MFC is particularly well suited to building large, complex custom applications. According to Microsoft, 90% of the 1997 Comdex award winners (for best software) were built with Visual C++.

Although C++ has a reputation for complexity, it is also widely regarded as the most powerful language available. Readers of Datamation, a magazine aimed mainly at corporate data processing professionals, chose Microsoft Visual C++ as "best application development tool" and "1998 Product of the Year" (beating out Sybase's Powerbuilder and Sun's Java). Summarizing readers comments about Visual C++, Datamation said:

"Flash is out, performance and reliability are in this year."

IDC (International Data Corporation) estimates that over the next five years the number of C++ programmers will continue to increase at about 10% a year (ComputerWorld, 4/99). The trade magazine, C/C++ Users Journal had this to say about the use of C++ as a programming language:

"C++ is big, complicated, heavy, hard-to-use - not yet even standardized. So why bother? Because it's king of the hill for creating reusable components and libraries, for server applications, for very large systems in general. It's where programmers have to go to maximize power and performance."

Microsoft published this comment about their Product of the Year award on their website:

"When it comes to choosing a tool, IT managers and developers are ignoring the hype and going to a tool that allows developers full control to build the most stable and fastest applications."

This is where BFC fills a major void in Visual C++. By adding literally hundreds of indispensable functions, BFC closes the gap between MFC and real world database applications. In addition, BFC shows what no MFC sample reveals - how to stitch together all the parts. BFC comes with administrative/security, batch processing, graphics and reporting libraries, forming a large body of tightly integrated sample code. Instead of getting bogged down reinventing the wheel, you can use BFC to focus on the technical and business problems that really matter to you.

BFC, in combination with Base One's Internet Server, demonstrate that Visual C++ and MFC can be ideally suited not only to client/server use but also to the most demanding Internet usage, such as highly graphical e-commerce applications and searching large databases. Bottom line - with BFC you can build great C++/MFC/Windows applications with the assurance that they’ll be efficient and reliable whether the data is local or happens to reside across the Internet.

BFC is a large, integrated class library, broken down into subsystems which can be understood separately. A standard BFC application uses four basic low level libraries as underpinnings: the Utility, Database, Screen and Application libraries (derived in that order).

The lowest level subsystem is the Utility Library (B1ULib), which has a set of useful utility classes, which aid programmers in handling dates, times, strings, 16 to 32 bit conversion, internationalization, file compression, error handling, etc.

The Utility library provides services to all the other subsystems but knows nothing of their existence. In other words, no header files from any other BFC library are included in the utility library.

Next after the Utility library comes the Database Library (B1DLib & B1DDLL). It provides database management services to all the higher level subsystems, without knowing of their existence and includes the ability to access Microsoft, Oracle, IBM, Sybase, and MySQL databases located both locally and across the Internet.

The Screen Library (B1SLib) provides a complete set of state-of-the-art screen controls, such as table (grid) controls, tab controls, hierarchical list boxes, enhanced status bar, 3-D and mask edit controls, etc., which are designed to be easily connected to the database classes. Most controls are built using MFC and the Win32 common controls.

The Screen library sits on top of the Database Library and depends on it because, for example, of the built-in Screen Dictionary records and mask edit controls that know about Data Dictionary information. The Screen library includes the Database and Utility header files, but has no knowledge of any other BFC subsystem but the BFC RESOURCE DLL (B1RDLL).

The Application Library (B1_App) pulls together all the components into a unified application. It is a small library, which sits on top of the Screen library and also makes direct calls to the Database and Utility libraries, and is responsible for the Base/1 Foundation Application (B1_APP.EXE). The Application library is the starting point for a typical BFC application and a detailed discussion of its components is contained in this manual.

There is a MANAGER CLASS class for each of the four basic libraries:

• Utility Manager Class, clsUtilMgr (in B1UCUM.h & cpp),
• Database Manager Class, clsDbMgr (in B1DCDM.h & cpp),
• Screen Manager Class, clsScrMgr (in B1SCSM.h & cpp), and the
• Application Manager Class, clsAppMgr (in B1_CAM.h & cpp)

plus Your Application Manager Class, clsYYYAppMgr (in YY_CAM.h & cpp).

Similarly, there are HEADER FILES for each of the four basic libraries, plus those created for your application (e.g. YY*.h), which you can choose to use or not.

BFC includes major components besides the basic, underlying Utility, Database, Screen and Application subsystems. You can choose to include these components directly (the default), or derive from them and modify them, or drop any that aren't appropriate for your application. It is the Application library facilities that make this flexibility possible.

The Administrative Library (B1Adm) includes a security subsystem, which is tied into the back-end DBMS, which supports user logon, password checking/changing, administrative controls for determining who should be allowed to view sensitive data or perform restricted operations. The user administration facilities make it easy to custom tailor application specific behavior, such as "filtering" data depending on who is looking at it.

The Administrative library includes a system administration facility for controlling database access, which allows administrators to force users to log off, restrict logon to certain types of users, and broadcast warning and information messages.

The Administrative library also includes the Data Dictionary facility, which is used to view, administer and report on database metadata, such as the description of database record layouts (tables), indexes, validation criteria, etc. Programmers can use the automated database creation capability during development to build tables, indexes, referential constraints, and storage creation parameters. When the application goes into production, the dictionary facility gives the DBA (Database Administrator) useful tools for managing the database structure.

The customizable Distributed Batch Processing Services (B1Bat) are designed for executing large scale, long-running tasks, creating batch functions and scheduling rules, specifying the hardware characteristics of PC's doing batch work, and logging task execution milestones.

The Help Subsystem (B1Hlp) is used for building, maintaining and displaying customized programmer documentation and includes facilities for automatically extracting documentation from source code. Users can print an individual topic, a topic and its subtopics, or an entire manual. BFC's Online Help and Programmer's Reference Manual are examples of what can be built with this subsystem.

The Graphics Library (B1Gph) is for producing graphs with Pinnacle Graphics Server.

The Crystal Report Writer Library (B1_CrW) assists you in writing custom Crystal Reports DLLs. The Miscellaneous Library (B1_Misc) includes a Report Base Class, clsRptBase (in B1_CRptB.H & CPP) that you can use for writing reports with Crystal. (The Data Dictionary Reports and the Batch Reports are good samples for creating your own reports.)

Large and complex applications have a special need for convenient and efficient ways to share information between components. In particular, screen objects (dialogs, form views, combo boxes, etc.) and application logic modules need to be able to launch each other and supply positioning information with as little knowledge of each other's insides as possible.

As an application grows, it becomes more and more critical to keep the application's logical complexity and average build times from getting out of hand. The number and average code size of each component tends to grow substantially as development effort is poured in. This should be planned for from the start.

The ideal is for each component to know as little as possible about the others, including not even knowing that the other component exists (whenever that's possible). In C++, this can be translated into preventing application specific header files from having to be included all over the source code body. In other words, even the public functions of an application specific component should be known to as few other components as possible.

Base/1 Foundation App illustrates a programming style in which application specific class implementation source files (*.CPP) can avoid sharing each other's header files (*.H). For example, a form view can launch a dialog without the form view's CPP having to include the dialog's header file. A menu item can be launched without following the standard MFC practice of adding a handler and a header file into your applications' main frame window class. Forms can interact with each other and pass around positioning information without knowing about each other or including each other's header files.

Most Base/1 Foundation App menu items do not have or need a main frame window message handler. Forms move their positions in the database as changes are made in other forms without either knowing about the other. Dialog boxes are launched from different locations in the source code without the dialog's header files being anywhere in the vicinity.

BFC implements global sharing of application data through two classes, the Application Manager Class and the Global Variable Class, plus a file for arrays of Global Definitions. If you use this architecture, your header files will not to need to sprinkled all over your application, your application objects will need to know much less about each other, and the modular independence of your application will be increased.

BFC provides the required infrastructure to rapidly develop your own robust Visual C++ COM components, both in-proc servers (DLLs) and out-of-proc servers (EXEs). VC++ BFC applications can incorporate ActiveX controls and support COM in the same manner as any MFC (Microsoft Foundation Classes) application. The BFC Screen library does the necessary COM and ActiveX initializations, and hence a BFC application can start using ActiveX controls straight away.

For example, you can drop ActiveX controls into form views and dialogs derived from BFC's Form View Base class (clsFrmVwBase) and Dialog Base class (clsDlgBase). The Help system in the Base/1 Foundation Application illustrates the use of the Microsoft Web Browser ActiveX control to display the help text. BFC's support for Crystal Web Report Server provides an additional sample of code to support a COM interface.

The MFC Visual C++ implementation of BFCCOM illustrates addressing some important issues related to developing COM components in general. The source code illustrates handling registry setting, threading model, multi-user issues related to concurrency and synchronization, dual interface, advanced error handling, etc.

The out-of-proc COM objects implemented in a BFC application can be used by any COM or .NET client, such as ASP or ASP.NET pages, another C++ application, VB or C# application, Cold Fusion application, etc.

Copyright © 2012, Base One International Corporation