How to create a Framework

Transkript

1 How to create a Framework Gerd Volberg OPITZ CONSULTING Deutschland GmbH Nürnberg, 18. November 2014 OPITZ CONSULTING GmbH Seite 1

2 Agenda 1. Wofür braucht man ein Framework? 2. Style Guide 3. Programmiervorschriften 4. Layout-Vorschriften 5. Namenskonventionen 6. Templates + Vererbungsstrategien 7. Demos OPITZ CONSULTING GmbH Seite 2

3 Wofür braucht man ein Framework? 1. Corporate Design durch einheitliches Look&Feel 2. Programmier-Vorgaben für das Entwickler-Team Programmiervorschriften Layout-Konventionen Namenskonventionen Interaktion mit der Datenbank (Surrogate Keys, API s, ) 3. Templates und Libraries vereinfachen und verkürzen die Entwicklungsphase 4. Bessere Wartbarkeit der Applikation OPITZ CONSULTING GmbH Seite 3

4 Style Guide OPITZ CONSULTING GmbH Seite 4

5 Style Guide 1. Der eigene, firmenweit gültige Style Guide ist die Bibel einer unternehmensweiten Softwareentwicklung. 2. Im Style Guide werden alle Themen beschrieben, die während des Software-Erstellungsprozesses und darüber hinaus in der Wartungsphase relevant sind. OPITZ CONSULTING GmbH Seite 5

6 Style Guide Primary Keys 1. Tabellen in einer relationalen DB benötigen Primary Keys. Diese sollten immer mit der gleichen Technik erzeugt und eingesetzt werden: 2. Sprechende Schlüssel Sind meistens abgeleitet aus den eindeutigen Attributen einer Tabelle. Bestehen oft aus mehreren Attributen (Verbundschlüssel). Vorteile: Gut lesbar, da sie aus relevanten Tabellendaten bestehen. 3. Surrogate Keys Der Primary Key besteht aus einer Spalte (Sequenzen befüllen ihn). Der PK hat keinen Bezug zu den Daten seiner Tabelle. Vorteile: Der PK ist nicht änderbar, hat eine optimale Indizierung und ist sehr einfach nutz- und referenzierbar OPITZ CONSULTING GmbH Seite 6

7 Style Guide Surrogate Keys Surrogat-Key Jede Tabelle bekommt einen festen ALIAS aus 4 Buchstaben Primary Key => ALIAS + "_ID" Foreign Key => Primary Key der Fremdtabelle OPITZ CONSULTING GmbH Seite 7

8 Programmiervorschriften OPITZ CONSULTING GmbH Seite 8

9 Programmiervorschriften (1) Alle Regeln, die im Team gelten sollen, müssen definiert werden und sollten niemals verletzt werden. Z.B. GOTO verboten - Wer trotzdem mit GOTO arbeiten möchte, kann ja in BASIC weiterarbeiten LABEL verboten (wenn sie als Sprungmarke genutzt werden) RETURN nur in Funktionen erlaubt EXIT in Loops verboten - Loops schreibt man besser immer mit einem beginnenden FOR oder WHILE TAB verboten. Zur Einrückung immer 2 Leerzeichen pro Ebene OPITZ CONSULTING GmbH Seite 9

10 Programmiervorschriften (2) Web-Regeln Keine ActiveX, OCX, OLE, VBX einsetzen (Stattdessen Java-Beans) Keine WHEN-MOUSE-ENTER/LEAVE/MOVE Trigger Richtlinien Hochfrequente Timer sollten nicht verwendet werden Die Netzwerkverbindungen sollten optimiert werden Datenbankabfragen sollten so effizient wie möglich formuliert werden und optimalerweise in einem API in der Datenbank liegen OPITZ CONSULTING GmbH Seite 10

11 Layout-Vorschriften OPITZ CONSULTING GmbH Seite 11

