KB Article T400009
Visible to All Users

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

Objects vs Tables

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.

Supported ORM and RDBMS for data access

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 (RDBMS) supported by these libraries. See the Database Engines Supported by XPO and Entity Framework Data Providers articles for more details.

If you have strict 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 SystemMiddle Tier Security - WCF Service, and Middle Tier Security - .NET Remoting Service help topics for details.

Non-ORM data access options (external API services, NoSQL, etc.)

If data from any custom data source (even NoSQL, web services, etc.) 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 the NonPersistentObjectSpace/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 the Business Model Design - Non-Persistent Objects section examples for more information.  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.

How to use another ORM with XAF

To support another ORM (e.g. NHibernate) as the main XAF application back end and reuse your data access code in ALL XAF Views (the same way it is done for XPO and EF), 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.EFCore*   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.

See Also

How to implement CRUD operations for Non-Persistent Objects stored remotely
How to customize the underlying database provider options and data access behavior in XAF
Should I use XAF with an old frozen or unchangeable database schema and all the business logic in raw SQL, stored procedures (SP)?

Disclaimer: The information provided on DevExpress.com and affiliated web properties (including the DevExpress Support Center) is provided "as is" without warranty of any kind. Developer Express Inc disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.

Confidential Information: Developer Express Inc does not wish to receive, will not act to procure, nor will it solicit, confidential or proprietary materials and information from you through the DevExpress Support Center or its web properties. Any and all materials or information divulged during chats, email communications, online discussions, Support Center tickets, or made available to Developer Express Inc in any manner will be deemed NOT to be confidential by Developer Express Inc. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.