Atlas > Support > Tipps > Code Richtlinien > Richtlinien für das Core-Modell
OpusAtlas
InformationSuccess StoriesScreenshotsBeispielmodellNewsletterSupport
How ToTippsRelease Notes
Community
ProdukteOpen SourceSupport

Richtlinien für das Objektmodell

Module

Module sind Funktionsbereiche, der von den anderen Bereichen möglichst entkoppelt sind. Der Name gibt den Funktionsbereich an, und sollte ohne spezielle Prä- oder Postfixe geschrieben werden. Beispiele: _Main, Adressstamm, Debitoren

Dateien

  1. \MeinProjekt
  2.   \Adressstamm
  3.     \Core
  4.       \Model

Das Modul muss eine Haupt-Modelldatei mit dem Namen des Moduls und der Endung .aom

  1. MeinProjekt\Adressstamm\Core\Model\Adressstamm.aom
  1. object model Adressstamm
  2.  
  3. ...
  4.  
  5. end object model Adressstamm.

Jedes Modul sollte eine eigene Delphi-Startup-Unit haben, in der die Initialisation des Moduls vorgenommen wird. Diese Datei trägt per Konvention den Namen Init.pas

  1. \MeinProjekt\Adressstamm\Core\adrInit.pas
  1. unit adrInit;
  2.  
  3. interface
  4. uses
  5.   atApplication;
  6.  
  7. var
  8.   AdressstammModule: TAtModule = nil;
  9.  
  10. procedure Startup( _application: TAtApplication );
  11. procedure Shutdown;
  12.  
  13. implementation
  14. uses
  15.   SysUtils,
  16.   adrNachschlagelisten,
  17.   adrAdressen;
  18.  
  19. procedure Startup( _application: TAtApplication );
  20.   begin
  21.     if not Assigned( AdressstammModule ) then begin
  22.       AdressstammModule:= _application
  23.                .ModuleClass.Create( _application );
  24.       AdressstammModule.Name:= 'Adressstamm';
  25.       AdressstammModule.SetupStandardEnvironment;
  26.       AdressstammModule.Startup;
  27.     end;
  28.     adrNachschlagelisten
  29.                 .AttachModule( AdressstammModule );
  30.     adrAdressen.AttachModule( AdressstammModule );
  31.   end {Startup};
  32.  
  33. procedure Shutdown;
  34.   begin
  35.     FreeAndNil( AdressstammModule );
  36.   end {Shutdown};
  37.  
  38. end {adrInit}.

Referenzen

Bezeichner

Referenz eines anderen Moduls, das Elemente in diesem Modul verwendet

  1. object model Debitoren
  2.  
  3. uses Adressstamm

Referenz einer anderen Unit, die Elemente in einer Unit in diesem Modul verwendet

  1. object model Debitoren
  2. unit Belege
  3.  
  4.   uses Adressstamm.Adressen

Referenz aus einer anderen Unit auf ein Element in einer Unit in diesem Modul

  1. object model Debitoren
  2. unit Belege
  3.  
  4.   uses Adressstamm.Adressen
  5.  
  6.   ...
  7.  
  8.   relation
  9.     class Beleg has Adresse[1]
  10.     class Adressstamm.Adresse has Belege[0..n]
  11.   end relation

Modulpräfix

Jedes Modul kann einen eigenen Modulpräfix haben, der die Objekte in einem Modul kennzeichnet. Er sollte 2-4 Buchstaben lang sein, und mit einem Grossbuchstaben anfangen. Der Präfix wird im generierten Code den Namen von im Modul enthalten Units, Klassen und Links vorangestellt.

Beispiele: Adr, Deb, Sys

  1. object model Adressstamm
  2.   prefixForNamesInGeneratedCode 'Adr'

Der Modul-Präfix muss in der Schnittstellen-Datei ...Intf.aom deklariert werden, wenn das Modul eine solche hat. Sonst in der Hauptdatei .aom. Man kann ihn auch an beiden Orten angeben.

Units

Units gliedern ein Modul in eng zusammenhängende, in eigenen Quell-Dateien verwaltete Teilbereiche. Sie entsprechen direkt den generierten Delphi-Units. Der Name gibt den Teilbereich an, und sollte auch ohne spezielle Prä- oder Postfixe geschrieben werden. Beispiele: Adressen, Kunden, Belege, Nachschlagelisten

Dateien

Die Modell-Datei zu einer Unit sollte den Namen der Unit mit den Endung .aom

  1.   \MeinProjekt\Adressstamm\Core\Model\Nachschlagelisten.aom
  1. object model Adressstamm
  2. unit Nachschlagelisten
  3.  
  4.   ...
  5.  
  6. end unit Nachschlagelisten
  7. end object model Adressstamm.

Die Modelldatei muss von einer Haupt-Datei des Moduls include

  1. object model Adressstamm
  2.  
  3. prefixForNamesInGeneratedCode 'Adr'
  4.  
  5. includes Adressen
  6. includes Nachschlagelisten
  7.  
  8. end object model Adressstamm

Durch den oben definierten Modulpräfix Adr

  1. \MeinProjekt\Adressstamm\Core\adrNachschlagelisten.pas

Referenzen

Bezeichner

Referenz einer anderen Unit, die Elemente in dieser Unit verwendet

  1. object model Debitoren
  2. unit Belege
  3.  
  4. uses Adressstamm.Adressen

Modell-Klassen

