Telerik OpenAccess Classic

Telerik OpenAccess ORM Send comments on this topic.
Using Configuration Files for Class Libraries
Programmer's Guide > OpenAccess ORM Classic (Old API) > Programming With OpenAccess > Configuration File > Using Configuration Files for Class Libraries

Glossary Item Box

This documentation article is a legacy resource describing the functionality of the deprecated OpenAccess Classic only. The contemporary documentation of Telerik OpenAccess ORM is available here.

Up to now, all configuration information for OpenAccess ORM was added to the "openaccess" node of the application configuration file (App.config or Web.config). However, there are often situations where you would like to have the configuration information distributed over several configuration files. If, for instance, you have written a class library with persistence capable classes, you might not want to copy the mapping information to the application configuration file of all applications using this library. It would be much easier—and more elegant—to have a configuration file for the class library which contains all mapping information for the contained classes. Then you can simply reference this configuration file from your application configuration file. The same might be true if you have a class library for database access where you want to have a configuration file containing all backend configurations.

Distributed Configuration

The following example demonstrates the usage of multiple configuration files. In this example, an application that uses a class library named DBAccess that contains the database access and two libraries, Model1 and Model2, with the persistence capable classes. The mapping information is stored in the configuration files for Model1 and Model2. The backend configuration is stored in the configuration file for the DBAccess library. The connections are defined in the application configuration file.

The App.config file
Copy Code
<configuration>
 
<configSections>
   
<section name="openaccess"
     
type="Telerik.OpenAccess.Config.ConfigSectionHandler, Telerik.OpenAccess.Config, Version=1.0.0.0,
     
Culture=neutral, PublicKeyToken=4a339ffcee0b897b"/>
 
</configSections>
 
<openaccess>
   
<connections>
     
<connection id="DBConnection1">
       
<databasename>MyBase</databasename>
       
<servername>MyServer</servername>
       
<user>openaccess</user>
       
<password>openaccess</password>
       
<backendconfigurationname>mssqlConfigurarion</backendconfigurationname>
     
</connection>
   
</connections>
   
<references>
     
<reference assemblyname="DBAccess" configrequired="true"/>
   
</references>
 
</openaccess>
</
configuration>
The DBAccess configuration file
Copy Code
<configuration>
 
<configSections>
   
<section name="openaccess"
     
type="Telerik.OpenAccess.Config.ConfigSectionHandler, Telerik.OpenAccess.Config, Version=1.0.0.0,
   
Culture=neutral, PublicKeyToken=4a339ffcee0b897b"/>
 
</configSections>
 
<openaccess>
   
<backendconfigurations>
     
<backendconfiguration id="mssqlConfiguration" backend="mssql">
       
<isolationLevel>REPEATABLE_READ</isolationLevel>
       
<mappingname>mssqlMapping</mappingname>
     
</backendconfiguration>
   
</backendconfigurations>
   
<references>
     
<reference assemblyname="Model1" configrequired="true"/>
     
<reference assemblyname="Model2" configrequired="true"/>
   
</references>
 
</openaccess>
</
configuration>
The Model1 and Model2 configuration files
Copy Code
<configuration>
 
<configSections>
   
<section name="openaccess"
     
type="Telerik.OpenAccess.Config.ConfigSectionHandler, Telerik.OpenAccess.Config, Version=1.0.0.0,
     
Culture=neutral, PublicKeyToken=4a339ffcee0b897b"/>
 
</configSections>
 
<openaccess>
   
<mappings>
     
<mapping id="mssqlMapping">
       
<!-- Mapping information for Model1 or Model2 (in separate files) -->
     
</mapping>
   
<mappings>

 
</openaccess>
</
configuration>

General Rules

The general rules for using multiple configuration files are as follows.

Entry Point
 

There always has to be an application configuration file as an entry point to the <openaccess> configuration information.

Assembly References
 

Reference elements must be used to specify referenced assemblies. References can be defined recursively. In the example above, the application configuration file has only one reference to the DBAccess library, which in turn has two references, one to Model1 and one to Model2.

Config File References
 

For each reference element, it is also checked if there is a configuration file for the referenced assembly. If a configuration file is found, the configuration information from this file is included. For locating the configuration file for an assembly, the following search criteria are used in order.

1.

 

It is checked if there is an embedded resource with name App.config or *.App.config embedded within the assembly that contains a <openaccess> node. If yes, this configuration file is used (You can add an embedded resource by choosing the build action Embedded Resource for the App.config file in Visual Studio or by using the -resource:<filename> compiler switch).

2.

 

It is checked, if there is a file assemblyname.dll.config in the same directory, where the assembly is located. If yes, then this configuration file is used.

As in the example above, you can use the configrequired attribute to indicate that a configuration file must exist for the referenced assembly. If no configuration file is found, a ConfigurationException will be thrown by OpenAccess.

In the example above, you might add embedded resources named App.config to the DBAccess, Model1, and Model2 libraries and have DBAccess.dll.config, Model1.dll.config, and Model2.dll.config files in the directory where the libraries are located. By default, OpenAccess ORM configuration files are added as embedded resources to class libraries in Visual Studio projects.

Resolution of Name References
 

If there is more than one matching backendconfiguration node for a <backendconfigurationname> element, the backend configuration found first will be used. Here, the following search order is used.

1.

 

Backend configurations in the application configuration file

2.

 

Backend configurations in configuration files directly referenced from the application configuration file (we call them level 1 configuration files). Among these files, the order of the references in the application configuration files is used.

3.

 

Backend configurations in configuration files of level 2, 3, and so on.

If there is more than one matching mapping node for a <mappingname> element, all the matching mapping nodes are used. In the example above, both mapping nodes in the configuration files for Model1 and Model2 have the same id attribute value, i.e., "mssqlMapping". The <backendconfiguration> has one <mappingname> element, <mappingname>mssqlMapping</mappingname>, which triggers the use of both mapping sections.