Can I connect an XAF application to a custom data source (Web service, OData service, NoSQL database, etc.)?

My colleague Michael and I have recently worked on the article clarifying the currently supported data stores for XAF, because from time to time we receive questions like the one above. Even though this is a very basic information, it is still worth checking out even if you already have some XAF experience. Please let me know if there are any questions on this.

XAF is a framework designed to visualize and work with data represented as business or domain objects. The object-relational mapping (ORM) concept is very important here as in our framework you should not normally think of database tables, stored procedures (SP), SQL statements, but rather operate data in an object-oriented manner. Check out the Business Classes vs Database Tables article and information about Domain Driven Design (DDD) to get more inspirations. To access and manipulate objects, queries for all CRUD operations are performed dynamically based on view properties via the IObjectSpace API in a unified way. This design implies certain requirements to the XAF application data source, and makes it difficult to use an arbitrary data service or a specialized database in this role.

Currently, XAF supports the XPO  and Entity Framework ORM libraries out of the box with the help of the XPObjectSpace/XPObjectSpaceProvider  and EFObjectSpace/EFObjectSpaceProvider APIs respectively. They allow connecting an XAF application directly to relational databases supported by these libraries. See the Database Engines Supported by XPO and Entity Framework Data Providers articles for more details.

Also, starting with version 16.1, we introduced the XAF Mobile (CTP) Application Platform. It exposes the XAF application database via the standard OData V3 service that can be consumed by the XAF mobile client, as well as by any custom client you may want to create. Refer to the FAQ: New XAF HTML5/JavaScript mobile UI (CTP) article for more details.

If data from any custom data source (even NoSQL) needs to be used in some XAF views (not all, because otherwise ROI from using XAF can be low), without replacing the main XAF application data store, non-persistent or POCO objects can be used to represent this data with the help of theNonPersistentObjectSpace/NonPersistentObjectSpaceProvider  APIs.  Non-persistent data is usually not queried from a database using your ORM data model, and this can be extremely helpful for analysis and reporting data obtained from dynamic runtime calculations, stored procedures, arbitrary SQL queries or third-party services. Also, such a non-persistent POCO class may be required if you want to display a standard XAF List or Detail View with temporary data generated in code or loaded from a custom storage; or display an empty View (dialog) and then process the user input. Refer to examples in the "Business Model Design - Non-Persistent Objects" part of the Task-Based Help topic for more details. Alternatively, you can display and manipulate any custom data with the help of non-XAF forms or fully custom user controls embedded into standard XAF views as described at eXpressApp Framework > Concepts > UI Construction > Using a Custom Control that is not Integrated by Default.

In case the demand for a custom data source is dictated by data security requirements, XAF provides an out-of-the-box solution based on the Middle-tier Application Server (for XPO only). Refer to the New Security System, Middle Tier Security - WCF Service, and Middle Tier Security - .NET Remoting Service help topics for details.

To use another ORM (e.g. NHibernate)  or fully custom data source as the main XAF application back end, the following extension points can be used:

1. Implement a custom XAF Object Space Provider by implementing the IObjectSpaceProvider and IObjectSpace interfaces. We do not provide any ready guidelines for supporting another ORM library or data access technologies, though, because this is quite an advanced task and is of no interest for the majority of our users. If you wish and are ready to support another data access technology for XAF, you may research our XPO and EF-related implementations in the source code (see the ...\DevExpress.ExpressApp.Xpo\ and ...\DevExpress.ExpressApp.EF\  folders).

2. Implement a custom XPO provider (IDataStore). Refer to the How to create a custom XPO connection provider and then use it in an XAF application article and the source code of existing XPO providers.

Note: the last two solutions require a deep knowledge of the DevExpress XAF and XPO/Data Library  internals and might be difficult to implement. We don't have examples of such implementations except for built-in providers whose source code you can examine.  The information from the How to customize the underlying database provider options and data access behavior in XAF article can be helpful as well.

If the options described above do not meet your requirements or you have additional questions, please feel free to submit a ticket to the Support Center, and describe your use-case and requirements in detail. With that, we will be in a better position to describe the best technical options for you.