SWT Globale Variable

[breakpoint]

Hi,
wie würdet ihrer in einer SWT-Anwendung (kein Eclipse RCP) ein Database-Handle global verfügbar machen?

Gibt's was eleganteres als ein Singelton? Wobei dies alle Anforderungen erfüllen würde.

Danke für Tipps/Beispiele! :]

 

[Joose]

Warum muss diese Handle global verfügbar sein? Warum nicht dann erstellen wenn es gebraucht wird?

 

[breakpoint]

Es ist eine JDBC-Connection. Bei Programmstart wird die Verbindung hergestellt und gehalten. Jedes SWT-Fenster soll prinzipiell auf sie Zugriff haben.

 

[Joose]

Eine Datenbankverbindung sollte dann bestehen wenn sie gebraucht wird. Eine dauerhaft geöffnete Verbindung sollte vermieden werden.

 

[da921610]

Meinst du vielleicht sowas wie eine abstrakte Klasse, wo alle Methoden statisch sind?
Und innerhalb dieser Methoden kannst du ja dann immer die Verbindung aufbauen. Bzw. dir statische Variablen speichern.
Somit würdest du von jeder Klasse darauf zugreifen können, ohne dir ein Objekt zu erzeugen.

 

[breakpoint]

Danke für eure Antworten.

@user da921610: Da wäre ich wieder bei meinem Singelton
@Joose:
Es ist eine sqlite-Datenbank, auf die zugegriffen wird, und die Verbindung wird die gesamte Programmlaufzeit über benötigt.

 

[Joose]

Je nach deiner Architektur kannst du das DB Handle an einer zentralen Stelle erstellen und per getter/setter an die benötigten Komponenten weiterreichen. Bei einer entsprechenden Trennung der Zuständigkeiten sollten nur wenige Klassen wirklich den DB Handle benötigen.

Da wäre ich wieder bei meinem Singelton

Singleton wäre eine schlechte Wahl.

Es ist eine sqlite-Datenbank, auf die zugegriffen wird, und die Verbindung wird die gesamte Programmlaufzeit über benötigt.

Ich bin mir da unsicher
Wird wirklich eine dauerhafte Verbindung gebraucht? Sprich gibt es einen Thread der alle paar ms Daten schreibt, liest oder analysiert?
Oder werden erst Daten gelesen/eingetragen sobald der User bestimmte Aktionen/Events auslöst?

 

[breakpoint]

@Joose, es kann natürlich vorkommen, dass der User mal kurz nen Kaffee holen geht . Aber grundsätzlich wird die Verbindung die ganze Zeit benötigt. Ich denke, ein Reconnect wäre da unnötig. Ich würde deinem Einwand zustimmen, wenn es Grund gäbe, die dahinterliegende Datenbank durch einen Disconnect zu schonen. Doch es ist, wie gesagt, nur diese eine sqlite-Datei, die ausschließlich von 1 Programm genutzt wird.

Aber zurück zur eigentlichen Frage: Beim Singelton ist mir nicht ganz wohl, ja. Was wäre eine gute Alternative?

 

[dzim]

@Joose Was findest du denn so schlimm am Singleton? Es gibt Situationen, da lässt es sich kaum vermeiden.

In dem Beispiel hier würde ich ungefähr so etwas machen:

import java.io.File;
import java.sql.Connection;
import java.sql.SQLException;
import java.sql.Statement;
import java.util.Locale;
import java.util.Properties;

import javax.sql.DataSource;

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import org.sqlite.SQLiteConfig;
import org.sqlite.javax.SQLiteConnectionPoolDataSource;

/* etwas gekürzt */

public class ConnectionManager {
   
    private static final Logger LOGGER = LogManager.getLogger(ConnectionManager.class.getName());
   
    private static SQLiteConnectionPoolDataSource dataSource = null;
   
    public static void init() throws DesktopDAOException {
        init(null);
    }
   
    public static void init(Properties props) throws Exception {
       
        if (props != null) {
            // check props and: append to JDBC, or drop / update tables / ...
        }
       
        String userHome = System.getProperty("user.home");
        if (userHome == null || userHome.isEmpty()) {
            // hier sollten "Custom" Exceptions verwendet werden - nicht Exception - wurde hier gekürzt
            throw new Exception("Could not determine the current user's home!");
        }
       
        SQLiteConfig config = new SQLiteConfig();
        dataSource = new SQLiteConnectionPoolDataSource(config);
       
        File dbPath = new File(userHome + Constants.USER_PATH);
        if (!dbPath.isDirectory()) {
            dbPath.mkdirs();
        }
       
        String url = String.format(Locale.ENGLISH, Constants.CONN_STRING_TEMPLATE, userHome);
        LOGGER.debug(String.format(Locale.ENGLISH, "JDBC-URL is: %s", url));
       
        dataSource.setUrl(url);
        dataSource.setDatabaseName(Constants.DB_NAME);
       
        try {
            initPerformanceDB();
        } catch (SQLException e) {
            throw new Exception(e);
        }
    }
   
    public static DataSource getDataSource() throws DesktopDAOException {
        if (dataSource == null)
            init();
        return dataSource;
    }
   
    public static Connection getConnection() throws DesktopDAOException, SQLException {
        if (dataSource == null)
            init();
        return dataSource.getConnection();
    }
   
    private static void initPerformanceDB() throws DesktopDAOException, SQLException {
        try (Connection conn = getConnection(); Statement stmt = conn.createStatement();) {
            stmt.executeUpdate(Tables.Preferences.SQL_CREATE);
            stmt.executeUpdate(Tables.Results.SQL_CREATE);
            stmt.executeUpdate(Tables.ResultDetails.SQL_CREATE);
        }
    }
}

Sprich: Da ist ein Singleton für die DataSource. Die connection selbst ist "on-demand" und sollte auch, wie @Joose es beschreibt nicht permanent offen gehalten werden.

 

[Joose]

Was findest du denn so schlimm am Singleton? Es gibt Situationen, da lässt es sich kaum vermeiden.

Natürlich gibt es ganz seltene Ausnahmen wo ein Singleton hilfreich sein kann, aber das ist eben selten. Es sollte sich jederzeit anders lösen lassen.
Wenn ich dieselbe Instanz von etwas an den unterschiedlichsten Stellen brauchen dann muss ich diese eben entsprechend weiterreichen.

 

[dzim]

Das nennt sich DependecyInjection - und am Beispiel von SpringBoot, mit dem ich so was auch schon mal für JavaFX gemacht. Und am Ende waren die DAOs auch als Singletons gescoped - weil in dem Fall alles andere sinnlos ist.
Singleton sind IMHO per se nicht "böse" und die Art der Dependency Injection ist am Ende meist auch nur syntaktischer Zucker.