Was man bei Base Enums beachten sollte

Schon einmal einen Base Enum in Dynamics AX erstellt? Oder einen bestehenden erweitert?

Ja?! Dabei auch auf das folgende geachtet?

.) Das erste Element eines Base Enums sollte den Wert 0 aufweisen und dieser sollte "Undefiniert", "Kein", "Unbekannt" oder ähnlichem entsprechen. Vor allem wenn man den Base Enum später in Tabellen verwenden möchte, die bereits Daten enthalten.
Selbst wenn man davon ausgehen kann, daß man einen solchen undefinierten Zustand nicht benötigt, sollte man die 0 reserviert halten, sprich der erste "echte" Wert des Base Enums sollte 1 entsprechen.

.) Freihalten von Werten
Üblicherweise wird ein Base Enum so aufgebaut: 0, 1, 2, 3, ...
Ich persönlich bin - vor allem dann, wenn der Base Enum einen Status abbilden soll - dazu übergegangen meine Base Enums wie folgt aufzubauen: 0, 10, 20, 30, ... Diese Vorgangsweise erleichtert einem die Arbeit ungemein, wenn man zu einem späteren Zeitpunkt einen "Zwischenstatus" einführen muss.

Beispiel:

Angenommen, ein Base Enum bildet einen Status ab und weist folgende Werte auf: 0=None, 1=Started, 2=Registered, 3=Confirmed, 4=Processed, 5=Finished.

Wenn man nun alle Datensätze einer Tabelle, deren Status noch nicht auf Finished gesetzt ist, abfragen möchte, kann man dies mit folgender Abfrage abbilden:

select tableName
where tableName.statusField < StatusEnum::Finished;

Erweitert man später den Base Enum um den Wert 6=Approved, der aber eigentlich zwischen den Stati 3=Confirmed und 4=Processed angesiedelt sein sollte müsste man die Abfrage wie folgt anpassen:

select tableName
where tableName.statusField < StatusEnum::Finished
         || tableName.status == StatusEnum::Approved;

.) Werte beim Erweitern von Base Enums freihalten
Beim Erweitern von Base Enums, die aus der Standard-Applikation stammen, immer zwischen den bestehenden und den eigenen, neuen Werten auseichend "Platz" für Anpassungen durch den Hersteller lassen.

Beispiel: Erweiterung des Base Enums SalesType

0 Journal
1 DEL_Quoation
2 Subscripton
3 Sales order
4 Returned order
5 Blanket order
6 Item requirements
101 Custom Type 1
102 Custom Type 2

Nichts wäre ungünstiger, als daß sich der Hersteller, z.b. im Zuge eines Versionupgrades, dazu entschließt einen neuen Wert einzuführen, der mit einem eigenen kollidiert. In einem solchen Fall wären Daten-Upgrade-Jobs unvermeidlich, warum also sich diese Arbeit nicht bereits im Vorfeld ersparen.

Übrigens: Der maximale Wert für Base Enums liegt bei 250 (zumindest unter AX 2009), Platz ist also genug!

.) Bei neuen Base Enums auf den Namen achten
Entsprechend der Best-Practice-Anweisungen des Herstellers sollte man den Namen richtig wählen, so ist z.B. unbedingt ein Präfix zu verwenden. Damit minimiert man die Wahrscheinlichkeit, z.B. im Zuge eines Release-Upgrades Probleme zu bekommen. Es könnte ja sein, daß der Hersteller selbst einen gleichnamigen Base Enum einführt!

Dieser Beitrag bezieht sich auf die Versionen:
Axapta 2.5, Axapta 3.0, Dynamics AX 4.0, Dynamics AX 2009, Dynamics AX 2012

 
 

 

 
 
 
Beiträge des aktuellen Monats
November 2024
MoDiMiDoFrSaSo
 123
45678910
11121314151617
18192021222324
252627282930 
 
© 2006-2024 Heinz Schweda | Impressum | Kontakt | English version | Mobile Version
Diese Webseite verwendet Cookies, um Benutzern einen besseren Service anzubieten. Wenn Sie weiterhin auf der Seite bleiben, stimmen Sie der Verwendung von Cookies zu.  Mehr dazu