Design der Konto E-Mail-Aktivierung (mit Hibernate im Hinterkopf)

Question

Ich habe ein Design-Problem, das ich gerne etwas eingegeben würde. Hier sind die Einschränkungen:

1. Jeder Benutzer muss eine funktionierende E-Mail-Adresse bei der Registrierung ihres Kontos haben. Bei der Registrierung ihres Benutzerkontos sollte eine Aktivierungs-E-Mail gesendet werden, die einen Link mit einem Aktivierungscode enthält, der befolgt werden muss, damit das Konto aktiviert wird.
2. Jedes Benutzerkonto existiert in genau einem Büro, das in genau einer Firma existiert.
3. Der erste registrierte Benutzer eines Unternehmens erstellt das Unternehmen und ein Büro. Der Rest der Firmenbenutzer wird dann vom ersten Benutzer eingeladen.
4. Die Unternehmen können miteinander interagieren, jedoch nur, wenn die ersten Benutzer des Unternehmens aktiviert werden (d. H. Sie haben nach der Registrierung auf die entsprechenden Aktivierungslinks geklickt).

Hier ist ein kleines UML-Diagramm, wie es gelöst werden könnte:

alt text http://i43.tinypic.com/2dj5bhh.png

In dem obigen Diagramm einige Details weggelassen. Das Diagramm zeigt nur Klassen und Felder. Wenn es um Felder geht, die nur konzeptionell verwendet werden, um zu zeigen, welche Informationen gespeichert werden sollen, ignorieren Sie bitte deren Gültigkeitsbereich.

Einige Gedanken und Fragen:

• User und NotActivatedUser sind meist die gleichen. Sollten sie eine einzige Klasse oder getrennt sein? Wenn sie getrennt sind, welche Form der Hibernate-Vererbungs-Persistenz würden Sie verwenden?
• Wenn ein Konto nach einer bestimmten Zeit nicht aktiviert wird, sollte es entfernt werden. Wenn es der erste Benutzer war, der auch die Benutzer Firma und Büro erstellte, sollten beide ebenfalls entfernt werden. Brauchen wir auch NotActivatedOffice und NotActivatedCompany? (Für saubere Trennung in der Datenbank.)

Wie würden Sie diese Art von Lösung entwerfen? Halten Sie es für wichtig, nicht aktive und aktive Einheiten in der Datenbank getrennt zu halten? Warum oder warum nicht?

Answer 1

Ich würde Vererbung nicht verwenden, um einen Status (aktiviert/deaktiviert) Ihrer Benutzerobjekte darzustellen. Zusammensetzung (Aggregation) ist hier eine viel bessere Wahl.

Durch Verwendung der Aggregation wird AbstractUser einfach zum Benutzer. Möglicherweise möchten Sie die Aktivierung mit einer Klasse modellieren, statt die Benutzerklasse mit Aktivierungsattributen zu belasten. Auf diese Weise erhalten Sie ein schönes und sauberes Objektmodell.

Auf Datenbankebene können Sie weiterhin entscheiden, die zwei Objekte in der gleichen Tabelle/Datensatz zu speichern, bekannt als Component mapping. Oder Sie können entscheiden, Benutzer und Aktivierung in separaten Tabellen zu speichern (aka Entity mapping).

Hibernate unterstützt beide Arten von Zuordnungen, es ist hauptsächlich eine Frage der Konfiguration.

die Benutzerklasse würde die folgenden Attribute enthält:

• given
• Nachnamen
• email
• Aktivierung (Referenz auf ein Aktivierungs Objekt)

Die Aktivierungs-Klasse enthalten würde die folgenden Attribute:

• Aktivierungscode (String)
• senton (wenn wurde die E-Mail gesendet)
• activatedOn (standardmäßig auf null, auf das aktuelle Datum/Zeit, wenn der Benutzer den Aktivierungs Link klickt, weist das System, ob der Benutzer aktiviert sein Konto, wenn sie nicht null)

Sie eine HQL-Abfrage, welche Unternehmen mindestens eine aktivierte Benutzer muss wissen, verwenden könnte:

from Office o 
    left join fetch o.company 
where 
    o.administrator.activatedOn != null 

Diese Abfrage, dass y annimmt, Sie haben in Ihrer Office-Klasse ein Administratorattribut definiert. Der "Administrator" wäre ein Verweis auf den Benutzer, der das Office erstellt hat. In der Datenbank hat die Office-Tabelle einen Fremdschlüssel für einen Benutzerdatensatz.

Indem Sie die Beziehung auf diese Weise modellieren, können Sie den Administrator eines Büros ändern (z. B. hat er das Büro verlassen oder wurde entlassen). Alles hängt von Ihren Anwendungsfällen ab ...

Ich habe der Aktivierungsklasse auch ein sentOn-Attribut hinzugefügt, das nach einer bestimmten Zeit für die Bereinigung des inaktivierten Kontos verwendet wurde (in Ihrem UML-Diagramm fehlte).

Answer 2

Ich würde den NotActivatedUser nicht vom ActivatedUser trennen; habe nur eine Benutzertabelle und eine Spalte für "Aktiviert", standardmäßig 0 (nicht aktiviert).

Eine Sache; Ich würde den Aktivierungscode in eine separate Tabelle aufteilen, vielleicht mit "ActivationMethod". Dies ermöglicht in der Zukunft eine Erweiterbarkeit, wenn ein Benutzer sein Konto anders als E-Mail aktivieren und die Spalte "activationCode" aus der Benutzertabelle entfernen soll.

Ich würde mich nicht um nicht aktivierte Büros und Firmen kümmern; Gemäß Ihren oben beschriebenen Nutzungsplänen sollten sie nicht von anderen Personen verwendet werden können, bis dieser Benutzer sich aktiviert (und somit das Büro und die Firma). Eine Frage; Warum erlauben Sie einem nicht aktivierten Benutzer, ein Büro und ein Unternehmen zu erstellen? Warum beschränken Sie diese Aktivität nicht nur auf aktivierte Benutzer?

Answer 3

Persönlich würde ich nicht zwei Klassen für aktivierte und nicht aktivierte Benutzer schreiben, weil es nur ein Zustand ist. Wenn dieser Zustand vor der Aktivierung komplex wird, können Sie auf einen Aktivierungsstatus oder Ähnliches verweisen.

Wenn Sie einen "OfficeOwner" -Flag für den Benutzer haben, wissen Sie, wann Sie das Büro ohne komplexe Logik entfernen müssen.

Answer 4

Wenn Sie dieselbe Tabelle für aktivierte und nicht aktivierte Benutzer verwenden, müssen Sie den Status des Benutzers sowie der Büros und Firmen überall in der Anwendung überprüfen.

Aus diesem Grund würde ich wahrscheinlich eine activationrequest-Tabelle mit allen Informationen verwenden, die benötigt werden, um den Benutzer, das Büro und das Unternehmen zu erstellen, wenn die Aktivierung durchgeführt wird.