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.

3 simple steps to improve the overall performance in a middle-tier application server scenario

UPDATED
The contents of this article were merged into the new document at Security - How to reduce the number of permission requests and improve overall performance.
=============

Preamble

Here I will be talking about the configuration described in the eXpressApp Framework > Concepts > Security System > New Security System > Middle Tier Security - WCF Service article, assuming that the application server (YourSolutionName.ApplicationServer) is used with a desktop client app (YourSolutionName.Win). I am not talking about the web client, because I anticipate that in this configuration the Client-Side Security (2-Tier Architecture) with the integrated mode (SecuredObjectSpaceProvider) is a more typical choice as long as the database is located on the same web server where the ASP.NET app is deployed.

1. Server or DataView data access mode for ListView

While this is not specific to the 'application server' scenario, it is still worth mentioning these options explicitly when you need to work with large lists in grids in an XAF app. You can learn more on how to select an appropriate mode for your particular case from the online XAF documentation: eXpressApp Framework > Concepts > UI Construction > Views > List View Data Access Modes.

The GetObjectsNonReenterant error for security permissions with complex criteria - Fixed in v15.2.5

In v15.2.5 we have made improvements at both the XPO and XAF levels to avoid the Entering state 'GetObjectsNonReenterant' from state 'CommitTransactionNonReenterant, CommitChangesToDataLayer' is prohibited due to state 'CommitChangesToDataLayer' error that might occur while evaluating security permission criteria involving collections during the object saving procedure (S170995). Our previous attempt was unsuccessful and I apologize for this and all the inconvenience this has caused you and your business.

Our new low-level solution does not require extra options on your side, and I invite you to test a new 15.2 build containing these improvements: 

http://downloads.devexpress.com/Share/DXP/S170995/DevExpressComponents-15.2.4.15357.exe

I am looking forward to hearing from you on how these improvements work in your real projects after installing this build and running the Project Converter tool. Thanks in advance!

Avoiding the GetObjectsNonReenterant error for security permissions with complex criteria

UPDATE2

Please see my latest "The GetObjectsNonReenterant error for security permissions with complex criteria - Fixed in v15.2.5" blog post.

UPDATE1

During further testing we found that the new solution is not appropriate for certain scenarios (e.g., when new objects are created and saved under certain scenarios) and eventually decided not to make this new mode as default in v15.2. We will also mark the CanCheckModifiedObject option as obsolete for now. We will try to approach this problem from another angle at a lower XPO level. As always, we will keep you posted of our results once have anything to share. We apologize for all the inconvenience here.

OUTDATED
Let me quote myself from the Security - Avoid the GetObjectsNonReenterant error while evaluating security permission criteria involving collections during the object saving procedure thread in our Support Center:

We have provided the new CanCheckModifiedObject property in the DevExpress.ExpressApp.Security.SecurityRule class, which can be used to avoid loading additional collections and thus throwing the "GetObjectsNonReenterant" error from XPO internals while evaluating security permission criteria during the object saving procedure.

If CanCheckModifiedObject = True, both currently modified and existing database records are validated by security rules (the current behavior leading to the error).

Otherwise, if CanCheckModifiedObject = False, only the existing database records are validated by security rules. The latter configuration should be suitable in most business scenarios we are aware of and this will be the default configuration in v15.2.

Thus, to avoid the "Entering state 'GetObjectsNonReenterant' from state 'CommitTransactionNonReenterant, CommitChangesToDataLayer' is prohibited due to state 'CommitChangesToDataLayer' for 'DevExpress.Xpo.UnitOfWork(35)'" error in v15.1.8+, 

set the static DevExpress.ExpressApp.Security.SecurityRule.CanCheckModifiedObject property to False in the entry point of your application; e.g., within the constructor of your platform-agnostic module (YourSolutionName.Module/Module.xx) OR within the Main method of the WinForms app (YourSolutionName.Win/Program.xx) OR within the Application_Start method of the ASP.NET app (YourSolutionName.Web/Global.xx).

For instance, below is the code I added in the MainDemo.Module/Module.cs file of the project from the E4045: How to separate data between employees and managers of different departments using security permissions example while testing this improvement locally:

