Appstruktur / mehrere Apps

Wann sollte eine neue App erstellt werden?

• 1 Core-App pro „Projekt“ ist i.d.R. ausreichend
  • Wenn es noch „OnPrem“-Anpassungen gibt, dann gerne in eine separate App, da die OnPrem-App ja ggf. herausfällt nach einigen Major-Updates.
• Bei großen Projekten, wenn die Core-App so groß wird und Teile davon eher einem eigenen Modul gleichen, dann würde sich eine eigene einzelne App anbieten, um auch einen Performance-Vorteil bei der Auslieferung zu erzielen

Ordnerstruktur

Die Ordner können grundsätzlich nach Thema oder Objekttyp sortiert werden, oder in einer Mischform aus beiden. Hierbei sollte vor Projektstart abgewogen werden, wie entwickelt werden soll.

Nach Thema

Wenn an einer speziellen Anforderung entwickelt wird, kann hierzu alles gemeinsam in einem Ordner abgelegt werden. Dabei können Ordner eher allgemein und auch sehr spezifisch sein. Der Detailgrad der Ordnerstrukturierung kann individuell festgelegt und angepasst werden, bspw. wenn ein Themen-Ordner zu groß wird, kann man diesen ggf. noch einmal weiter unterteilen. Hierbei ist jedoch zu empfehlen, dass die Unterordner keine weiteren Unterordner haben, damit die Themenbereiche übersichtlich bleiben.

Beispielstruktur:

• src
  • ADCS
  • Sales
  • CrossDockingCarrier
  • ContractQuantity
  • Item
  • Disposer
  • etc.

Pro:

• Übersichtlichkeit der Themenbereiche
• Schnelles Finden von allen notwendigen Dateien zu einer Funktion
• Vorbild von Microsoft, siehe auch Thema Namespaces

Contra:

• Manche Objekte passen in mehrere Bereiche, daher eindeutige Einsortierung ggf. schwierig

Nach Objekttyp

Hierbei werden für die jeweiligen Objektarten eigene Ordner angelegt, in denen die AL-Dateien sortiert werden.

Beispielstruktur:

• src
  • codeunit
  • table
  • tableextension
  • page
  • pageextension
  • report

Pro:

• Automatische Speicherung und „Einsortierung“ möglich

Contra:

• Sehr große Ordner, mit vielen Dateien, in denen alle Themen gemischt sind
• Wird an einem Modul gearbeitet und hierfür verschiedene Objekttypen benötigt, muss man diese „zusammensuchen“, möglicherweise übersieht man dadurch ein Objekt

Struktur innerhalb von Objekten

• Tabellen
  • Felder
  • Keys
  • Trigger
  • Globale Variablen
  • Funktionen
  • Ggf. Eventpublisher
• Page
  • Felder
  • Actions
  • Trigger
  • Globale Variablen
  • Funktionen → nur Pagelogik
  • Ggf. Eventpublisher
• Codeunit
  • Trigger
  • Globale Variablen
  • Funktionen
  • Ggf. Eventpublisher
  • Subscriber Codeunits (siehe Kapitel Eventsubscriber)
• Hinweise:
  • "Regions"
    • Nutzung, wenn sinnvoll zur Aufteilung einer Codeunit, Tabellen …
    • Wird verwendet, um zum Beispiel Funktionen, die zu einem Themenbereich gehören zusammenzufassen
  • Funktionen-Abschnitt innerhalb der genannten Objekten: Sortierung lokal/global
  • Allgemeine Hilfsfunktion in eigene Codeunit auslagern, auf die von den speziellen Funktionen dann zugegriffen werden kann. Das klingt banal, sieht man oft aber auch noch anders.
    • Beispiel Schnittstellen: Angenommen, es müssen verschiedene Nachrichten (EK-Bestellung und VK-Auftrag) erstellt werden. In jeder Nachrichtenart müssen Datumswerte für das Zielsystem speziell formatiert werden, dann sollte die Formatierungsfunktion nicht in der zuerst angelegten Codeunit z.B. für EK-Bestellung erstellt und aus der VK-Auftrags-Codeunit darauf zugegriffen werden, sondern in eine dedizierte Codeunit ausgelagert werden, auf die dann beide zugreifen.