Inhaltsanbieter vs direkten Datenbankzugriff (Transaktionsverwaltung)

Question

Ich verstehe, zumindest auf dem Papier, den grundlegenden Unterschied zwischen dem Content Provider und direkt auf die SQLiteDatabase zugreifen. Ich habe einen funktionierenden Prototyp für meine Anwendung, und momentan ist es nur direkt in der Datenbank. Ich habe keine Erfahrung mit dem Content-Provider-Muster, aber ich habe herausgefunden, dass ich einige Daten mit einer anderen Anwendung teilen muss.

Ich werde nur etwa 2 von einem Dutzend oder so Tabellen teilen, also habe ich mich gefragt, ob ich gerade die Datenschicht vollständig dem Content Provider-Muster folgen oder nur diese Tabellen nur über einen Content Provider verfügbar machen sollte aus Gründen der anderen Anwendung und immer noch direkt auf die Datenbank in der primären Anwendung zugreifen.

Eines der Probleme, die ich mit meinem Prototyp hatte, war, dass ich einige ziemlich komplexe Transaktionen habe und der Code, den ich geschrieben habe, ist nicht besonders gut und nicht wiederverwendbar. Da ich dieser App mehr Funktionalität hinzufüge, brauche ich eine besser gestaltete Datenzugriffsschicht, bevor ich meine eigene schreibe. Weiß jemand schon irgendwelche guten Ressourcen mit Entwurfsmustern für diese Art von Dingen? Muss ich, wenn ich die Route des Content Providers durchlaufen muss, auch die Datenbanktransaktionen kontrollieren?

Answer 1

Ich glaube nicht, dass Sie ein Problem haben sollten, nur einen Inhaltsanbieter mit der Funktionalität, die Sie benötigen, die auf Ihrem direkten Datenbankcode sitzt. Ein Inhaltsanbieter ist eigentlich nur eine Abstraktion für den Zugriff auf strukturierte Daten, die SQLite sehr ähnlich sieht. :) Wenn verschiedene interne Teile der App direkt auf die gleiche Datenbank wie der Provider zugreifen, solange der Code der beiden gut zusammenspielt, sollte es in Ordnung sein.

Ich bin eigentlich kein Fan davon, absolut zu sein, "du musst immer Inhaltsanbieter verwenden." Wenn Sie keinen Inhaltsanbieter benötigen, verwenden Sie keinen; Wenn es einfacher ist, führen Sie SQLite aus. Wenn Sie einen Content-Provider für eine bestimmte Interaktion mit anderen Apps benötigen, können Sie einen einfach dafür schreiben, ohne dass es zu einer komplizierten Sache wird, die all das unterstützt, was Ihre App intern mit der Datenbank macht. Wenn das einfacher ist, großartig. Es ist auch viel weniger wahrscheinlich, dass Sie unbeabsichtigt private Daten von Ihrer App für andere freigeben.

Answer 2

Zitieren Sie mich nicht, aber ich bin mir ziemlich sicher, dass ein Inhaltsanbieter eine Möglichkeit bietet, die Art und Weise zu abstrahieren, wie Sie einem Objekt Daten bereitstellen. Auf diese Weise kann Ihr Objekt nur mit dem Anbieter kommunizieren und kümmert sich nicht um die Implementierung, d. H. Wie/wo die Daten gespeichert sind. Vielleicht möchten Sie in Zukunft eine andere Möglichkeit zum Speichern Ihrer Daten bereitstellen, und die Verwendung des Content-Provider-Paradigmas spart Ihnen jede Menge Nacharbeit, da es sich nur um eine schnittstellenbasierte Kommunikation handelt.

Ich würde die Android-Design-Muster verwenden, wo immer ich konnte. Um ehrlich zu sein, wenn ich es jetzt ansehe, sollte ich das wirklich in meinem Projekt machen.