IMPORTANT NOTE
This article describes some advanced customization techniques and low-level entities of the framework with regard to data access, which may be required in complex scenarios only.
So, if you just want to change the connection string, e.g. to use the Oracle instead of the Microsoft SQL Server database, then you would better refer to the Connect an XAF Application to a Database Provider article and documentation on your database provider instead. The XAF integration of supported ORM libraries is also described in the Business Model Design section of the framework's documentation.
Introducing IObjectSpaceProvider and IObjectSpace
XAF accesses data from a data store through special abstractions called - IObjectSpaceProvider and IObjectSpace.
The IObjectSpace is an abstraction above the ORM-specific database context (e.g., the DBContext used in Entity Framework or the Session in XPO) allowing you to query or modify data.
The IObjectSpaceProvider is a provider/creator of IObjectSpace entities, which also manages which business types these IObjectSpace are supposed to work with, how to set up the underlying connection to the database, create and update it and other low level data access options.
![]()
An XafApplication can use one or several IObjectSpaceProvider objects at the same time, and you can access this information through the XafApplication.ObjectSpaceProvder or XafApplication.ObjectSpaceProviders properties. Check out these help links to learn more on how to plug in custom IObjectSpaceProvider objects a well.
There are several built-in implementations of the IObjectSpaceProvider and IObjectSpace interfaces in our framework, which are usually specific to a target ORM (Entity Framework or XPO). I suggest you check out the source code of the default framework classes to better understand the role of the IObjectSpaceProvider:
...\DevExpress.ExpressApp.Xpo\XPObjectSpaceProvider.cs
...\DevExpress.ExpressApp.EF\EFObjectSpaceProvider.cs
Typical customization considerations
You may want to provide a fully custom IObjectSpaceProvider implementation or inherit from the built-in implementors when you want to customize how data access is performed for a chosen ORM.
Below is a list of typical scenarios where a custom IObjectSpaceProvider may be required:
1. How to use XPO caching in XAF
2. How to prevent altering the legacy database schema when creating an XAF application
3. How to connect to remote data store and configure WCF end point programmatically
4. How do I change the default schema in the database
5. How to use a custom ObjectSpace throughout the application by handling the CreateCustomObjectSpaceProvider event?
6. How to connect different ORM data models to several databases within a single application
In most cases, it is not required to implement the IObjectSpaceProvider interface from scratch since you can inherit from existing implementors or customize/just their parts.
XPO-specific customizations
1. Implementing IXpoDataStoreProvider
For instance, in XPO one of such replaceable parts is the IXpoDataStoreProvider interface, which enables you to provide a custom or configured IDataStore object, which is used for underlying data access with this ORM:
[C#]
publicinterfaceIXpoDataStoreProvider{IDataStoreCreateWorkingStore(outIDisposable[]disposableObjects);IDataStoreCreateUpdatingStore(outIDisposable[]disposableObjects);stringConnectionString{get;}}
In its turn, XAF provides several ready to use implementations of this interface for most popular scenarios:
1. ConnectionDataStoreProvider - can provide IDataStore by the IDbConnection object;
2. ConnectionStringDataStoreProvider - can provide IDataStore by just connecting string information;
3. MemoryDataStoreProvider - DataSet based in-memory IDataStore providers.
Technically, such an IXpoDataStoreProvider part is passed into the XPObjectSpaceProvider constructor as a parameter, which means that you can just customize it instead of re-implementing the whole XPObjectSpaceProvider logic.
Refer to the ...\DevExpress.ExpressApp.Xpo\XPObjectSpaceProvider.cs file within the XAF source code to better understand the role of this part.
2. Overriding XPO connection or database providers
To learn more on this approach, check out the Database Systems Supported by XPO help topic and How to create a custom XPO connection provider and then use it in an XAF application article in particular. To learn more on customizing data access settings for XPO, please refer to the corresponding product documentation: Data Access Layer.
See Also:
Can I connect an XAF application to a custom data source (Web service, OData service, NoSQL database, etc.)?
Question Comments
Added By:
Rejoice Supsup at:
9/16/2015 11:33:05 AM Is this intended to contain an empty example resource?
Added By:
Dennis (DevExpress Support) at:
9/16/2015 11:46:15 AM Yes. This article originally contained an example, but it is now more like a KB article.
Added By:
Rejoice Supsup at:
9/16/2015 12:00:10 PM Thank you for the quick reply. But I thought this might be misleading since it's categorized as an example. Should I expect that you're be providing an example in the future? If I may suggest, what about 2 databases:
#1 - Departments and Employees
#2 - Customers and Orders
Where #1 is integrated with the Security Module and #2 (used by XAF Win Forms) to manage CRM data but will be authenticated via DB #1.
Added By:
Dennis (DevExpress Support) at:
9/16/2015 12:16:34 PM The category is to be changed in the future as the main purpose of this article is to describe the main concepts.
There are already multiple examples mentioned in this article - see under the "Typical customization considerations" section (no plans for new examples so far). I hope you find them helpful to implement your particular scenario. Should you have any further difficulties with your own implementation, please submit a separate ticket and attach your sample showing what you tried to do and what did not work as expected. Thanks.