New learning materials on the security system and middle-tier application server

Our team has recently created several help articles on the subject, which you may find helpful, as they describe certain configuration aspects in greater detail:

How to: Implement a WCF Application Server and Configure a Client Application for It
How to: Connect to the WCF Application Server from Non-XAF Applications
How to: Use the Integrated Mode of the Security System in Non-XAF Applications
How to: Configure Permissions to Allow Linking/Unlinking of Read-Only Objects
(find even more in our Task-Based Help...)

Let me know whether you like these additions and what other things you wish to learn more from us. We will be glad to consider them for the future.

Beware of Session.DataLayer in middle-tier scenarios

I would like to pay your attention to a couple of Support Center tickets on the subject: one and two.

It is important to remember that when you use DataServerObjectSpaceProvider with a dedicated application server (as per Middle Tier Security - .NET Remoting Service), then you cannot write the code like this:

        Session session = ((XPObjectSpace)View.ObjectSpace).Session;
        UnitOfWork uow = new UnitOfWork(session.DataLayer);

I recommend you use the View.ObjectSpace object and its methods to query and manipulate your data, if possible. This is because it will always work correctly regardless of whether you are using a middle-tier server or not.

If, for some reason, you cannot follow this recommended approach, use the Session.ObjectLayer property instead of the Session.DataLayer one.

BTW, you can test the Session.DataLayer property to execute your business logic on the server or on the client only:

protected override void OnSaving() {
if(Session.DataLayer != null && !(Session.ObjectLayer is DevExpress.ExpressApp.Security.ClientServer.SecuredSessionObjectLayer)
) {
        // Server
}
else { 
        // Client
}
base.OnSaving();
}

Here are also screenshots that show values for these properties when the OnSaving is called on the server or on the client sides:

Since we touched OnSaving here, I would also remind you that it can be executed several times (3 times in the screenshot above for the middle-tier scenario) in a general case (as per XPO Best Practices), so it is probably not the best place for your logic at all, unless you are ready to introduce additional checks here.

It is technically possible to run business logic on the application server side via the IApplicationDataService.Commiting event. I am afraid we currently do not have much documentation on this feature as we are improving it to support more scenarios (audit, validation, etc.).

See Also:

Object Access Layer

A trick for the XAF application server

As you probably know, the Application Server creates its own GUI-less XafApplication descendant - ServerApplication. When working with Application Server, you should be aware of a very important requirement desribed at http://documentation.devexpress.com/#Xaf/CustomDocument3438:

The ServerApplication.Modules collection. It should contain modules that are directly referenced by your client application. To see which client application modules are required, refer to the InitializeComponent method code in your WinApplication/WebApplication descendant. There is no need to add modules that are indirectly added to your client application (i.e., modules that are added to your custom modules).

In this blog post, I would like you to show you how to comply with this requirement without having to add extensive references to all the extra modules used in your client apps, and having to write a great number of lines like: serverApplication.Modules.Add(new DevExpress.ExpressApp.XXX.XXXModule());

My goal is to save you time in adding these references (the "Add Reference | .NET"  dialog has always been and still is one of the weakest places in Visual Studio prior to VS2012) and writing unfamiliar code in Visual Studio. Technically, I want to achieve this by cutting this initialization code to just a few lines in the application server project:

...
// Add your client application's modules to the ServerApplication.Modules collection here. 
List<ModuleBase> list = new List<ModuleBase>(new Solution2.Win.Solution2WindowsFormsApplication().Modules);
foreach(ModuleBase item in list) {
    if(!serverApplication.Modules.Any<ModuleBase>(m => m.GetType() == item.GetType())) {
        serverApplication.Modules.Add(item);
    }
}
...

The trick is to just reference two client apps assemblies (YourSolutionName.Win and YourSolutionName.Web) and then instantiate these the XafApplication descendants to grab their Modules list.

Of course, it can be achieved more easily, and we have the corresponding request in our TODO list: http://www.devexpress.com/Support/Center/Issues/ViewIssue.aspx?issueid=S38219 Feel free to share your ideas and suggestions on how to make this more usable for developers.