ADF Strukturierung – Best Practices

Immer und immer wieder sehe ich Kunden-Projekt in denen eine ADF-Projektstruktur erstellt wurde, die 1:1 aus dem  Jdeveloper Standard-Wizard generiert wurde.
Problematisch daran  ist, dass diese Struktur sich weder für Wiederverwendung noch konkurrierende Programmierung eignet. Als Regel gilt  in unseren  Projekten deshalb  immer:

  • Es es existiert auf oberster Ebene  immer ein ADF- Framework Projekt für das ADF-Model und die ADF-UI. Das ADFModeCommon Projekt enthält die  Basisfunktionalität des Modells wie Protokollierung, VPD Anmedlung usw.  des ADF Models. Das ADFUICommon Projekt enthält die Basisklassen der Oberfläche wie z.B. Internationalisierung, Help-Einbindung usw.
  • Die EntityObjekte und Associationen werden in einem eigenen Projekt, getrennt von AppModule und ViewObjects gespeichert. Die Strukturierung und Anzahl der Projekte erfolgt durch Vorgabe der  fachlichen Domänen.
    Beispiel: Entities der Versicherungsdomäne Vertrag oder Partner werden jeweils in eigenen Entity-Projekten verwaltet. Die Anlage von Association über die Grenze einer Fachdomäne sollte soweit wie möglich vermieden werden (Kopplungsgrad).
  • ViewObjects gelten als Objektschnittstellen zu den Fachanwendungen und sollten deshalb die identische  Projektgranularität aufweisen. Es wird jedoch erst ein ViewObjet angelegt, wenn es wirklich gebraucht wird und niemals der Wizard zur Default-Gernerierung (1:1 zu Entities)   verwendet werden – erzeugt zu viel Objekte, die danach verwaltet werden müssen. Die Funktion der View-Object Vererbung ist hier ein ganz wichtiges Feature, um tatsächlich Wiederverwendung zu gewährleisten und die  wiederholte Definition aller Attribute zu vermeiden.
  • Die Nameskonvention der  Wizards sind  sehr technisch und sollte immer überschrieben werden:
    • Entity Objekte werden immer wie das fachliche Geschäftsobjekt, ohne dem Anhang Entity, benannt und unter demSub- Package bo abgelegt  (Beispiel: de.mycompany.mode.bo.customer.Address)
    • View Objecte werden ebenfalls  fachliche getrieben , ohne dem Anhang View,  benannt und unter demSub- Package vo abgelegt  (Beispiel: de.mycompany.mode.vo.customer.CustomerAddress)
    • Bei der Namesvergabe der  Entity Associations sind verwende ich immer die Konvention BaseObject2DestinationObjectAccociation. Eine strikte Regel kann aufgrund der unterschiedlichen  Kardinalitätsmöglichkeiten und Eindutigkeit innerhalb einem Projekt  nicht geben.    Zudem müssen die Asscciationen nach der Anlage durch den Refactor-Wizard verschoben und umbenannt werden.
    • Für ViewLinks sind die identischen Regeln wie bei den Associations anzuwenden. einziger Unterschied ist, dass sie im Sub-Package der VO abgelegt und mit dem Nameszusatzs Link angelegt werden.
    • ApplicationsModules ist für die meisten ein nicht aussagekräftiger Begriff. Ich verwende deshalb stets den Begriff und Strukturierungsmerkmal Component oder Service. Zu Components(AppModule)  werden alle wiederverwendbare kleine Einheiten. Den Begriff Service verwende ich für AppModule dann, wenn ein Service nach außen sichtbar und damit öffentlich wird. Beispiel:  OrderManagementService, OrderComponent, CustomerComponent, usw.

Advertisements

~ von bmaier - 29. 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: