CommerceContext loads the connection string from a configuration
file — this is a trap. It causes every new CommerceContext to read the configuration
file, even though the configuration file typically doesn’t change while
an application is running. A CommerceContext shouldn’t contain a hard-coded
connection string, but neither should it load a configuration value from the
Mary loaded the connection string from the configuration file from within the CommerceContext
class (shown in listing 2.2). From the perspective of its consumers, the
dependency on this configuration value is completely hidden. As we alluded to
when discussing listing 2.2, this implicitness contains a trap.
Although the ability to configure a compiled application is important, only the
finished application should rely on configuration files. It’s more flexible for reusable
libraries to be imperatively configurable by their callers, instead of reading
configuration files themselves. In the end, the ultimate caller is the application’s
entry point. At that point, all relevant configuration data can be read from a configuration
file directly at startup and fed to the underlying libraries as needed.
We want the configuration that CommerceContext requires to be explicit.