Modell-Klassen definieren Daten-Objekt-Klassen im Atlas-Modell. Sie haben eine direkte Entsprechung in den generierten Delphi-Klassen. Klassennamen sollen in Einzahl stehen und die Art des beschriebenen Objekt-Typs angeben. Beispiele: Adresse, Ort, Anrede.

Warum Singular? Rein praktisch liest sich TFibuKontoObj und TFibuKontoLink besser als TFibuKontenObj. Argumentieren könnte man für TFibuKontenLink, aber aus Gründen der Konsistenz und damit Merkbarkeit verzichten wir hier darauf. Theoretischer: Eine Klasse beschreibt die Struktur der einzelnen Objekte eines Typs, nicht die Struktur der Typ-Menge (z.B. keine Kardinalität - Ausnahmen gibt es natürlich wie Eindeutigkeit von Werten innerhalb der Menge).

Delphi-Code

  1. class Adresse
  2.   ..
  3. end class Adresse

erzeugt in der generierten Delphi-Unit folgende Delphi-Klassen (Modul-Präfix ist Adr)

  1. type
  2.   TAdrAdresseObj = class;
  3.   TAdrAdresseLink = class;

Referenzen

Referenz in einer Relation

  1. relation
  2.   class Adresse has Ort[0..1]
  3.   class Ort has Adressen[0..n]
  4.   end
  5. end relation

Referenz aus dem View-Modell

  1. detail Adresse
  2.   coreClass Adresse
  3. list Adressen
  4.   coreClass Adresse

Im Code beim Datenzugriff

  1. var
  2.   adrs: TAdrAdresseLink;
  3.   iAdr: integer;
  4.   adr: TAdrAdresseObj;
  5. begin
  6.   adrs:= TAdrAdresseLink.Create( Session );
  7.   try
  8.     ...
  9.   finally
  10.     adrs.Free;
  11.   end;
  12. end;

In der Implementation von Methoden der generierten Klasse

  1. function TAdrAdresseObj.DoKannMailEmpfangen: boolean;
  2.   begin
  3.     result:= not VarIsNullOrEmpty( vEmailAdresse )
  4.         and MailSystemIstOnline;
  5.   end {DoKannMailEmpfangen};

Modell-Links

Modell-Links definieren Relationen zwischen Daten-Objekt-Klassen im Atlas-Modell. Ein Linkname entspricht häufig einfach dem Namen der Klasse, auf die der Link zeigt. Der Name steht im Singular (Einzahl), wenn die Kardinalität des Links eins ist, sonst im Plural (Mehrzahl). Beispiele zu Eins: Beleg hat Adresse, Adresse hat Ort und Anrede Beispiele zu N: Adresse hat Belege und Telefonnummern.

Wir verwenden bewusst die saubere Zahlform und keine speziellen Prä- oder Suffixe. Damit erreichen wir eine saubere Lesbarkeit von Queries und Code in der Anwendung. In Queries sind Links sowieso mit > ausgezeichnet (wie in [>Ort.PLZ] [>Ort.Name]) und im Code mit .l oder .o (wie in adr.oOrt.vName oder adr.lBelege.Count).

Delphi-Code

  1. relation
  2.   class Adresse has Ort[0..1]
  3.   class Ort has Adressen[0..n]
  4.   end
  5. end relation

erzeugt in der generierten Delphi-Unit folgende Delphi-Klassen (Modul-Präfix ist Adr)

  1. type
  2.   TAdrAdresseObj = class
  3.     property lOrt: TAdrOrtLink read;
  4.     property oOrt: TAdrOrtObj read write;
  5.   end {TAdrAdresseObj};
  6.  
  7.   TAdrOrtObj = class
  8.     property lAdressen: TAdrAdresseLink read;
  9.   end {TAdrAdresseObj};

Rollennamen

Zeigt eine Klasse über mehrere verschiedene Links auf dieselbe andere Klasse, so müssen die Links unterschiedliche Namen haben. Wir sprechen dann auch von einem Rollennamen. Es macht meist Sinn, den Namen der Zielklasse an den Rollennamen anzufügen: . Beispiele: Buchung hat SollKonto und HabenKonto

Schwieriger zu benennen sind in diesem Fall häufig die Umkehr-Relationen. Wir empfehlen Als.

Beispiele: Konto hat BuchungenAlsSoll und

  1. relation
  2.   class Buchung has SollKonto[1]
  3.   class Konto has BuchungenAlsSoll[0..n]
  4.   end
  5. end relation

Referenzen

Referenzen in AQL

  1. >Adresse(  // hier noch unschön!!
  2.   Name; Vorname;
  3.   HatKredit := >Kundengruppe.Kreditlimite > OffenerBetrag;
  4.   Anschrift := |[Strasse], [>Ort.PLZ] [>Ort.Name]|;
  5. )

Referenzen aus dem View-Modell

  1. link Belege
  2.   coreLink Belege
  3.   listView Belege
  4. end

Referenzen im Query-Setup-Code

  1. adr.Query.oOrt.vPLZ;
  2. adr.Query.oOrt.vName;
  3. adr.Query.lBelege.vBetrag;

Referenzen im Datenzugriffs-Code

  1.   plzOrt:= adr.oOrt.vPLZ + ' ' + adr.oOrt.vName;
  2.   anzBelege:= adr.lBelege.Count;

Eigenschaften

Fehlt noch.

Methoden

Fehlt noch.

Wertlisten

Fehlt noch.

© 2004-2009 Opus Software AG, Switzerland

Zuletzt aktualisiert am 13.02.2009.