Data Access has been discontinued. Please refer to this page for more information.

Multiple Models Overview

This article is relevant to entity models that utilize the deprecated Visual Studio integration of Telerik Data Access. The current documentation of the Data Access framework is available here.

Telerik Data Access supports two main approaches for data access layer design that allow you to utilize multiple models in your application. The main difference between them is whether the models share the same connection string or each model has a connection string of its own.

Generally, the connection string supplies the information necessary for establishing a connection to a given database. In addition to that, during runtime Telerik Data Access uses it as identification for the in-memory MetadataContainer of the database elements which participate in a given model. The container is formed during the creation of the first instance of the context related to a given model and is cached in-memory for all of its following instances. All Telerik Data Access runtime features relay on it.

By default, the support for Multiple Models automatically aggregates the containers for models that share a connection string. Additionally, you are able to explicitly control whether the containers of models with common connection string should be aggregated or not. In the cases when multiple models do not share the same connection string, Telerik Data Access will not accumulate their containers.

The multiple models support of Telerik Data Access also offers a way of instantiating a context without providing a connection string. This ability can be utilized only after the context was instantiated at least once with the appropriate connection string:

Multiple Models With Different Connection Strings

This approach allows you to design the data access layer so that it contains more than one model and each model is consumed through a connection string of its own. With it, during runtime Telerik Data Access will create separate instances of metadata for each model and will use the appropriate one depending on the utilized model.

Since, all types of cache supported by Telerik Data Access (the cache on context instance level, Level 2 Cache, Level 2 Query Cache and Prepared Statement Cache) relay on the existence and the state of the corresponding containers, with the Multiple Models With Different Connection Strings approach you will have a separate instance of these features for each model.

Multiple Models With The Same Connection String

This approach allows you to design the data access layer of the application so that each logical part of a corresponding database is isolated in a separate model. In other words, the result would be a few models that use the same connection string. Here, during runtime Telerik Data Access could either aggregate on demand the MetadataContainer instances for all models utilized until the current moment or create a separate container for specified models.

Multiple Models With Aggregated MetadataContainer

By default, if the models created after a logical division of the database, are in the same namespace (Figure 1: Multiple Models With Aggregated MetadataContainer), during runtime Telerik Data Access will aggregate all the required containers (Figure 2: MetadataContainer Aggregation Process). The aggregation will be executed each time you utilize a model that was not used until the current moment.

This approach has the following considerations:

  • The multiple models need to be in the same namespace.
  • Since all types of cache supported by Telerik Data Access (the cache on context instance level, Level 2 Cache, Level 2 Query Cache and Prepared Statement Cache) relay on the existence and the state of the container corresponding to a given model, the data from them will be purged each time the in-memory container is aggregated with a new one.

Figure 1: Multiple Models With Aggregated MetadataContainer

Figure 2: MetadataContainer Aggregation Process

This design approach is demonstrated in the How to: Use Multiple Models With Aggregated MetadataContainer article.

Multiple Models With Separate MetadataContainer Instances

In case the classes from the multiple models are in different namespaces, during runtime Telerik Data Access will not automatically aggregate their container and will notify you about a metadata conflict with the help of MetadataException with text:

Failed to obtain a Database object. There is already opened context with the same ConnectionName/ConnectionString and its metadata is not compatible with the current one. See the inner exception for more details.

This approach has the following considerations:

  • The multiple models need to be in the same namespace.
  • Since the MetadataContainer instances of the models are different and because all types of cache supported by Telerik Data Access (the cache on context instance level, Level 2 Cache, Level 2 Query Cache and Prepared Statement Cache) relay on their existence and the state, with this approach you will have a separate instance of these features for each model.

To avoid this scenario, our recommendation is to adopt one of the following:

The How to: Use Multiple Models With Separate MetadataContainer Instances And The Same Connection String article contains workflows for solving this error.