12 Layout-Vorschriften (1) 1. Hierunter fallen zum Beispiel die Definition einer Standard- Grösse für alle Formsmasken. Z.B. 1280*1024, 1680* Neben den Runtime-Einstellungen sollten auch die Designtime-Einstellungen verbindlich definiert werden. Ruler-Settings OPITZ CONSULTING GmbH Seite 12

13 Layout-Vorschriften (2) Grid einschalten, Show Canvas ausschalten Dadurch wird der Layout Editor optimal benutzbar: Standardabstände X-Richtung: 6 Y-Richtung: 18 OPITZ CONSULTING GmbH Seite 13

14 Namenskonventionen OPITZ CONSULTING GmbH Seite 14

15 Namenskonventionen (DB) Benamung von Objekten in der Datenbank ist sehr wichtig. Hier sollten strengste Konventionen gelten. Objekt Notation Tabelle <28 Zeichen> Sprechender Name. Tabellennamen immer Plural. Primary Key <TabellenAlias> _ID Vierstelliger eindeutiger Alias des Tabellennamens. Foreign Key (1) <ReferenzAlias> _ID <ReferenzAlias> ist der Alias der Referenz-Tabelle. Foreign Key (2) <ReferenzAlias> "_ Mehrfachreferenz auf die gleiche Tabelle. <22 Zeichen> _ID Foreign Key (3) <TabellenAlias> "_ Selbstreferenz auf die eigene Tabelle. <Primary Key> Tabellen-Spalte <25 Zeichen> Sprechender Name, 25 Zeichen max. wg View-Spalten innerhalb einer Tabelle. View <TabellenName> _V View, die auf einer Tabelle aufbaut (Standard-View). View <TabellenName>[x] _V Mehrere Views auf der gleichen Tabelle. View <28 Zeichen> _V Der Name der View beinhaltet mindestens den Namen der wichtigsten Tabellen, die benutzt werden. View <27 Zeichen>[x] _V Bei mehreren Views, die auf die gleichen Tabellen schauen. View-Spalte <TabellenAlias> "_" <Tabellen-Spalte> Der Name einer View-Spalte setzt sich aus dem Alias der zugehörigen Tabelle und dem Originalnamen der Spalte in dieser Tabelle zusammen. Damit sind die Spalten der View immer eindeutig. Sequence <TabellenAlias> _SEQ Die Standard-Sequence jeder Tabelle setzt sich aus dem Tabellen-Alias und "_SEQ" zusammen OPITZ CONSULTING GmbH Seite 15

16 Namenskonventionen Am Beispiel einer Auftrags- und Positionentabelle wird hier nun exemplarisch gezeigt, wie Namenskonventionen aussehen könnten Alle Themenbereiche, in denen Konventionen benötigt werden, kommen auf den nächsten Seiten OPITZ CONSULTING GmbH Seite 16

17 Namenskonventionen (DB) Interne Benamungen in der DB Objekt Notation Tabellen-Alias <4 Zeichen> Abkürzung der Tabelle (Unique über alle Projekte) Primary Key <Alias> _PK Foreign Key <Alias_von>_<Alias_nach> _FK Foreign Key <Alias_von>_<Alias_nach> _ [x] _FK Falls mehrere benötigt werden => durchnummerieren Unique Key <Alias> _UK Bei einem Unique-Key Unique Key <Alias> _ [x] _UK Falls mehrere benötigt werden => durchnummerieren Check Constraint <Alias> _CHK Bei einem Check Constraint Check Constraint <Alias> _ [x] _CHK Bei mehreren Index <Alias> _I Bei einem Index Index <Alias> _ [x] _I Falls mehrere benötigt werden => durchnummerieren DB-Trigger <Alias> _[A B] [R S] [<I> <U> <D>] A After; B Before R Row; S Statement I Insert; U Update; D Delete OPITZ CONSULTING GmbH Seite 17

