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 System, Middle 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)?