OOP Programmstrukturierung: UserManager für Webanwendung

[e:ke]

Hallo,
ich hoffe hier ein paar Tipps für eine kleine Java Webanwendung zu bekommen. Ich habe zwar Programmiererfahrung, allerdings nicht im Bereich OOP. Was mir quasi fehlt ist das objektorientierte Denken bzw. Herangehen beim Codeaufbau. Intuitiv würde ich einfach alles strukturiert prozedural abarbeiten... Mit diesem Projekt möchte ich die OOP etwas trainieren.
Konkret geht es um einen UserManager für eine JSF Webabwendung. Ich habe also ein "Java-Web-Application" Projekt in Eclipse mit Tomcat 8.5 und PrimeFaces aufgesetzt. Grundsätzlich läuft die Infrastruktur soweit. Mein UserManager soll in der Lage sein folgende Funktionen für den User bereit zu halten:

1. User registrieren (Mail + Password)
2. User einloggen --> Zugriff auf gesicherten Bereich
3. User löschen
   
4. User ausloggen
5. User Passwort ändern

Weiterhin ist es natürlich erforderlich, dass die Daten aller User irgendwie gespeichert werden. Als Textdatei macht das vermutlich nur für eine Übungsaufgabe Sinn. Ich habe mir folgende Strukturierung überlegt:
Es gibt also eine Klasse User:

public class User {
    public String username;
    public String password;
  // + getter + setter methods...
}

Für die Schnittstelle mit der Webseite gibt es eine Bean Klasse, in der ich NUR die Daten halten möchte, die auch benötigt werden. Der Tomcat verwendet die Getter/Setter Methoden, um username und password mit den entsprechenden Formularen der XHTML Seite zu verknüpfen.

@ManagedBean
@SessionScoped
public class LoginBean implements Serializable {
    private String username;
    private String password;
    //...
    public String doLogin() {
       System.out.println("LoginBean.doLogin");
     //...
    }  
public String doLogout() {
       System.out.println("LoginBean.doLogout");
     //...
    }  
public String doRegister() {
       System.out.println("LoginBean.doRegister");
     //...
    } 
// + getter + setter methods...
}

Für solch ein Login Bean habe ich ein einfaches Beispiel gefunden. Allerdings sind die username und password dort explizit im Code angegeben. Jetzt möchte ich das ganze etwas erweitern und habe eine Klasse UserManager gebaut, die alle vorhandenen und zukünftigen User in einem Vektor halten soll. Es gibt dort also etwas wie:

  Vector<User> users = new Vector<User>();

Somit sollen sämtliche User in dem Vektor users gehalten werden.
Von der Klasse User werden also immer wieder Objekte erzeugt und in users abgelegt oder mit den Einträgen dort verglichen. Der UserManager soll sinngemäß folgende Methoden enthalten:

1. loadUsersFromDataBase
2. writeUsersToDataBase
3. addUser
4. validateUser
5. deleteUser

Vom UserManager sollen also nicht ständig neue Objekte erzeugt werden, er soll den Vektor aller User nur einmal halten und bearbeiten. Beim laden der Webseite und damit über das Bean muss irgendwie der UserManager gestartet werden, der am Anfang die Daten von Platte laden muss. Sobald ein neuer User hinzu kommt, muss auch die Datenbank geschrieben werden, denn sobald die Session stirbt, ist auch der UserManager nicht mehr da.

Hier bin ich allerdings am Ende: Wie starte ich den UserManager vom LoginBean aus? Irgendwie sehe ich nicht den "Anfang" des ganzen Programms. Es gibt schließlich kein "Main".
Wenn es dann ein einziges Objekt des UserManagers gibt, wer erzeugt es? und wie können die anderen Klassen dann die Methoden des UserManagers aufrufen? Die Klasse User kann ich mir bildlich vorstellen, die des UserManagers irgendwie nicht. Ist der ganze Ansatz schlecht gewählt? Sollte der User selbst die Methoden (z.B. hinzufügen zu Datenbank users) besitzen? Aber welche Klasse hat dann die Daten users?
Mittlerweile bin ich ziemlich verwirrt...
PS: Was wäre der geeignete Weg, die Daten zu speichern? Eine SQL Datenbank? Oder gibt es etwas "kleineres"?

 

[sascha-sphw]

