FAQ Page: Repository Design Pattern

Das Repository gehört zur „Daten“-Schicht (Data Layer). Die Use-Cases arbeiten mit Interfaces, die über Dependency Injection mit konkreten Repository-Implementierungen versorgt werden. Damit bleibt die Logik unabhängig von der Hardware.

Ein Sensor-Repository könnte eine Schnittstelle bieten wie: Die Implementierung könnte die Daten direkt vom Sensor abfragen oder aus einem Cache lesen.

Die Geschäftslogik arbeitet nur mit der Repository-Schnittstelle und kennt die konkrete Implementierung nicht. Das bedeutet, dass du z. B. zwischen EEPROM, SD-Karte oder RAM wechseln kannst, ohne die Logik anzupassen.

Du kannst test-spezifische Implementierungen des Repository-Interfaces schreiben, die z. B. Daten in einem RAM-Puffer speichern. Das ermöglicht Unit-Tests ohne tatsächliche Hardware.

Die Repositories können statisch angelegt werden. Statt new/delete verwendet man z. B. statisch allozierte Objekte und übergibt Referenzen oder Zeiger. Es ist wichtig, dass keine dynamische Allokation in der Repository-Implementierung verwendet wird.

In C++ kann man Interfaces (reine virtuelle Klassen) verwenden:

In C implementierst du das Pattern meist mit einer strukturierten Funktionsschnittstelle und Funktionszeigern:

Vorteile: Nachteile:

Es wird verwendet, um die Datenzugriffsschicht von der Geschäftslogik zu trennen. In Embedded-Systemen kann es helfen, Hardwarezugriffe zu kapseln und testbar zu machen.

Das Repository Pattern ist ein Entwurfsmuster, das den Zugriff auf Daten von der restlichen Anwendung abstrahiert. Es stellt eine Schnittstelle bereit, über die Daten gelesen oder gespeichert werden können, ohne dass der Aufrufer wissen muss, wie oder wo die Daten gespeichert sind (z. B. Flash, EEPROM, RAM, Datei, etc.).