Files to look at:

• Model.DesignedDiffs.xafml
• Module.cs (VB: Module.vb)
• XpoDataStoreProxy.cs (VB: XpoDataStoreProxy.vb)
• XpoDataStoreProxyProvider.cs (VB: XpoDataStoreProxyProvider.vb)

Scenario
This example shows how to prevent altering the legacy database schema when creating an XAF application. Sometimes our customers want to connect their XAF applications to legacy databases, but they often have strong restrictions, which disallow making any changes in the legacy database schema, i.e. adding new tables, new columns. This is bad, because XAF creates the ModuleInfo table to use an application's version for internal purposes. XPO itself can add the XPObjectType table to correctly manage table hierarchies when one persistent object inherits another one. Usually, legacy databases contain plain tables that can be mapped to one persistent object. So, the XPObjectType table is not necessary in such scenarios.
However, one problem still remains: it is the additional ModuleInfo table added by XAF itself. The idea is to move the ModuleInfo and XPObjectType tables into a temporary database.

For this task we introduced a custom IDataStore implementation, which works as a proxy. This proxy receives all the requests from the application's Session objects to a data store, and redirects them to actual XPO data store objects based upon a table name that has been passed.

Steps to implement

1. In YourSolutionName.Module project create a custom IDataStore implementation as shown in the WinWebSolution.Module\XpoDataStoreProxy.xx file;

2. In YourSolutionName.Module project create a custom IXpoDataStoreProvider implementation as shown in the WinWebSolution.Module\XpoDataStoreProxyProvider.xx file;

3. In YourSolutionName.Module project locate the ModuleBase descendant and modify it as shown in the WinWebSolution.Module\Module.xx file;

4. Define connection strings under the element in the configuration files of your WinForms and ASP.NET executable projects as shown in the WinWebSolution.Win\App.config and WinWebSolution.Win\Web.config files.

IMPORTANT NOTES
1. The approach shown here is intended for plain database tables (no inheritance between your persistent objects). If the classes you added violate this requirement, the exception will occur as expected, because it's impossible to perform a query between two different databases by default.
2. One of the limitations is that an object stored in one database cannot refer to an object stored in another database via a persistent property. Besides the fact that a criteria operator based on such a reference property cannot be evaluated, referenced objects are automatically loaded by XPO without involving the IDataStore.SelectData method. So, these queries cannot be redirected. As a solution, you can implement a non-persistent reference property and use the SessionThatPointsToAnotherDatabase.GetObjectByKey method to load a referenced object manually.
3. As an alternative to the demonstrated proxy solution you can consider solutions based on database server features. Create a view mapped to a table in another database as a Synonym. Then map a regular persistent class to this view (see How to: Map a Database View to a Persistent Class).

See also:
How to implement XPO data models connected to different databases within a single application
How to: Use both Entity Framework and XPO in a Single Application