externe Variablen/Typen

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • entwickler schrieb:

    [...]Wie würdest Du sowas lösen? Tatsächlich immer übergeben?
    Und ist eine Kopplung loser oder enger, wenn ich verpflichtet bin, die Daten der Klasse immer zu übergeben?

    Ich weiß nicht genau, wie Deine App aufgebaut ist, aber ja: Ja, das würde ich übergeben. Wenn Du mit Sessions arbeitest, sind die ja normalerweise der Ausgangspunkt zum Model bzw. Kontext, der User hängt da ja normalerweise dran. Um etwas Vernünftiges zu tun braucht ein Controller die Session eh. Mir wäre es viel zu riskant, Sessions irgendwo global zu halten und implizit für alle zugreifbar zu haben - da habe ich schon zu viele, auch sicherheitskritische, Probleme gesehen, die aus einem kaputtem Session Management resultieren, wenn irgendwo angenommen wurde, dass a) die Session irgendwo auf magische Weise entsteht, b) es nur eine Session geben kann, c) sich eine Session nicht ändern kann, d) Sessions nicht ordentlich voneinander getrennt wurden, e) irgendwo auf Sessions zugegriffen wird, wo es nicht sein sollte usw. Also explizit. Macht auch das Testen einfacher (bzw. erst möglich).

    Ich weiß nicht, was Dein Logging tut. Wenn es ein für den User unsichtbares Zugriffslog ist, würden bei mir die Controller- oder Viewschicht wahrscheinlich gar nichts davon sehen. Im anderen Fall, dass der User darauf Zugriff hat, müsste es wahrscheinlich eh an der Session hängen, um Zugriff auf Aktivitäten anderer Sessions zu verhindern.

    Das alles hängt stark von Deinen Anforderungen ab, aber gerade bei Sessions und Usern ist es zu leicht, mit global zugreifbaren Objekten großen Mist zu bauen. Und sich Gedanken darüber zu machen, wer wann wie auf welche Logs zugreifen kann, ist auch nicht das Schlechteste, was man tun kann. Und wenn man wiederholt mehrere Sachen übergeben muss (was ja durchaus passieren kann), kann man sich überlegen, ob man diese Sachen in einen Kontext packen kann und was da reingehört oder ob es sonst einen eleganten Weg gibt.

    Es gibt bestimmt Situationen, in denen Globals oder Singletons sinnvoll oder notwendig sind - aber in den meisten Fällen ist das nicht der Fall, sondern es ist schlicht die Faulheit, etwas zu tippen oder sich über eine gute Modellierung Gedanken zu machen. Das meinte ich mit Pfusch. Und ja: wie MyMattes war ich auch schon mal faul und habe irgendwas ans AppDelegate gehängt. Habe mir dabei gesagt, dass das erstmal nur provisorisch ist und ich das später mal ordentlich mache. Habe mich dabei schlecht gefühlt, es dann vergessen und nicht selten ist es mir danach irgendwann mal auf die Füße gefallen. Während man etwas schreibt, ahnt man ja meistens nicht, wo das später mal landet.
    Multigrad - 360°-Produktfotografie für den Mac
  • Vielen Dank für die ausführliche Antwort.

    Zur App: Ich habe noch keine app, die mit Sessions arbeitet, das war nur ein Gedankenspiel. Interessehalber.
    Manchmal überlegt man ja auch, wie man selbst das gemacht hätte.
    Spielen wir das mal weiter.

    mattik schrieb:

    Mir wäre es viel zu riskant, Sessions irgendwo global zu halten und implizit für alle zugreifbar zu haben - da habe ich schon zu viele, auch sicherheitskritische, Probleme gesehen
    ok. klar. Ein globales Array wäre nicht so gut. Wobei für alle ja bei iOS bedeutet, für alles, was ich in den Sandkasten lege und da muss ich halt auf mein Werkzeug/Objekte selbst aufpassen, was die so machen. Aber egal. Das würde ich ja auch nicht so machen.

    Ich würde eine HauptSessionController haben, der sich um alles kümmert (Aufbau/Abbau der Session). Die Session/daten würde ich entsprechend persistieren, da ein ewiges einloggen mich stört (ist ja meine persönliche Fantasieapp, da darf ich machen, was ich will :) , dann lieber der Hinweis, dass man mit dem Zugangscode vom Handy auch Zugriff auf die aufgebaute Session hat.
    Dann hätte ich einen abgestuften Controller, der mir alle Basisdaten aus der Session auslesen (nur lesen) kann. Er brauch noch nicht prüfen, ob die Session tatsächlich noch existiert. Weil erst alle folgenden Aktionen (Eintrag hinzufügen/Löschen/etc.) einer solchen Prüfung unterliegen.
    Oben rechts, die Status/Profilinformation würde per Notification darüber informiert werden, wenn sich was ändern sollte.
    Das bedeutet, das jeder ViewController über den abgestuften Controller Zugriff die Sessiondaten haben muss und hat.
    Übrigens gehe ich davon aus, dass er genau das meinte mit
    mit den Eigenschaften und auf den User muss ich in allen Klassen drauf zugreifen können

    ----------
    So ungefähr würde ich es machen.
    Jetzt bitte alle Fehler respektvoll ansprechen. Sarkasmus und Ironie sind aber erlaubte Stilmittel ;)
    (Ich habe nicht Stift und Paper verwendet. s. u.)
    -----------
    Aus meiner Sicht ist das viel lockerer als die Daten immer mit zu übergeben. Wenn ein ViewController mal nicht oben den Status anzeigen soll, dann lasse ich es einfach und muss nicht refactoring betreiben und hoffen, dass Xcode auch alles richtig macht.
    -----------
    In deiner Variante (mit der Weiterreichung) wäre das Fortführen einer Session (nach dem manuellem Beenden) vermutlich nicht möglich? Ernst gemeinte neutrale Frage. Auch wenn Sie „natürlich“ Nein sein wird.
    -----------
    Ansonsten gebe ich Dir in allem Recht. Insbesondere, was das nachdenken über die benötigten Controller/Model/Rechte geht. da hilft es auch mal ein paar Stifte und ein A3-Blatt (200gr pro qm) in die Hand zu nehmen.
  • Du hast natürlich Recht, dass explizites Setzen aller Abhängigkeiten nicht automatisch lockere Kopplung ist. Aber es hilft ungemein dabei, bzw. ermöglicht es erst. Nur so sieht man überhaupt, welche Abhängigkeiten ein Objekt hat. So kann man es z.B. isolieren, getrennt testen und in einem anderen Kontext wieder verwenden.

    Eine globale Session (oder AppDelegate oder Singleton oder so) macht die Session ja nicht nur allen Controllern verfügbar, sondern auch jedem anderen Objekt, auch solchen, die damit gar nichts zu tun haben. Wenn das Projekt etwas größer wird, wird es parktisch unmöglich, den Überblick über alle Abhängigkeiten (direkte und indirekte) zu behalten. Das Problem gibt es übrigens auch bei kreuz und quer durch die App geworfenen Notifications - ist in einigen Fällen zwar praktisch, aber auch mit Vorsicht zu genießen.

    Die ganzen Sachen, die Du ansprichst, sind auch mit explizit übergebenen Abhängigkeiten machbar. Einmal liegt bei einer Client-Server-App das Original der Session ja gar nicht auf dem Client, sondern auf dem Server. Nebenbei: Sessions solle man nicht über mehrere Clients teilen - jeder seine eigene. Der Client hat vielleicht eine Session-ID und einen Cache für einige Daten (die sich auch persistieren lassen, z.B. für Offline-Betrieb). Aber das sollte die Controller- und die View-Schicht eigentlich gar nicht interessieren. Das Model liefert die Daten und ermöglicht Operationen darauf und stellt der Controller-Schicht dafür eine Schnittstelle bereit. Wie das Model das genau macht (z.B. ob es dafür eine neue Session eröffnet, weil die alte abgelaufen ist) geht den Controller nichts an. So sind Model und Controller gegeneinander austauschbar, solange die Schnittstelle gleich bleibt. Wenn das Model keinen Namen liefert schiebt der Controller halt keinen Namen in seinen View.
    Multigrad - 360°-Produktfotografie für den Mac
  • shit. grad alles hier im Editor gelöscht...

    ok. Abhängigkeiten sichtbarmachen, Code einfacher isolierbar machen..
    Das sind gute Argumente.

    Wobei man das Aufzeigen der Abhängigkeiten auch durch eine gute Dokumentation realisieren kann. Ok. klar, irgendwann wird die Dokumentation „schwammig“, wenn man bei der Pflege anfängt diese nach hinten bzw. später zu machen (was irgendwann immer passiert (wenns nicht von dritten sichergestellt wird), da man meint, das Projekt so gut zu kennen, dass man eine bestimmte Änderung nicht dokumentieren muss)

    Vielen Dank.