Best practices

One entity view = one UI view

Entity views must be specific to their use. Using the same entity view to display a list and to edit an element is not good practice for performance reasons. The information to be displayed in the two UI views very often differs. In the case of a list, the properties to be displayed are less rich. In the case of an input form, all the properties may need to be entered and sometimes even some navigation properties need to be embedded. Added to this is the business code present in an entity view, which may only make sense in only one UI view (retrieving/ed, saving/ed rules, expressions, etc.). We are also looking at the entity views attached to the lookups. In the case of lookups, the properties retrieved are very often limited.

Example

I want to create two screens: the first listing the list of read-only orders, and the second allowing you to edit them.

In the case of the list, an entity view showing the order number, total amount and customer name will be created. No navigation properties will be used. The order number and amount will be retrieved directly from the order header, and the customer name can be constructed from an expression. On the other hand, creating/updating the order will require all the fields that can be entered to be retrieved. The list of order lines will very often also be embedded, along with all the properties that can be entered. Reusing this rich entity view when 50 orders are retrieved will cause performance problems.

Expression property

To retrieve one property from a reference, use an expression.

Example

I want to create a UI view to consult my list of sent emails. In the columns of my list, for each line I want to display the name of the company that sent it.

On the entity view used to display my message list ('MessageListView'), in order to access the 'Name' property of the 'Company' entity, it is not necessary to add the full embedded reference to the Company. Instead, you can add an expression property to your entity view by defining 'e.Company.Name' as the source.

When your UI view is loaded, this results in the execution of a lighter SQL query integrated into the entity view's global query.

Warning

Expression is possible provided that the Linq expression engine is able to interpret it correctly.