Michael Schröpl: Überschneidungen zw. Auth, User und Request-Daten

Beitrag lesen

Hi Andreas,

Jetzt habe ich das Problem, das als erstes die Auth-Klasse die Userdaten aus der Datenbank ermittelt, um diese zu validieren, und danach holt sich die User-Klasse den username und schickt im Prinzip dieselbe Abfrage an die Datenbank. Das ist nicht schön.

Du hast eine Diskrepanz zwischen der externen und der internen Repräsentation Deiner Objekte: Intern speicherst Du alles in einer Tabelle, extern sind es zwei verschiedene Objekte. Deshalb kommt Dir die Implementierung "nicht schön" vor. Sie ist jedenfalls nicht konsistent - sie ist nicht leicht zu verstehen. Und das ist für ihren Anwender, den Programmierer, ein Nachteil.

Habt Ihr eine Idee wie ich das gleichzeitig "schön" und ohne 2. Abfrage hinbekomme?

Hm. Ich würde den User als Objekt sehen, nicht aber die Authentifizierung desselben. Wieso ist das nicht einfach eine Methode dieses Objektes?

Ich könnte direkt alle Daten in der Auth-Klasse ermitteln, aber das wäre sehr unsauber, da das ja nichts mehr mit der Authentifizierung zu tun hat.

Das kommt auf die Definition der Aufgaben-Zuständigkeiten an. Wenn Deine User-Klasse dafür zuständig ist, alles zu tun, was mit den Attributen eines Users zu tun hat (also auch die Authentifizierung), dann sehe ich keine Unsauberkeit.

Ich könnte auch in der User-Klasse zuerst die Daten ermitteln, und _danach_ die Auth-Klasse validieren lasse. Aber das ist auf alle Fälle der falsche Weg.

Warum nicht beides simultan? Als SQL-Query formuliert:
   SELECT attributes
     FROM user_table
    WHERE username="<value1>"
      AND password="<value2>";
Klappt die Authentifizierung, dann bekommst Du eine Trefferzeile (ich impliziere, daß 'username' primary key ist), wenn nicht, dann bekommst Du nichts.

Viele Grüße
      Michael

--
T'Pol: I apologize if I acted inappropriately.
V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.