This project proposes several modifications to the SecureADODB library, as well as explores some alternative design options.

SecureADODB is an object-oriented VBA library developed as a part of the RubberDuck VBA project. To learn the library better and get some hands-on experience, I forked its code. I am currently working on integrating the library into my demo personal database manager application, ContactEditor. When necessary, I adjust/adapt the library's code in my fork. The present focus of this documentation is on the introduced changes. For convenience, when I need to disambiguate the reference, I will use suffixes to designate either the original version (SecureADODB-RD) or this fork (SecureADODB-PG).

Class diagram and connections to ADODB

The class diagram below shows the core SecureADODB classes (this fork, blue) and the mapping to the core ADODB classes (green).

SecureADODB Fork class diagram (interfaces not shown)

DbRecordset class has been added in this fork, while the DbManager class shown at the bottom is functionally similar to the UnitOfWork class from the base project.

DbManager class streamlines the interaction with the database by facilitating typical workflows. This class glues together individual base classes. It takes connection parameters or connection string and then instantiates other classes and injects dependencies as necessary.

DbConnection and DbRecordset classes receive and handle events raised by the corresponding ADODB classes (which was part of the motivation for creating the DbRecordset class). The core events (associated with connection, execution, and transaction) are accessible via the “Connection” class. Accessing asynchronous fetching events, however, requires the “Recordset” class.

Usage examples

Please see ExamplesDbManager.bas, ExamplesDbRecordsetUpdate.bas (examples using this fork of the SecureADODB library), and ExamplesPlainADODB.bas (mostly plain ADODB examples) in "VBAProject\SecureADODB\Examples" for usage examples. SecureADODB examples produce output via Debug.Print and via the QueryTable feature. Plain ADODB module produces very little output, and its results can be examined via the debugger or by modifying the code.

Core differences from RDVBA SecureADODB

1). A coupling loop between DbConnection and DbCommand has been removed (issue IDbConnection_CreateCommand interface).

SecureADODB dependency loop

2). AutoDbCommand and DefaultDbCommand have been replaced with DbCommand and DefaultDbCommandFactory replaced with DbCommandFactory. DbCommand always takes an existing DbConnection class as a dependency, and is only responsible for ExecuteNoQuery functionality (NoQuery flag commit), while queries returning a Recordset or a scalar are executed via the DbRecordset class.
3). DbConnection's constructor now checks the "Transaction DDL" attribute to see whether transactions are supported by the backend.
4). A new Guard class replaces the Errors module with some refactoring and additional functionality. A "Scripting.Dictionary" backed logger prototype has also been implemented.
5). Design patterns:

• Factory-Constructor pattern. Following the convention of the base project, the default concrete factory is the "Create" method defined on default class instances. Initialization, on the other hand, is not performed by a set of public setters but rather via a corresponding constructor (Factory-Constructor pattern issue). Please see Contact Editor tutorial for additional discussion about the returned value.
• Abstract Factory and CreateInstance convention. Аbstract factory's Create method generates factory instances. Factory instance's CreateInstance method, in turn, generates instances of the target class (CreateInstance convention issue).
• Duplicate Guard clauses. Factories hold only the non-default instance guard, which might be redundant when the factory produces non-default interface objects lacking the factory method. The factory passes all initial values to the new instance constructor responsible for validation guards/checks.

6). DbRecordset class handles queries returning disconnected or online Recordsets, as well as scalars. A fully initialized “ADODB.Command” sets most of the DbRecordset’s properties (via injected DbCommand). Several options (such as return type and cursor type/location) are supplied to the DbRecordset factory directly.
7). A new module, DbManagerITests, runs a set of tests against mock CSV and SQLite databases. This way, actual SecureADODB classes (as opposed to stubs) are tested. DbManagerITests tests also serve as use templates.