Enrico: Sinnvoller Umgang mit Session-Variablen und lokalen Variablen

Hallo,

ich habe mal eine generelle Frage bzgl. des effektiven Umgangs mit Session-Variablen in Relation zum Arbeitsaufwand auf dem Server in Verbindung mit der zu verarbeitenden Dateigröße.

Ich gebe unsere Sortimente über eine Schleife aus, die vom ersten bis zum letzten Artikel einer ausgewählten Rubrik geht.

Da ich die Details der einzelnen Artikel aber auch in nachfolgenden Seiten wieder brauche, lege ich die Details in Session-Variablen ab.

Nun zu meiner Frage:

Ist es sinnvoll, die Werte der Session-Variablen gleichzeitig auch lokalen Variablen zuzuweisen, damit der Code besser lesbar ist, was dann aber wieder eine größere Datei und einen höheren Arbeitsaufwand auf dem Server bedeutet, oder sollte man nach dem Anlegen der Session-Variablen nur noch mit diesen arbeiten, was zwar eine kleinere Datei bedeutet, den Code aber unübersichtlicher macht?

Was meint ihr?

Gruß
Enrico

  1. Moin!

    Da ich die Details der einzelnen Artikel aber auch in nachfolgenden Seiten wieder brauche, lege ich die Details in Session-Variablen ab.

    Eine Session ist kein Cache.

    Warum nicht? Der Vorteil eines Caches ist, dass man den Wert einmal aufwendig ermittelt und dann zusätzlich einmal in den Cache schreibt, um ihn später schnell erneut lesen zu können - so lange, wie er als gültig angesehen wird.

    Alle Daten einer Session werden zum Beginn des Skripts in den Speicher geladen und am Ende wieder weggeschrieben. Dieser Vorgang erfordert ständiges Serialisieren und Unserialisieren - diese Vorgänge sind ziemlich CPU-lastig - und ständiges Lesen und Schreiben dort, wo die Session persistent gespeichert ist. Je mehr Daten bewegt werden, desto langsamer wird alles.

    Ist es sinnvoll, die Werte der Session-Variablen gleichzeitig auch lokalen Variablen zuzuweisen, damit der Code besser lesbar ist, was dann aber wieder eine größere Datei und einen höheren Arbeitsaufwand auf dem Server bedeutet, oder sollte man nach dem Anlegen der Session-Variablen nur noch mit diesen arbeiten, was zwar eine kleinere Datei bedeutet, den Code aber unübersichtlicher macht?

    Die Dateigröße des Codes ist recht irrelevant. Lesbarkeit des Code bedeutet viel mehr, als wenige Mikrosekunden bessere Performance, denn die Lesbarkeit beeinflusst direkt die Geschwindigkeit der Entwickler. Wenn die CPU zu lahm ist, den Code auszuführen, dann kauft man sich einen schnelleren Server, oder zwei - alles billiger, als monate- und jahrelang nicht die beste Performance vom Entwickler zu erhalten. Entwickler sind teuer.

    Darüber hinaus ist es aus Codegründen ohnehin angesagt, möglichst KEINE Zugriffe auf globale Variablen zu machen - und $_SESSION gehört eindeutig dazu. Solchen Code kann man nämlich nur sehr schwierig testen. Also kapseln. Und kopieren! Nur-Lese-Kopien von Variablen sind in PHP performante Referenzen auf den Originalwert, die erst beim Ändern der Variablen echt kopiert werden und dabei die Referenz auflösen.

    - Sven Rautenberg

    1. Hallo Sven,

      danke erstmal für Deine ausführliche Antwort.

      Ich hoffe, ich habe Dich richtig verstanden:

      Ich definiere in der aktuell angezeigten Seite beispielsweise die Variable "Farbenzuschlag" als Session-Variable, da ich sie in nachfolgenden Seiten wieder brauche und gleichzeitig noch als gleichnamige lokale Variable, um mit ihr zu arbeiten?

      Gruß
      Enrico

      1. Hi

        Ich hoffe, ich habe Dich richtig verstanden:

        Ich definiere in der aktuell angezeigten Seite beispielsweise die Variable "Farbenzuschlag" als Session-Variable, da ich sie in nachfolgenden Seiten wieder brauche und gleichzeitig noch als gleichnamige lokale Variable, um mit ihr zu arbeiten?

        Set

          
          
        $product->setFarbwert($_SESSION["farbwert"]);  
          
        
        

        get

          
          
        someFunction($product->getFarbwert());  
          
        
        

        ein Umkopieren auf

        $farbwert = $product->getFarbwert();

        ist nicht nötig.

        1. Hallo Run,

          tut mir leid, aber das verstehe ich jetzt nicht.
          Kannst Du mir das genauer erklären?

          Gruß
          Enrico

          1.   
            function tuIrgendwas($a,$b){  
                 $c = "$a $b";  
                 return $c;  
            }  
              
            echo tuIrgendwas($_SESSION["kartoffel"],$_SESSION["matsch"]);  
            
            

            Du benutzt die globalen Variablen nur noch als Parameter an die Funktion.
            In der Funktion selbst arbeitest du mit deinen leicht lesbaren Variablennamen.
            Solange $a und $b in der Funktion keine Werte zugewiesen werden, werden sie intern von PHP nur als Referenz auf $_SESSION["kartoffel"] und $_SESSION["matsch"] gehalten. Wenn sie neue Werte zugewiesen bekommen, dann alloziiert PHP erst eigenen Speicher für die Variablen.
            Zusätzlich ist deine Routine abtrakter, da sie die Quelldaten bekommt und nicht "selbst beschafft".

            MfG
            bubble

            1. Hallo bubble,

              function tuIrgendwas($a,$b){
                   $c = "$a $b";
                   return $c;
              }

              echo tuIrgendwas($_SESSION["kartoffel"],$_SESSION["matsch"]);

                
              interessant, auch wenn mir so eine "Handhabung" völlig neu ist.  
                
              Für was nutzt man diese Vorgehensweise?  
                
                
              Gruß  
              Enrico
              
              1. Tach!

                function tuIrgendwas($a,$b){

                $c = "$a $b";
                     return $c;
                }

                echo tuIrgendwas($_SESSION["kartoffel"],$_SESSION["matsch"]);

                
                >   
                > interessant, auch wenn mir so eine "Handhabung" völlig neu ist.  
                > Für was nutzt man diese Vorgehensweise?  
                  
                Für alles mögliche. Das ist ein ganz normaler Funktionsaufruf mit zwei Parametern. Man verwendet Funktionen, um wiederkehrende Aufgaben nur einmal zu definieren und mehrfach mit unterschiedlichen Parametern aufzurufen.  
                  
                Du solltest nun aber nicht hingehen und all deine Zugriffe auf $\_XXX in Funktionen umzuschreiben. Das wäre auch wieder Quatsch.  
                  
                  
                dedlfix.
                
    2. Darüber hinaus ist es aus Codegründen ohnehin angesagt, möglichst KEINE Zugriffe auf globale Variablen zu machen - und $_SESSION gehört eindeutig dazu. Solchen Code kann man nämlich nur sehr schwierig testen. Also kapseln. Und kopieren!

      Hier lese ich eigentlich immer den Rat, man solle möglichst NICHT solche Dinge machen:
      $xy = $_POST["variable"]
      sondern immer mit $_POST arbeiten, da umkopieren unnötig ist.
      Ich kopier mir das ja auch immer weg, da ich ein sprechendes $xy sinnvoller finde als $_POST[...] und ich dadurch lesbareren und schneller geschriebenen Code habe.
      Du scheinst das so zu sehen wie ich.

      Jetzt muss ich doch mal fragen, was ist der Grund dass so oft geraten wird, man soll das nicht tun?

      1. Jetzt muss ich doch mal fragen, was ist der Grund dass so oft geraten wird, man soll das nicht tun?

        IMHO: Weil es bessere Wege gibt Code lesbarer zu machen. (zB. das im andern Post angesprochene Routinen-Abstrahieren)

        MfG
        bubble

      2. Tach!

        Hier lese ich eigentlich immer den Rat, man solle möglichst NICHT solche Dinge machen:
        $xy = $_POST["variable"]
        sondern immer mit $_POST arbeiten, da umkopieren unnötig ist.

        Richtig, es gibt keinen (für die typischen Anwendungsfälle kleinerer Scripts relevanten) Unterschied in der Verwendung, beides sind Variablen.

        Ich kopier mir das ja auch immer weg, da ich ein sprechendes $xy sinnvoller finde als $_POST[...] und ich dadurch lesbareren und schneller geschriebenen Code habe.

        Was soll an $name sprechender sein als an $_POST['name']? Da fehlt mindestens die Information der Herkunft. Oder meinst du, dass der Post-Parameter bei dir eine kryptische Bezeichnung hat, die gar nichts über dessen Inhalt aussagt? Dann wäre zu fragen, warum du sowas machst. Mir fällt da kein Vorteil ein. Und fürs schnellere Schreiben gibt es auf PHP spezialisierte Entwicklungsumgebungen, die einem mit Codevervollständigung und anderen Features weit mehr sparen als ein paar etwas umständlich einzugebende Sonderzeichen.

        Jetzt muss ich doch mal fragen, was ist der Grund dass so oft geraten wird, man soll das nicht tun?

        Weil damit die Anzahl der Variablen erhöht wird, ohne dass der Vorteil der einfacheren Schreibweise die Nachteile aufwiegt. Manchmal sieht man sogar, dass der umkopierte Wert lediglich ein einziges Mal verwendet wurde. Das ist dann sogar noch Mehrarbeit gegenüber der direkten Verwendung des $_POST-Elements.

        Wenn Tippeinsparungen das Argument für ein Umkopieren ist, dann muss man vorher zählen/wissen, wie oft der Wert verwendet wird und nur solche mit wirklicher Tippersparnis umkopieren. Das führt dann zu einer Zweiklassengesellschaft, bei der ein Teil der Werte umkopiert wird, ein anderer nicht - was noch mehr Chaos erzeugt, als das bisschen Tipparbeit einspart.

        dedlfix.

        1. Oder meinst du, dass der Post-Parameter bei dir eine kryptische Bezeichnung hat, die gar nichts über dessen Inhalt aussagt? Dann wäre zu fragen, warum du sowas machst. Mir fällt da kein Vorteil ein.

          Ich habe, auf der Suche nach einer captchafreien Spamabwehr gelesen, man könnte sich stets ändernde, mit Zufallsprozess generierte Feldnamen haben (die per Sessionvariablen parallel weitergegeben werden). Ein Grund :)

          Cheers,
          Baba

          1. Tach!

            Oder meinst du, dass der Post-Parameter bei dir eine kryptische Bezeichnung hat, die gar nichts über dessen Inhalt aussagt? Dann wäre zu fragen, warum du sowas machst. Mir fällt da kein Vorteil ein.
            Ich habe, auf der Suche nach einer captchafreien Spamabwehr gelesen, man könnte sich stets ändernde, mit Zufallsprozess generierte Feldnamen haben (die per Sessionvariablen parallel weitergegeben werden). Ein Grund :)

            Nö, das wäre nur ein Grund, $_POST[$name] statt $_POST['name'] zu verwenden.

            dedlfix.

            1. Nö, das wäre nur ein Grund, $_POST[$name] statt $_POST['name'] zu verwenden.

              Das würde alledings auf $_POST[$_SESSION["feldname"]] hinaus laufen (wenn man nicht grade mit Funktionen arbeitet)

              MfG
              bubble

              1. Nö, das wäre nur ein Grund, $_POST[$name] statt $_POST['name'] zu verwenden.
                Das würde alledings auf $_POST[$_SESSION["feldname"]] hinaus laufen (wenn man nicht grade mit Funktionen arbeitet)

                Stimmt auch wieder (@both).

                Cheers,
                Baba

          2. Hallo Baba,

            man könnte sich stets ändernde, mit Zufallsprozess generierte Feldnamen haben (die per Sessionvariablen parallel weitergegeben werden)

            Das interessiert mich.
            Weisst Du noch, wo Du das gelesen hast?

            Gruß
            Enrico

            1. Das interessiert mich.
              Weisst Du noch, wo Du das gelesen hast?

              Arhh, war auf einem anderen Rechner. Habs aber doch gefunden! Bin für weitere Links für guten Spamschutz für Formulare ohne Captcha auch dankbar.
              Cheers,
              Baba

              1. Super, danke, Baba

                Gruß,
                Enrico

        2. Hi

          Hier lese ich eigentlich immer den Rat, man solle möglichst NICHT solche Dinge machen:
          $xy = $_POST["variable"]
          sondern immer mit $_POST arbeiten, da umkopieren unnötig ist.

          Richtig, es gibt keinen (für die typischen Anwendungsfälle kleinerer Scripts relevanten) Unterschied in der Verwendung, beides sind Variablen.

          Ich kopier mir das ja auch immer weg, da ich ein sprechendes $xy sinnvoller finde als $_POST[...] und ich dadurch lesbareren und schneller geschriebenen Code habe.

          Was soll an $name sprechender sein als an $_POST['name']? Da fehlt mindestens die Information der Herkunft. Oder meinst du, dass der Post-Parameter bei dir eine kryptische Bezeichnung hat, die gar nichts über dessen Inhalt aussagt? Dann wäre zu fragen, warum du sowas machst. Mir fällt da kein Vorteil ein. Und fürs schnellere Schreiben gibt es auf PHP spezialisierte Entwicklungsumgebungen, die einem mit Codevervollständigung und anderen Features weit mehr sparen als ein paar etwas umständlich einzugebende Sonderzeichen.

          du findest sowas also i.O:

            
          $_POST["test"] = str_replace("xy" ,"", $_POST["test"]);  
          
          

          ?

          Meines Erachtens Unfug. Ich will zu _JEDER_ Zeit in meinem Programm wissen, welche Post-Daten ihr übergeben wurden. Und zwar unverfälscht.

          1. Tach!

            du findest sowas also i.O:
            $_POST["test"] = str_replace("xy" ,"", $_POST["test"]);
            ?
            Meines Erachtens Unfug. Ich will zu _JEDER_ Zeit in meinem Programm wissen, welche Post-Daten ihr übergeben wurden. Und zwar unverfälscht.

            Ich habe nicht gesagt, dass man ausschließlich die Einträge von $_POST und Konsorten nehmen soll, inklusive aller Änderungen, die man an dem Wert vorzunehmen gedenkt. Aber ich hab auch nichts prinzipielles dagegen, wenn es dafür eine gute Begründung gibt (Magic-Quotes-Entfernung beispielsweise). Und ich wüsste jetzt auch nicht, warum man pauschal auf einer Unversehrtheit der Daten bestehen müsse - ohne konkrete Einsatzfälle zu betrachten. Es ging hier auch bisher nicht um Änderungen an den Werten, sondern um das einfache Kopieren zum Zwecke einer angeblich besseren Lesbarkeit und Tippersparnis.

            dedlfix.

          2. Hallo,

            Was soll an $name sprechender sein als an $_POST['name']? Da fehlt mindestens die Information der Herkunft. [...]
            du findest sowas also i.O:

            $_POST["test"] = str_replace("xy" ,"", $_POST["test"]);

            nein, eben gerade nicht. Da werden Eingabedaten verändert, es ist also strategisch absoluter Unsinn, sie dann wieder in $_POST abzulegen und sich selbst damit zu suggerieren, es handle sich immer noch um die Eingabedaten.

            Gerade dann, wenn Daten verändert werden, ist ein Umkopieren oft sinnvoll.

            Meines Erachtens Unfug. Ich will zu _JEDER_ Zeit in meinem Programm wissen, welche Post-Daten ihr übergeben wurden. Und zwar unverfälscht.

            Eben.

            Ciao,
             Martin

            --
            Realität ist eine Illusion, die durch Unterversorgung des Körpers mit Alkohol entstehen kann.
            Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
          3. du findest sowas also i.O:

            $_POST["test"] = str_replace("xy" ,"", $_POST["test"]);

            
            > ?  
            > Meines Erachtens Unfug. Ich will zu \_JEDER\_ Zeit in meinem Programm wissen, welche Post-Daten ihr übergeben wurden. Und zwar unverfälscht.  
            
            Da werden dir wohl die meisten/alle zustimmen, hier ging es (zumindest so weit ich verstanden hab) aber darum, Post und Konsorten für die \_LESBARKEIT\_ umzukopieren.  
              
            MfG  
            bubble