Auf dem Weg vom Ausgangspunkt - einem Framework mit persistentem Objekt-Datenquellen-Mapping - hin zum gewünschten Soll-Zustand - die Erweiterung hinsichtlich genannter Werkzeuge zur Versionskontrolle - ist die erste relevante Fragestellung jene nach der Ebene, in der strukturell angesetzt wird. Die Wahl des Schnittstellenumfangs und die anschließende Definition der darin enthaltenen Methoden bilden das nächste Kriterium, bevor (auch) damit verbundene Detailfragen, wie implizites Verhalten, oder die Versionskontrolle für Relationen, besprochen werden können. Weiters gilt bereits in der Planungs- und Designphase zu entscheiden, welche Granularität erreicht werden soll und welche Funktionen auf die einzelnen Elemente im System anwendbar sein müssen.

Ebene der Integration

Prinzipiell sind hier folgende Ansätze denkbar:

1. Datenkomponente
   Auf dieser Ebene kann direkt in und mit der zugrundeliegenden Repository-Technologie gearbeitet werden, im Standardfall wäre dies z.B. eine MySQL-Datenbank.
   • Vorteile: Performance (Funktionalität auf Basis der zugrundeliegenden Technologie, z.B. SQL), Kapselung innerhalb der Datenkomponente
   • Nachteile: (mangelnde) Modularität, Komplexität der Datenkomponente, nicht unabhängig von Datenquelle
2. Versionskomponente (Subklasse von Datenkomponente)
   Verwendung der Datenkomponente als Basisklasse für eine Versionskomponente, welche ein entsprechendes zusätzliches Interface für Versionskontrolle implementiert und ggf. Methoden der Basisklassen überschreibt.
   • Vorteile: Modularität, Transparenz
   • Nachteile: evtl. notwendig, Großteil der Basisklasse zu überschreiben (=Redundanz), evtl. Teile nur in PHP implementierbar (=schlechtere Performance), außerdem nicht von Datenquelle unabhängig
3. Versionskomponente (eigenständig)
   Interface für Datenkomponente wird verwendet, um auf Basis dessen die Funktionalität einer Versionskontrolle (in der Framework-Sprache) zu implementieren.
   • Vorteile: Modularität, Transparenz, Wiederverwendbarkeit (unabhängig von Datenquelle)
   • Nachteile: Performance (Implementierung rein in der Framework-Sprache)

Schnittstellenumfang und -definition

Je nach Ebene des Ansatzes sind verschieden breite Schnittstellen denkbar. Bei der direkten Integration in eine Datenkomponente sollte auf ein minimales Interface geachtet werden, sonst könnte die Komponente unnötige Komplexität erhalten. Externe Komponenten können/sollen die darin definierten (performanten) Methoden verwenden, um ein umfangreiches, komfortables und dabei möglichst effizientes System zu implementieren.

Bei der Auslagerung in eine abgeleitete Klasse oder einer Client-Klasse, welche die Datenkomponente über ihr Interface anspricht, sind komplexere, vollständigere Schnittstellen ggf. empfehlenswert, um keine weiteren, darauf aufbauenden Klassen zu benötigen, dh. um die aufgebaute Hierarchie flacher zu halten.

Detailfragen: Implizites Verhalten, Relationen,...

Unabhängig von obigen Entscheidungen ergeben sich aufgrund der angestellten Überlegungen weitere Fragestellungen:

• Implizites Verhalten: Automatische Erstellung von Revisionen bei Update auf Objekt, Löschen aller Revisionen beim Löschen eines Objektes, Abhängigkeit des Verhaltens von Konfiguration oder Parametern bzw. Typen?
• Verhalten bei Relationen: Intuitiv: Relationen werden wie Datenelemente behandelt (bedeutet evtl. komplexere User-Interfaces); Alternativ: Relationen von Versionskontrolle ausnehmen
• Granularität: Intuitiv: Versionskontrolle auf Objektebene, Revisionen für vollständige Objekte; Alternativ: Member-Ebene, Revisionen für einzelne Datenelemente der Objekte (höhere Flexibilität und Granularität, aber deutlich höhere Komplexität auch in der Anwendung und im Interface)

Skizze eines möglichen Designs

• Datenkomponente integriert und implementiert notwendiges (minimales) Interface (minimiert Nachteile der erhöhten Komplexität der Komponente und des Entwicklungsaufwandes bei Migration neuer Datenquellen, maximiert Performance und bietet gute Flexibilität).
• Darauf setzt eine Versionskomponente auf, welche das zur Verfügung stehende Interface verwendet, um komplexere Methoden für eine breiter und einfacher verwendbare Schnittstelle zu implementieren. Drittkomponenten verwenden dieses Interface, dadurch einfache Verwendung bei guter Performance, Flexibilität durch die Möglichkeit, verschiedene solcher Interfaces für unterschiedliche Zwecke (z.B. Objekttypen) zu definieren.
• Kritik: Der in der Datenkomponente integrierte Teil ist nicht für beliebige Datenquellen wiederverwendbar. Dieser Nachteil lässt sich durch Verwendung von Adaptern (z.B. eine Datenkomponente für viele DBMS über DB-Adapter) relativieren. Zudem würde eine vollständige Abstraktion von der zugrundeliegenden Datenquelle Manipulationen u.a. an den Typdefinitionen für Objekte bedingen.