Basis der Formeln in BA sind die Criteria Operator, welche eine Technologie von Dev Express ist. Als Beispiele sind da zu nennen die Datensatzfilter und die Berechnungsformeln bei der Konfiguration der Kalender.
Es gibt sowohl eine Klassenstruktur als auch eine Syntax für eine textuelle Darstellung.
Repräsentationsformen
String
Jede Criteria-Expression ist als String darstellbar. Diese Form ist für Benutzereingaben und Serialisierungen das Mittel der Wahl.
CriteriaOperator
Die Basisklasse CriteriaOperator ist eine technische Darstellung des Ausführungsbaumes.
Dialekte
Formeln in .NET
Diese Variation findet immer dann Anwendung, wenn ein Ausdruck in .NET ausgewertet und nicht an den XPO-Layer übergeben (IQueryable) wird.
Formeln in Reports fallen ebenfalls in diese Kategorie, weil die Report-Engine komplett im Speicher abläuft. Einzige Ausnahme: Filter auf Datenquellenebene. Diese werden von BA bisher aber noch nicht unterstützt.
.NET Formeln können auf alle Public Properties eines Objektes lesend zugreifen, auch jene, die nur programmiert sind und nicht nach SQL übersetzt werden können. Die Möglichkeit des Upcasting erlaubt auch auf Eigenschaften zuzugreifen, die zu konkreteren Datentabellen gehören (Siehe DevExpress). Beispiel:<OrmPhoneCall>Phone. Das castet erst auf OrmPhoneCall und nimmt dann das Property Phone.
Formeln in Datenbankabfragen (XPO)
Neben .NET können Formeln auch vom XPO-Layer nach SQL übersetzt werden. Das ist z.B. bei Filter-Expressions für Grids oder Kalender der Fall. Ebenso in berechneten Spalten derselben.
Restriktionen
- Es können nur XPO-kompatible Properties verwendet werden. Das sind neben den im Datenmodell definierten Spalten und Collections nur noch berechnete Properties mit einem PersistentAliasAttribut.
- Auch wenn es manchmal anders schein, Formeln können niemals Mengen liefern, sondern immer nur einzelne skalare Werte. Jeder Zugriff auf ein XPO-Collection-Property oder einen Free-Join muss daher mit einer Aggregatfunktion abgeschlossen werden.
- Aggregatfunktionen können nicht in Bedingungen geschachtelt werden.
[<OrmBABase>][[Oid]=[<OrmRelation>][[RelationType]={AF6FD532-FDE0-4732-964B-648B6E8B8415} && [Target]=[^^.Oid] && [IsPrimary]].Single([Source])].Single([EntityTitle])funktioniert nicht. Statt dessen muss die Subexpression in das Aggregat geschrieben werden:
[<OrmRelation>][[RelationType]={AF6FD532-FDE0-4732-964B-648B6E8B8415} && [Target]=[^.Oid] && [IsPrimary]].Single([<OrmBABase>][[Oid]=[^.Source]].Single([EntityTitle]))
Hybrid Formeln .NET/XPO
Bei Besimmten Formeln findet ein Übergang zwischen XPO und .NET statt. Das bedeutet, dass ein Teil des Ausdrucks in .NET verarbeitet wird und ein anderer Teil in XPO.
Beispiele
[IsActive && [RelatedParents][IsActive].Exists()]Diese Criteria, in .NET verwendet, führt das erste IsActive in .NET aus. Für den Zugriff auf RelatedParents wird allerdings eine DB-Zugriff benötigt. Dadurch wird das zweite IsActive und auch das Exists-Aggregat auf der Datenbank ausgeführt.
[<OrmSubAddressCompany>][[Parent] = ^.RelatedOwner.Oid && [SortOrder] = 0].Single(EntityTitle)Auch das wird, in .NET ausgeführt, nahezu komplett auf der Datenbank ausgewertet – wie auch sonst bei einem Free-Join. Einzig der Teilausdruck ^.RelatedOwner.Oid wird in .NET berechnet, denn durch den Parent-Operator verlässt dieser den Geltungsbereichs des Free-Join und muss entsprechend in .NET vorberechnet werden.