Repository bei Room-Database in Android Studio (Java)

[mrkennedie89]

Hallo zusammen,

ich bin noch relativ neu bei der Programmierung mit Java und Android Studio. Nun habe ich einige Verständnisprobleme was die Repository Klasse und generell den dort enthaltenen Codeausführungen betrifft.
Es geht um eine App mit einer Datenbank. Das DAO-Interface, die DataBase-Klasse und die Entity mit einem Table sind bereits implementiert.

Die Datenbank-Klasse:

@Database(entities = {NoteEntity.class}, version = 1)
public abstract class NotesDataBase extends RoomDatabase {

    public abstract DAO_Note daoNote();

    private static NotesDataBase instance;

    public static synchronized NotesDataBase getInstance(Context context) {

        if (instance == null) {
            instance = Room.databaseBuilder(context.getApplicationContext(), NotesDataBase.class, "notedata_base").fallbackToDestructiveMigration()
                    .build();
        }

        return instance;
    }
}

Der Codeausschnitt aus der Repository-Klasse sieht wie folgt aus:

public class Repository {

    private DAO_Note daoNote;
    private LiveData<List<NoteEntity>> notes;

    public Repository(Application application) {
        NotesDataBase notesDataBase = NotesDataBase.getInstance(application);
        daoNote = notesDataBase.daoNote();
        notes = daoNote.getAllNotes();
    }
   
    ....
    
    public LiveData<List<NoteEntity>> getAllNotes() {
               return notes;
            }

}

Es sind leider gleich mehrere Sachen die ich irgendwie nicht so ganz nachvollziehen kann:

- Warum wird in der Datenbank-Klasse eine abstrakte Methode angelegt, die ein DAO-Objekt zurückliefern soll? Dieses zurückgelieferte
DAO-Objekt wird ja offensichtlich später der Variablen daoNote im Konstruktor der Repository zugewiesen.

- Warum wird im Konstruktor von Repository notes = daoNote.getAllNotes(); zugewiesen?
und später nocheinmal public LiveData<List<Note>> getAllNotes()...?

- Wozu wird sowohl bei der DataBase als auch bei der Repository das Übergabeparameter Application application verwendet?


Irgendwie verstehe ich den gesamten Zusammenhang zwischen DAO, Database, Repository, ViewModel und LiveData nicht?
Kann ich mir das so vorstellen, dass das DAO dazu verwendet wird, um auf Datenbankeinträge überhaupt zuzugreifen. Dann werden die Daten
von der Datenbank an das Repository gereicht. Von dort wiederum an das ViewModel.

Kann man sagen, dass das Repository für das ViewModel die gleiche Funktion erfüllt, wie das DAO-Interface für die Repository?

Was ich technisch auch nicht wirklich verstehe, warum ein Objekt der Klasse Repository später im Konstruktor des ViewModels erzeugt wird
und nicht einfach innerhalb der Klasse, sowie wenn man in Java in der Main einfach ein Objekt einer anderen Klasse erzeugt?

public NoteViewModel(@NonNull Application application) {
        super(application);

        repository = new NoteRepository(application);
        notes = repository.getAllNotes();

    }

Ich weiß es ist ein langer Text und durcheinander. Bin aber für jegliche Tipps und Hilfe dankbar.

 

[Jw456]

Eigentlich hast du bei Room zwei Interfase Klassen.
Ein DAO und eins was von DataSourceInterface erbt.

Das Repository sollte auch das DataSourceInterface implementieren.
Was du nicht machst.

Schaue mal hier vielleicht hilft das.

Room Datenbank - App-Daten in einem Datenbank-Format einfacher speichern - ard

Room ist eine Persistence Library, die einen abstrakten Layer über SQLite zur Verfügung stellt. Damit ist ein einfacher und sicherer Zugriff möglich, ohne auf die Funktion von SQLite zu verzichten. In diesem Tutorial wird eine Einführung, wie man die Datenbank erstellt und Daten von der...

ard-site.net

Was ich technisch auch nicht wirklich verstehe, warum ein Objekt der Klasse Repository später im Konstruktor des ViewModels erzeugt wird
und nicht einfach innerhalb der Klasse, sowie wenn man in Java in der Main einfach ein Objekt einer anderen Klasse erzeugt?

Das ViewModel ist ja deine Daten Klasse die entweder an dem Fragment hängt oder direkt an der Activity also solange lebt wie die Activity. Schaue dir mal den Lifecycle an.
Das viewmodel will oder soll ja mit der DB arbeiten.
Das ViewModel dient zur Trennung von GUI und Programm Code.

Model, View, ViewModel (MVVM)
Ein anderes in Android nicht so übliches Pattern Prinzip ist MVC Model, View, Controler.

Frage nach welchen Tutorial bist du vorgegangen?

 

[M.L.]

Auf rein formeller Ebene erzwingt die Verwendung von "abstract" die Vererbung einer Klasse oder die konkrete Implementierung (wenigstens) einer abstrakten Methode.
Was die Konstruktion an sich (MVC, MVVM,...) angeht: es sind aus der SW-Architektur bekannte Verfahren, die (häufige(re)) Änderungen oder Erweiterungen an einer (zentralen) Stelle erleichtern.