Level 300
DevForce Professional

May 23, 2006

Many IT shops prescribe separate Development, QA, Test, Stage, and Production environments. Each version of the application works its way through a testing gauntlet from the developer environment to the ultimate production release.

Suppose our application refers to a database data source called “default”. Its data source key is “default”. The application will use this key at runtime to find a data source configuration in the application configuration file (IdeaBlade.ibconfig).

The data source configuration is very simple for the development environment. The development deployment puts all tiers on the PC. The “default” development configuration’s connection string points to a database on the PC.

The QA environment, on the other hand, has a 3 tier deployment with separate machines for client, business object server, and database. This requires many changes to the “default” configuration including a different connection string that points to the QA database. We really need a separate “default” configuration for QA.

In fact, we need five “default” configurations in the application configuration file.

The symbolic data source, “default”, doesn’t change as we cross environments. The business objects associated with the “default” data source should be indifferent to configuration differences. The executing environment, on the other hand, has to know which of the “default” configuration to use.

DevForce provides data source key extensions to help distinguish the five “default” data source configurations. By convention, the data source configuration name is the data source key name followed optionally by a data source key extension (with an underscore “_” separating the two).

In our example, the configurations could be named “Default_Development”, “Default_QA”, etc. When the application launches, it determines its runtime environment and then tells the PersistenceManager to connect to its data source(s) using the extension to find the appropriate data source configuration information. If we execute in development, we initialize the PM with “Development” and it adds the “_Development” suffix to “default”.

If the PersistenceManager  (and, later, the PersistenceServer) cannot find a data source configuration named “Default_Development”, it will look for one named “default” before giving up.

An example section of an IdeaBlade.ibconfig file is showing below:

<rdbKey name="Default_Development">
  <connection>Provider=SQLOLEDB.1;Integrated Security=SSPI;
    Persist Security Info=False;Initial Catalog=IdeaBladeTest;
    Data Source=.</connection>
</rdbKey>
<rdbKey name="Default_QA">
  <connection>Provider=SQLNCLI.1;Integrated Security=SSPI;
    Persist Security Info=False;Initial Catalog=IdeaBladeTest;
    Data Source=.</connection>
</rdbKey>
<rdbKey name="Default_Test">
  <connection>Data Source=.;Initial Catalog=IdeaBladeTest;
    Integrated Security=True</connection>
</rdbKey>
<rdbKey name="Default_Test_ORACLE">
  <dataProvider>System.Data.OracleClient </dataProvider>
  <connection>Data Source=Oracle10G/ibnorth; Password=password;
    Persist Security Info=True;User ID=sa;</connection>
</rdbKey>

Note that the multiple RdbKeys for a single data source do not have to use the same ADO.NET dataProvider, nor do they have to reference the same database from the same database vendor (providing the schemas are compatible).

In addition, entities in the PM may map to more than one data source. The PM will suffix each data source key name with the same extension.

At runtime the appropriate datasource can be accessed via a call similar to the one below, where the “datasourceExtensionName” is determined dynamically by the executing application.

 C#:

PersistenceManager pm =
   new PersistenceManager (true, datasourceExtensionName);

VB.NET:

Dim pm As PersistenceManager = _
   New PersistenceManager (True, datasourceExtensionName)