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 IDataStoreAsync 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.

1. In YourSolutionName.Module project create a custom IDataStoreAsync implementation as shown in the XpoDataStoreProxy.cs file;
2. In YourSolutionName.Module project create a custom IXpoDataStoreProvider implementation as shown in the XpoDataStoreProxyProvider.cs file;
3. For Blazor, in YourSolutionName.Blazor.Server project locate the XAF Application Builder invokation and modify the ObjectSpaceProviders initialization as shown in the Startup.cs file;
4. For Win/Web, in YourSolutionName.Module project locate the ModuleBase descendant and modify it as shown in the Module.cs file;
5. Define connection strings under the <connectionStrings> element in the configuration files of your WinForms and ASP.NET executable projects as shown in the WinWebSolution.Win\App.config, WinWebSolution.Win\Web.config and AspNetCore.Blazor.Server\appsettings.json files.

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 IDataStoreAsync.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).

• Module.cs for Win/Web or Startup.cs for Blazor
• XpoDataStoreProxy.cs
• XpoDataStoreProxyProvider.cs

• How to: Use both Entity Framework and XPO in a Single Application

• How to implement XPO data models connected to different databases within a single application