Auf Server Seite hat sich die Schichtenarchitektur bewährt. Das würde in Deinem Fall bedeuten, der UserManager wird ein UserDAO und erledigt das Laden der User aus der DB.
Ich würde auch nicht immer alle User aus der Datenbank vorhalten, Du wirst sie in einer Session ja nicht alle brauchen. Hier solltest Du nur den aktuellen User laden.

Bei Server Anwendungen bin ich ein großer Fan von Stateless, somit sollte der Server auch keine Session starten, hier würde ich mit JWT die relevanten Daten mitschicken.

Solltest Du dennoch Deinen Ansatz weiter verfolgen wollen, mit einem Server Container hat man die Möglichkeit einen Context Listener hinzuzufügen. Damit kannst Du dann beim Starten Deinen UserManager erzeugen und beim Stoppen entsprechend wieder aufräumen. https://docs.oracle.com/javaee/6/api/javax/servlet/ServletContextListener.html

PS: Was wäre der geeignete Weg, die Daten zu speichern? Eine SQL Datenbank? Oder gibt es etwas "kleineres"?

Eine SQL Datenbank ist der geeignete Weg.

 

[Manuel.R]

ich würde den Vorgang zum Logging etwas anders strukturieren:

@Named
@RequestScoped
public class LoginCredentials {
  
    private String userName;
  
    private String password;

    public LoginCredentials() {
        super();
    }

    public String getUserName() {
        return userName;
    }

    public void setUserName(String userName) {
        this.userName = userName;
    }

    public String getPassword() {
        return password;
    }

    public void setPassword(String password) {
        this.password = password;
    }
}

Die eigegebenen Daten werden im Anschluss über einen Controller verifiziert. Die Eingabe von Passwort und Benutzername ist selbst nur im Request-Mode. Somit werden die Eingabe nach Beendigung der Anfrage von Container verworfen.

package org.fourd.phase.configuration;

import java.io.Serializable;
import java.util.ResourceBundle;
import java.util.logging.Level;
import java.util.logging.Logger;

import javax.enterprise.context.SessionScoped;
import javax.enterprise.inject.Produces;
import javax.faces.application.Application;
import javax.faces.application.FacesMessage;
import javax.faces.context.FacesContext;
import javax.inject.Inject;
import javax.inject.Named;

import org.fourd.pages.Pages;

/**
* @author Manuel
*
*/
@Named
@SessionScoped
public class LoginController implements Serializable
{
    private static final long serialVersionUID = -684028620835489337L;
    /**
     * Through CDI the necessary object for evaluating the login credentials
     * were injected in - loginController provides the typed in username and
     * password - the userManager is checking the typed in credentials against
     * existing data in the xml file - if credentials match to an existing user
     * the user become the currentUser
     */
    @Inject
    private LoginCredentials loginCredentials;
  
    @Inject
    private UserManager userManager;
  
    //@Inject
    //private LanguageController languageController;
  
    private Logger logger = Logger.getLogger(this.getClass().getName());
  
    private User currentUser;

    /**
     * Login-Method is responsible for the login action. The username and password from the view
     * (loginController)
     * @return
     */
    public String doLogin()
    {
        FacesContext context = FacesContext.getCurrentInstance();
        Application app = context.getApplication();
        ResourceBundle resourceBundle = app.getResourceBundle(context, "msg");
      
        String errorMsg = resourceBundle.getString("error_msg_login_failed");
      
        boolean login = false;
      
        try
        {
            currentUser = userManager.findUser(loginCredentials.getUserName(), loginCredentials.getPassword());
            if(currentUser!=null)
            {
                login = true;
            }else
            {
                FacesContext.getCurrentInstance().addMessage(null, new FacesMessage(FacesMessage.SEVERITY_ERROR, "Error!", errorMsg));
            }
        } catch (Exception e)
        {
            logger.log(Level.SEVERE, "Error do Login: "+e.getMessage());
        }
      
        if(login){
            FacesContext.getCurrentInstance().getExternalContext().getSessionMap().put("currentUser", currentUser);
            return Pages.HOME_VIEW;
        }else{
            return null;
        }
    }
  
    public String doShowProjects(){
        return Pages.PROJECT_VIEW;
    }

    @Produces
    @CurrentUser
    public User getCurrentUser() {
          return currentUser;
    }
}

über CDI kann dann im Anschluss auf den Benutzer der Session zugegriffen werden, wenn eine Benutzer-Verifikation notwendig wird.