Ich habe diese Frage gelesen und fühlte, dass ich stimme nicht ganz mit der Aussage Separation of user and profile data is a nice touch überein.
Wie ich es sehe, werden Profildaten wie z.B. Land oder was auch immer in das Benutzerobjekt gehört, während das Trennen dieser Daten in das Profil dazu führt, dass ein neues Objekt (und eine Tabelle) mit einer 1: 1-Beziehung zu dem Benutzerobjekt erstellt wird. Wird eine solche Trennung aus ästhetischen Gründen als gute Praxis angesehen? (Sie sehen nur Benutzereingabedaten in einer Tabelle und generierte Daten in einer anderen Tabelle)
Das geht nur, wenn Sie davon ausgehen, dass der Benutzer und das Profil eine 1: 1-Beziehung haben.
Wenn dies garantiert immer der Fall ist, dann könnte der Grund für die Trennung rein ästhetisch sein, aber es kann immer noch Leistungsgründe geben, die beiden zu trennen.
Zum Beispiel kann auf Profildaten von anderen Benutzern zugegriffen werden, sie können oft zwischengespeichert werden, ohne viel Rücksicht auf eine schnelle Ungültigkeitserklärung usw. zu nehmen.
Sie sind konzeptionell unterschiedliche Arten von Daten - selbst wenn sie eine 1: 1-Beziehung haben. Ich würde niemals Benutzer-Login-Daten zwischenspeichern - aber dann würde ich es nicht programmatisch Modulen offen legen, die nur Profildaten erfordern.
Das ist der Grund, wenn eine 1: 1-Beziehung garantiert gelten kann. Kann es?
Wenn Sie mehrere Anmeldedaten (oder mehrere Anmeldeverfahren) pro Benutzer zulassen, wird es jetzt interessanter. Zum Beispiel werden Cookie-basierte Sitzungen oft in einem flüchtigen Speicher auf der Serverseite gespeichert (es gibt selten eine Notwendigkeit für die Persistenz dieser Daten). Würden Sie diese Informationen auf das Benutzerobjekt oder auf das Profilobjekt zeigen?
Sie können eine unidirektionale Beziehung haben - es gibt einen Zeiger von Benutzer zu Profil, aber nicht von Profil zu Benutzer. Auf diese Weise können Module, die die Profildaten enthalten, die Anmeldedaten nicht ändern.
Was wäre, wenn Sie eine Lösung wie Facebook verwenden, mehrere Login-E-Mails pro Benutzer zulassen und sich zusätzlich über OpenID und eine iPhone / Android-App anmelden? Würden Sie dann zustimmen, dass Profil und Benutzer immer noch gleich sind?
Es gibt einige Gründe, warum ich Benutzerdaten teilen kann:
Pros:
Nachteile:
Zum Beispiel bietet Django (Python Web Framework) einen Authentifizierungsmechanismus und Sie können Ihren eigenen Profilmechanismus hinzufügen.
Wenn das Profil klein ist und niemals Änderungen unterliegt, können Sie es neben den Benutzerdaten speichern. Wenn das Profilschema in Zukunft geändert werden kann oder wenn es viele Daten enthält, ist es besser, Benutzer und Profil zu trennen.
Für mich ist der Benutzer: Login (Benutzername), Passwort, Rolle und wird verwendet, um alle sicherheitsrelevanten Dinge zu tun.
Das "Profil" ist eine zusätzliche Information für den Benutzer, die in einem separaten Objekt platziert werden sollte.
Und bedenken Sie: In einigen Fällen kann ein Benutzer mehr als ein Profil haben ...
Hauptsächlich, weil Profildaten nicht benötigt werden, wenn man nur wissen möchte, wer eine Entität erstellt hat. Der einzige wirkliche Ort, an dem ein Benutzerprofil benötigt wird, ist in erster Linie, wenn das System etwas für diesen Benutzer anpassen möchte, wenn es sich auf dem System befindet. Stellen Sie sich vor, dass das Profil die vom Benutzer bevorzugte Farbe hat, was für viele oder alle anderen Anwendungen der Anwendung unerheblich ist.
Tags und Links language-agnostic oop authorization