18 Namenskonventionen (Forms) Forms-Objekte Objekt Blöcke Alert Canvas Editor Frame LOV Object Group Parameter Popup Menu Property Class Record Group Visual Attribute (Common) Visual Attribute (Prompt) Visual Attribute (Title) Window User Named Trigger Präfix Kein Präfix, sprechender Name AL_ CN_ ED_ FR_ LV_ OG_ PA_ PM_ PC_ RG_ VA_ VP_ VT_ WN_ UN_ OPITZ CONSULTING GmbH Seite 18

19 Namenskonventionen (Forms) Item-Typen Bean Area Button Button-LOV Checkbox Chart Item Display Item Hierarchical Tree Image List Item OLE-Container Radio Group Radio Button Sound Text Item User Area Objekt BA_ BT_ BT_LV_ CB_ CI_ DI_ HT_ IM_ LI_ OC_ RA_ RB_ SO_ TI_ UA_ Präfix OPITZ CONSULTING GmbH Seite 19

20 Namenskonventionen (PL/SQL) PL/SQL-Präfixe Objekt Notation Constant Variable Cursor Parameter Recordvariable Typ Variable C_ Cur_ P_ R_ T_ V_ OPITZ CONSULTING GmbH Seite 20

21 Sourcecode-Layout 1. Einrückung z.b. 2 Leerzeichen pro Ebene und niemals Tabs 2. Groß / Kleinschreibung Reservierte Worte werden groß geschrieben, alle anderen Worte Initcap 3. Leerzeichen bei Parameterübergabe Vor jeder Klammer und hinter jedem Komma ein Leerzeichen Vor und hinter jeder Zuweisung ein Leerzeichen 4. Aliasnutzung beim Select auf mehrere Tabellen Wenn in einem Select die FROM-Clause mehr als eine Tabelle benutzt, sollte jede Tabelle mit einem Alias versehen werden. Aliase wie im Kapitel Interne Benamungen in der DB 5. OPITZ CONSULTING GmbH Seite 21

22 Sourcecode-Formatierung Alle relevanten Strukturen in PL/SQL sollten definiert werden SELECT Auftrag_Nr, Datum FROM Auftraege WHERE Auftrag_ID = V_Auftrag_ID AND Datum > SYSDATE 10 ORDER BY Auftrag_Nr; UPDATE Auftraege SET Kunden_Name = 'Müller' WHERE AUFT_ID = V_AUFT_ID; DELETE FROM Positionen WHERE Datum < Sysdate 180; INSERT INTO Positionen (POSI_ID, AUFT_ID, Position_Nr, Datum, Anzahl, Wert) VALUES (V_POSI_ID, V_AUFT_ID, 1, SYSDATE, 17, 12.50); OPITZ CONSULTING GmbH Seite 22

23 Exception-Handling In jeder Routine muss am Ende ein Exception-Handling geschrieben werden. Beispiel: EXCEPTION WHEN <Exception> THEN Statement1; END; WHEN OTHERS THEN Statement2; OPITZ CONSULTING GmbH Seite 23

24 Kommentare (1) 1. Ein effektiver Code-Stil hat zum Ziel, verständlichen, produktiven und wartbaren Code zu erzeugen. Die meisten Programme profitieren von den im Programm dokumentierten Kommentaren und Erklärungen. 2. Diese Kommentare erhöhen die Lesbarkeit des Source- Codes enorm. Entwickler, die den Source-Code in der Wartungsphase das erste Mal zu sehen bekommen, haben meist keine Chance, den Code zu verstehen, ohne eine gute Inline-Dokumentation. OPITZ CONSULTING GmbH Seite 24

25 Kommentare (2) 1. Tipps zum Schreiben von Kommentaren Schreibe Source-Code geradeaus und ohne Tricks und Kniffe (egal, wie gut diese dokumentiert sind) Variablen, Module und andere Namen bekommen sprechende Namen (egal, wie lang sie sind) Nutze immer Konstanten statt Literale (sowohl als Übergabewerte, wie auch als Vergleichswerte oder an anderen Stellen) Arbeite immer mit den gleichen, sauberen und durchgängigen Sourcecode- Layout-Regeln Kommentiere den Source-Code während Du ihn schreibst. OPITZ CONSULTING GmbH Seite 25

