WEBVTT 00:00.080 --> 00:07.730 Der zweite Schritt bei der Erstellung unserer Datenbank besteht darin, dem Singleton-Muster zu folgen, um eine Instanz während des Lebenszyklus 00:07.730 --> 00:09.980 der Anwendung bereitzustellen. 00:10.010 --> 00:17.900 Eine Datenbankinstanz kann ressourcenintensiv sein, und die Erstellung mehrerer Instanzen der Datenbank verbraucht 00:17.900 --> 00:21.110 unnötig Speicher und Rechenleistung. 00:21.140 --> 00:29.030 Ein Singleton stellt sicher, dass während des gesamten Lebenszyklus der Anwendung nur eine Instanz der Datenbank existiert, 00:29.030 --> 00:31.880 was die Ressourcennutzung optimiert. 00:31.880 --> 00:39.740 Dafür erstelle ich eine private statische Instanz aus dieser Kontaktdatenbank und nenne sie 00:39.740 --> 00:41.660 Instanz DB-Instanz. 00:41.660 --> 00:43.850 Ich möchte, dass Sie sich mit mir zusammen konzentrieren. 00:43.850 --> 00:51.680 Ich werde ein Singleton-Designmuster in Java implementieren, um eine einzige Instanz während des Lebenszyklus der Anwendung bereitzustellen, 00:51.680 --> 00:59.150 um die Ressourcennutzung zu optimieren und die Erstellung mehrerer Instanzen der Datenbank zu vermeiden. 00:59.150 --> 01:05.750 Öffentliche statische synchronisierte Kontakt-Datenbank und Get-Instanz. 01:05.750 --> 01:11.330 Diese Methode wird verwendet, um eine Kontaktdatenbank zu erstellen, wenn es kalt ist. 01:11.330 --> 01:18.020 Ich übergebe den Kontext als Parameter für diese Methode und beginne hier mit dem Schreiben des Codes. 01:18.020 --> 01:25.730 Ich muss prüfen, ob es eine vorhandene Instanz der Datenbank während des Lebenszyklus der Anwendung gibt, dann werde ich 01:25.730 --> 01:27.080 sie bereitstellen. 01:27.080 --> 01:31.580 Andernfalls werde ich eine neue Instanz der Raumdatenbank anlegen. 01:31.580 --> 01:39.920 Also, wenn Instanz diese DB-Instanz gleich null ist, so gibt es keine Instanz der Datenbank. 01:39.920 --> 01:42.800 Ich muss eine neue Rauminstanz erstellen. 01:42.800 --> 01:52.640 So db Instanz gleich Raum Punkt Datenbank Builder und innerhalb dieser Builder-Methode muss ich den Kontext Punkt übergeben, erhalten 01:52.640 --> 01:56.870 Anwendungskontext als der erste Parameter. 01:56.900 --> 02:02.700 Dann muss ich den zweiten Parameter übergeben, der vom Typ class ist. 02:02.700 --> 02:09.540 Und hier muss ich die Raumdatenbank angeben und diese Kontaktdatenbank fungiert als Raumdatenbank, 02:09.540 --> 02:12.120 also muss ich sie dot class übergeben. 02:12.120 --> 02:22.200 Und der dritte Parameter ist der Name dieser Datenbank, und ich werde sie wieder Kontakte Unterstrich DB nennen, Raumpunkt 02:22.200 --> 02:24.750 Database Builder. 02:24.780 --> 02:33.780 Dies ist eine Fabrikmethode, die von der Raumbibliothek bereitgestellt wird, um eine neue Datenbank zu erstellen oder auf eine bestehende Datenbank zuzugreifen. 02:33.780 --> 02:41.610 Es ermöglicht Ihnen die Konfiguration und den Aufbau einer Raumdatenbankinstanz Context Dot get application Context. 02:41.610 --> 02:47.250 Kontext ist in der Regel der Kontext der Anwendungskomponente, wie eine Aktivität oder eine Anwendung. 02:47.250 --> 02:54.540 Und hier wird die Methode get application context verwendet, um den Anwendungskontext zu erhalten, der bei der Arbeit mit Datenbanken 02:54.540 --> 03:01.530 oft bevorzugt wird, weil er einen längeren Lebenszyklus hat als beispielsweise ein Aktivitätskontext. 03:01.530 --> 03:08.580 Dies trägt dazu bei, Speicherlecks zu vermeiden, und dies ist die Datenbank Raumdatenbanken, die Sie mit der rooms-Anmerkung 03:08.580 --> 03:15.180 definiert haben, und dies ist der Name der Datenbank Raumdatenbanken sind in der Regel dateibasiert, und dieser Name 03:15.180 --> 03:20.640 wird verwendet, um die Datenbankdatei auf dem Speicher des Geräts zu identifizieren. 03:20.640 --> 03:26.550 Dann muss ich Fallback zur destruktiven Migration aufrufen. 03:26.550 --> 03:31.440 Diese Methode wird verwendet, um eine Datenbankmigrationsstrategie festzulegen. 03:31.440 --> 03:34.050 In diesem Fall wird diese Methode angewandt. 03:34.050 --> 03:42.090 Das bedeutet, dass der Raum, wenn eine neue Version des Datenbankschemas aufgrund von Änderungen in der Entitätsstruktur 03:42.090 --> 03:49.220 erkannt wird, die Datenbank löschen und neu erstellen wird, wobei alle vorhandenen Daten verworfen werden. 03:49.230 --> 03:57.930 Dies wird als destruktive Migration bezeichnet und ist während der Entwicklung nützlich, oder wenn es akzeptabel ist, vorhandene Daten 03:57.960 --> 04:01.230 für Produktionsanwendungen zu verlieren. 04:01.230 --> 04:08.910 In der Regel implementieren Sie ausgefeiltere Migrationsstrategien, um zu verhindern, dass Daten bei Schemaänderungen verloren gehen, oder um 04:08.910 --> 04:11.100 Daten bei Schemaänderungen zu erhalten. 04:11.100 --> 04:19.020 Und schließlich wird die Build-Methode aufgerufen, um die Raumdatenbankinstanz gemäß der angegebenen Konfiguration zu 04:19.020 --> 04:19.860 erstellen. 04:19.860 --> 04:24.960 Dies ist der Fall, wenn es keine Instanz gibt, wenn DB-Instanz gleich null ist. 04:24.960 --> 04:29.820 Andernfalls muss ich die Instanz zurückgeben, die erstellt wurde. 04:29.820 --> 04:37.470 Wenn es also eine Instanz gibt, die in den vorherigen Ausführungen oder Befehlen erstellt wurde, dann muss ich diese zurückgeben. 04:37.470 --> 04:46.080 DB So erstellen wir also nur eine Instanz unserer Datenbank, um den Speicher zu erhalten und Speicherlecks zu vermeiden, 04:46.080 --> 04:54.030 und synchronisiert wird verwendet, um eine Bereinigung der Kontaktdatenbank zu verhindern. 04:54.390 --> 04:56.760 Und das ist für die Themen. 04:56.760 --> 04:59.880 Die Methode get instance stellt also sicher, dass nur. 04:59.970 --> 05:07.110 Es wird eine Instanz der Kontaktdatenbank erstellt und während des gesamten Lebenszyklus der Anwendung verwendet. 05:07.110 --> 05:15.210 Dieses Singleton-Muster hilft bei der Arbeit mit einer Raumdatenbank, die Konsistenz, den Thread, die Sicherheit und die effiziente 05:15.210 --> 05:17.670 Ressourcennutzung zu erhalten.