Android: ORM für Modell in JAR

Question

Ich habe eine Jar-Datei, in der ich eine Reihe von (normalen/nicht annotierten) Klassen, die das Modell meiner Android-Anwendung definieren werden. Ich habe das Glas bereits als neues JAR-Modul in die Anwendung importiert und kann es problemlos in der Android-App verwenden.

Gibt es ein ORM-Framework für Android, das in der Lage ist, die Klassen in der JAR-Datei zu berücksichtigen und daraus sowohl die DB als auch die DAO/DAL zu erstellen?

Ich habe über GreenDAO gelesen, aber ich habe verstanden, dass es umgekehrt funktioniert: aus den Spezifikationen erstellt es sowohl DB als auch die Modellklassen.

BTW, ist es gut, einem solchen In-Memory-Ansatz für eine einfache App zu folgen, wo es höchstens 5 Klassen im Modell gibt? Wenn nicht, gibt es einen Best-Practice-Weg, um die Geschäftslogik vom DB-Zugriff und dem Rest der Android-App zu trennen?

Vielen Dank!

Answer 1

Ja derzeit gibt es. Werfen Sie einen Blick auf JuhakuDb: https://github.com/juhaku/juhakudb.

Diese Android-Bibliothek liest Klassen aus dem Klassenpfad und erstellt eine Datenbank für sie. Außerdem bietet es eine Gerenal Dao-Implementierung, die einfach implementiert werden kann.

Es verwendet Androids eigenen SPI, um auf die Datenbank zuzugreifen und Abfragen durchzuführen, so dass es ab der ersten API-Ebene funktioniert, auf der die Datenbank in Android-Geräten unterstützt wurde.

Ebenso Konfiguration, die Bibliothek zu verwenden ist fast Null. Nur Java-Konfiguration ist erforderlich und es dauert nur etwa 10 Zeilen Code.

Die Verwendung erinnert wirklich an Hibernate, SpringDATA und JPA. Also, wenn Sie mit ihnen vertraut sind, dann sollte dies keine große Sache sein.

Als zweite Frage zu beantworten.

Es hängt wirklich von Ihrem Anwendungsfall der Anwendung ab. Wenn Sie Ihre Daten vor dem Schließen der Anwendung nicht persistieren müssen und immer von vorne anfangen können, ist In-Memory in Ordnung. Das Verwalten mehrerer Listen und Objekte im Arbeitsspeicher kann jedoch problematisch sein, insbesondere wenn Ihre Anwendung wächst.

Es gibt jedoch Möglichkeiten, um Daten für die Anwendung in der Nähe zu halten, wie gemeinsame Präferenzen zu verwenden. Der speichert es auch in der Datenbank. Oder speichern Sie Daten im Dateisystem und lesen Sie sie von dort.

Aber die Verwendung der Datenbank ist keine schlechte Idee. Und es kann auch als Cache für Online-Lesedaten verwendet werden. Normalerweise sind die Operationen für die Datenbank schnell und es ist eine gute Möglichkeit, Daten zu speichern. Zum Beispiel ist das Verwalten von 4 separaten Karten oder das Verwalten von 4 Karten, die ineinander im Speicher sind, manchmal etwas frustrierend. Datenbanken bietet eine strukturierte Möglichkeit zum Speichern von Daten und Holen von Objekten mit verwandten Objekten ist einfach, insbesondere mit JuhakuDb-Bibliothek.

Es gibt einige Möglichkeiten, die Geschäftslogik vom Datenbankzugriff und/oder von gui zu trennen. Es könnte separate Klassen geben, die verschiedene Suchkriterien für Datenbanken bereitstellen, und diese werden für Repositories verwendet. Und Repositories könnten Aktivitäten hinzugefügt werden. Oder es könnte eine fassadenähnliche Klasse geben, die Zugriffe auf alle Repositories bietet und alle Abfragen durch sie ausgeführt werden. Dann würde diese fassadenähnliche Klasse zu allen Aktivitäten oder anderen Klassen hinzugefügt, die Zugriff auf die Datenbank benötigen.

Desings sind mehrfach. Aber Fassadenmuster und oder MVC-Muster könnten verwendet werden. Natürlich gibt es in Android keinen MVC.Aber um es bildlich darzustellen, könnte Aktivität oder Fragment der Controller sein. Ansicht ist das Layout. Und Modelle sind die Modellklassen. Der Controller kann dann Logik haben und ruft das Repository auf, um Elemente zu speichern oder zu löschen oder abzufragen. Dann wird das Repository die Restlogik mit der Datenbank ausführen. Also wäre das Muster wie MVCR.

Glückliche Kodierung. Hoffe, das macht Sinn.