ADF Projekt – Best Practice

Immer wieder werde ich gefragt wie wir von Oracle Consultant ADF-Projekte richtig aufsetzen. Leider ist es bei ADF wie überall in der Softwareentwicklung: die Anforderungen legen die Architektur und das Vorgehen fest und nicht das Framework. Ich möchte deshalb in einer kleinen Blog-Folge eine paar Ansätze diskutieren, die den Interessierten eine kleine Orientierungshilfe geben. Dabei will ich nur auf rein architektonische und technische Aspekte und nicht auf die in unseren Projekten meist verwendete Methode OUM (Oracle Unified Method) eingehen.

Im IT-Umfeld setzt sich ja vermehrt die Erkenntnis durch, dass die traditionellen Monster-Anwendungen und ihre enge Kopplung langfristig einem Unternehmen mehr schaden als sie nützen. Betroffen sind dabei nicht nur alte Cobol oder PL-SQL Anwendungen, sonder vor allem auch J2EE Anwendungen, die traditionelle Aufgaben wie Master Data Management, Identity- und AccessManagement, Reporting usw. immer wieder monolithisch neu implementieren. Ich plädiere deshalb dafür sich bei einer Neuimplementierung nur auf die Kernaufgaben zu konzentrieren und klare fachliche und technische Domänen auf Grundlage des Domain Driven Developments (DDD) zu bilden.

Lose Kopplung klare Schnittstellen und übergreifende Zusammenarbeit (Collaboration) der Softwarebausteine (Building Blocks) ist also ein muss beim Design einer Anwendung.

Und nun zu ADF. ADF mit alle seinen Sub-Frameworks biete viele Möglichkeiten Digen richtig order auch falsch zu machen. Deshalb treffen wir zuerst ein paar Vorentscheidungen, bevor wir beginnen:

1.) Die Daten und deren Qualität sind oft das wertvollste einer Anwendung, weshalb die Datenbank nicht automatisiert aus den Java-Objekten (EntityObject) generiert werden, sondern von einem erfahrenen Datenbankdesigner erstellt werden. Der DB-Designer sollte natürlich auch das ER-Modell mit einem grafischen Tool wie z.B. MID-Innovator Data erstellen und beim Einsatz des MDA/MDSD-Generators die Templates mit angepassten Designentscheidungen (physisches DB Design) bereitstellen. 

1.1) In der Anwendungsdatenbank sollten keine Masterdaten (Bundesländer, Kunden, Organisationseinheiten) gehalten werden und diese alleinig über eindeutige Schlüssel (GUID) logisch referenziert werden – hier existiert kein DB-Constraint (Ausnahmen durch programmatische CheckConstraint z.B. in einer PLSQL-Funktion).

1.2) Als Objekt-Schlüssel (Primary-Key) werden stets nichtsprechende eindeutige IDs (GUID) verwendet.

1.3) Constraints außerhalb der Fachdomäne werden über die Business-Logik abgehandelt und nicht durch native Datenbankmittel wie CheckConstraints (ALTER TABLE table_name enable CONSTRAINT constraint_name;)

1.4) Die letzte Änderung eines Datensatzes wird je Tabelle durch zwei Change-Indikator Felder (Zeit + Benutzer aus LoginContext) gekennzeichnet.

1.5) Historisierung in einer relationalen OLTP-Anwendung lässt sich nur mit hohem Aufwand realisieren und ist soweit wie möglich vermeiden. Bei einer Anforderung zur Nachvollziehbarkeit wird das Prinzip der zentralen ChangeHistoryTabelle mit eingeführt. Notwendige Columns: Zeitpunkt, Benutzername, alter Wert, neuer Wert.  Aus Performanzgründen muss ein zyklischer Bereinigungslauf vorhanden sein und die angefallenen Alt-Daten archivieren. 

1.6) Die Datenbank sollte mindestens die Normalisierungsstufe  aufweisen, bevor man beginnt die Entity-Objekte zu erstellen. Ein Refactoring ist heute zwar per Jdeveloper möglich, verursacht jedoch einen riesen Aufwand.

1.7) Ein EntityObject basiert immer auf einer  Tabelle und nicht auf einer DB-View. Ausnahmen mit einer 1:1 View sind möglich; es ist jedoch zu Bedenken, dass hier oft Seiteneffekte mit dem ADF-Cache auftreten.   

 

Die Liste werde ich in dem Blog die nächsten Monate fortsetzen!

Advertisements

~ von bmaier - 30. Juli 2010.

Kommentar verfassen

Bitte logge dich mit einer dieser Methoden ein, um deinen Kommentar zu veröffentlichen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

 
%d Bloggern gefällt das: