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