Accessing real persistent objects through the SelectedObjects and CurrentObject properties of View and Action's event arguments when DataAccessMode = DataView or InstantFeedback

The View.CurrentObject and View.SelectedObjects properties return XafDataViewRecord objects instead of original business objects when the View operates in DataView mode (and XafInstantFeedbackRecord - in InstantFeedback mode). To get a real object, you can use the View.ObjectSpace.GetObject(obj) method.

I just wanted to remind you of this specificity and detail currently recommended solution strategies:

https://www.devexpress.com/kb=T584572

According to our current figures for support traffic in this regard (for one year of the InstantFeedback mode existence and more than two years of the DataView mode existence), this is not a big deal for our users - I located less than seven support requests in total. Probably, this is due to the fact that our learning materials already describe this or due to the fact that the DataView and InstantFeedback modes are used rarely, only when ListView contains a lot of records. Here I must also emphasize that this behavior exists in the first place because returning real objects by default may prevent you from getting all the benefits of these data access modes... So, we implemented the current design on purpose.

Should you have difficulties with these features and aforementioned solutions or can foresee better options, my team and I are happy to listen. For instance, one of the alternative solutions I saw in a couple places was the implementation of the auxiliary GetRealSelectedObjects/GetRealCurrentObject methods.

Experimental support of DataView mode in Analysis editors of the PivotChart module in v15.2.10 - YOUR FEEDBACK IS NEEDED

Starting with v15.2.10,  the DevExpress.ExpressApp.PivotChart.PivotChartModuleBase and 

DevExpress.ExpressApp.PivotChart.AnalysisEditorBase classes provide the new

 DataAccessMode property. The supported values are  Client (default) and DataView (new).Use the first class via the Application Designer to configure the required data access mode globally for all analysis editors in the application while the second class can be used in a ViewController to configure individual editors (learn more...).

Refer to the eXpressApp Framework > Concepts > UI Construction > Views > List View Data Access Mode  documentation to learn more on the specificities of each data access mode, because the validity of the PivotGridSettingsContent property is up to the XAF developer. For instance, in DataView mode non-persistent properties are not processed.

To test the preview version of this functionality right away in v15.2, almost one month prior to the official release, do the following:

Experimental support of DataView mode in Pivot Grid List Editors in v15.2.9 - YOUR FEEDBACK IS NEEDED

There is other performance related news today. This time it is for users who need to analyze and visualize large amounts of data using the pivot table. 

Starting with v15.2.9, we have made improvements to our Pivot Grid List Editors and are ready to share a preview of our work. So far, things are pretty stable, and we have not found any issues in scenarios with DataView (a few XAF customers tested this functionality earlier did not experience problems either). We still wanted to collect more feedback and hear from you about how this works in your real projects. The more scenarios we cover at this stage, the better for the product. If all goes according to plan, this functionality will be officially released in the upcoming 16.1 build, which should be out around early June.

Improving performance when a large portion of data matches a workflow activity criterion

Here is a real customer scenario from a related Support Center thread: 

"Hi, I have an application with several workflows that work ok in my local computer (testing with few records), but when I deploy the workflows to a server and the workflow gets approximately 1,500,000 records that match the criteria the workflow service crashes...

I've done some testing and this only happens when the workflow needs to deal with a lot of data, workflows that deal with less records don't have a problem. I've been looking for an alternative like XPCursor or something similar to ask the workflow to page the records that meet the criteria but I haven't found any."

After some time, we could replicate this behavior locally and found that it could be easily improved upon on our side. In short, our solution is in using XafDataView + a sort of paging  when first querying and processing records that match a certain workflow activity definition criteria in the workflow service. 

A minor improvement to the Object Property Editors that represent aggregated object references in the UI

From the related Support Center thread:

Starting with version 15.1.8, you can easily specify a custom DetailView for ObjectPropertyEditor via the Model Editor at the DetailView | Items or ListView | Columns node levels in the Application Model:

Thus,  the IModelMemberViewItem.View  attribute now helps you specify custom Views for all object reference property editors used in both ListView and DetailView.

Previously, this task required a custom-tailored code solution like in the How to change ASPxObjectPropertyEditor's DetailView thread.  So, I hope you find this addition helpful.

Simplifying declaration of calculated properties in code for DataView mode with Entity Framework

Starting with v14.2.4 (and even 14.1.9) you can use the DevExpress.ExpressApp.DC.CalculatedAttribute to specify an expression used to calculate a property value of an Entity Framework class in Data View mode:

[C#]
public class Payment {    
    public Int32 ID { get; protected set; }
    public Decimal Rate { get; set; }
    public Decimal Hours { { get; set; }
    [NotMapped, DevExpress.ExpressApp.DC.Calculated("Rate * Hours")]
    public Decimal CalculatedAmount {
        get { return Rate * Hours; }
    }
   // Other data properties and logic...
}

This attribute functions exactly like the DevExpress.Xpo.PersistentAlias attribute applied to a regular business class property. Of course, properties, referenced in the specified expression (using our cross-platform object-oriented criteria language) should be persistent to be able to run an SQL query at the database level. 

To remind you of the DataView mode, this is what you will see in the SQL Server Profiler if you set DataAccessMode = DataView for the Payment_ListView node containing only the Amount column above:

SQL:
SELECT 
    [Limit1].[ID] AS [ID], 
    [Limit1].[C1] AS [C1]
    FROM ( SELECT TOP (2147483647) 
        [Extent1].[ID] AS [ID], 
        [Extent1].[Rate] * [Extent1].[Hours] AS [C1]
        FROM [dbo].[Payments] AS [Extent1]
    )  AS [Limit1]

Note that even though our entity may contain a way more other persistent properties, the query included only the two from the expression above, which increases performance in certain scenarios.
The advantage of this attribute solution is that it is easier to keep your data model logic in one place/class instead of spreading it across multiple layers, e.g., Application Model, where the DataView settings are specified:

XAFML:
<ListView Id="Payment_ListView" DataAccessMode="DataView">
    <Columns>
       <ColumnInfo PropertyName="CalculatedAmount" IsNewNode="True" />
    </Columns>
</ListView>

If you are not sure of which ListView data access mode is best for your particular screen, these guidelines in our docs will help you decide.