26 Templates + Vererbungsstrategien OPITZ CONSULTING GmbH Seite 26

27 Templates frw_ref frw_lib frw_template Applikation OPITZ CONSULTING GmbH Seite 27

28 Templates kontinuierlich weiterentwickeln Templates sind in Funktion und Anzahl nicht begrenzt Im Projektverlauf macht es Sinn kontinuierlich weitere Templates zu erzeugen, die vielleicht erst später benötigt werden Tree-Templates Shuttle-Templates OPITZ CONSULTING GmbH Seite 28

29 Vererbungsstrategie Beispiel eines Referenz- Templates mit den wichtigsten Property- Klassen, Visual Attributes uvm. OPITZ CONSULTING GmbH Seite 29

30 Library Integration und PLL- vs. PLX-Nutzung Reihenfolge, in der Forms seine Libraries nutzt: frw_lib.plx im Arbeitsverzeichnis frw_lib.plx im FORMS_PATH frw_lib.pll im Arbeitsverzeichnis frw_lib.pll im FORMS_PATH Ansonsten Fehlermeldung Gleiches gilt für Forms und Menüs OPITZ CONSULTING GmbH Seite 30

31 Konstantenpackages Zentrales Konstantenpackage PACKAGE Const Lokales Konstantenpackage PACKAGE Const_local OPITZ CONSULTING GmbH Seite 31

32 Konstantenpackage Const PACKAGE Const IS -- Alerts alr_error CONSTANT VARCHAR2 (30) := 'AL_ERROR'; alr_info CONSTANT VARCHAR2 (30) := 'AL_INFO'; alr_warning CONSTANT VARCHAR2 (30) := 'AL_WARNING'; -- Block, Record and Form-Status sta_changed CONSTANT VARCHAR2 (10) := 'CHANGED'; sta_insert CONSTANT VARCHAR2 (10) := 'INSERT'; sta_new CONSTANT VARCHAR2 (10) := 'NEW'; sta_query CONSTANT VARCHAR2 (10) := 'QUERY'; -- Other CR CONSTANT VARCHAR2 (1) := CHR (10); Tab CONSTANT VARCHAR2 (1) := CHR (9); TRUE CONSTANT VARCHAR2 (10) := 'TRUE'; FALSE CONSTANT VARCHAR2 (10) := 'FALSE'; END Const; OPITZ CONSULTING GmbH Seite 32

33 Hilfsfunktionen (1) Nachricht als Alert ausgeben PROCEDURE Info Parameter: P_Text IN VARCHAR2 Nachricht + Raise Form_Trigger_Failure PROCEDURE Raise_Info Parameter: P_Text IN VARCHAR2 OPITZ CONSULTING GmbH Seite 33

34 Hilfsfunktionen (2) Rückfrage stellen FUNCTION Question Parameter: P_Text IN VARCHAR2 Rückgabewert: NUMBER OPITZ CONSULTING GmbH Seite 34

35 Hilfsfunktionen (3) Deutscher Wochentag ermitteln FUNCTION German_Weekday Parameter: P_Date IN DATE Rückgabewert: NUMBER OPITZ CONSULTING GmbH Seite 35

36 Demos OPITZ CONSULTING GmbH Seite 36

37 One Time Timer OPITZ CONSULTING GmbH Seite 37

38 Undo OPITZ CONSULTING GmbH Seite 38

39 Multi LOV OPITZ CONSULTING GmbH Seite 39

40 Generische List-Items OPITZ CONSULTING GmbH Seite 40

41 LOV's mit gruppierten Daten OPITZ CONSULTING GmbH Seite 41

42 BI Beans OPITZ CONSULTING GmbH Seite 42

43 Ihr Ansprechpartner Gerd Volberg Solution Architect OPITZ CONSULTING Deutschland GmbH Kirchstr. 6, Gummersbach Tel. +49 (2261) talk2gerd.blogspot.com OPITZ CONSULTING GmbH Seite 43