Abhängigkeit von Klassen unmöglich?

[himitsu]

Ich dachte es gibt für PHP 2 Methoden, wie dieses Modul aufgerufen wird?

- sowas wie 'ne DLL, welche bei jedem Request neu geladen wird
- und quasi als EXE, welche ständig aktiv ist und z.B. vom "Apache" die Requests zugeschockt bekommt,

aber Klassen und der restliche zum Request gehörende Speicher werden wohl so oder so jedesmal neu geladen und am Ende freigegeben.

Wenn man diese Klasse aber in der Session serialisiert hat, dann könnte man sie von dort jeweils neu rausladen.

[shmia]

Zitat von Matze:

Im Konstruktor kann ich den Cache aktivieren oder deaktivieren:

Code:

$cache = new cache(true); // aktiviert
$cache = new cache(false); // deaktiviert

Also mir scheint hier schon ein grundsätzliches Designproblem zu liegen.
Welchen Sinn macht ein Cache, der über den Konstruktor deaktiviert werden kann? (rhetorische Frage
Man kann den Cache-Size auf 0 setzen, so dass im Prinzip jeder Zugriff auf den Cache zu einen "Miss" wird.
Oder es gibt eine Methode ClearCache.
Aber ein An/Aus-Flag im Konstruktor is nicht gut.

[dominikkv]

Ich kenne das Cachen von DB-Abfragen von einer Shopsoftware. Dabei werden die Ergebnisse in eine (bzw in mehreren) Dateien zwischengespeichert.

Zu deinem Parameter-Problem: ich würde das nicht über einen Parameter steuern. Ich würde der Klasse Cache selbst die Entscheidung überlassen, ob eine bestimmte Abfrage gecached werden soll oder nicht. Du kannst dir ja eine Zeitspanne überlegen, nach der die zwischengespeicherten Informationen verfallen. Das kannst du sogar für jede Abfrage getrennt verwalten.

[Matze]

Hallo

Zitat von shmia:

Welchen Sinn macht ein Cache, der über den Konstruktor deaktiviert werden kann? (rhetorische Frage
Man kann den Cache-Size auf 0 setzen, so dass im Prinzip jeder Zugriff auf den Cache zu einen "Miss" wird.
Oder es gibt eine Methode ClearCache.
Aber ein An/Aus-Flag im Konstruktor is nicht gut.

Das Auslesen der Daten erfolgt generell über die Cache-Klasse. Ist der Cache deaktiviert oder die Cache-Zeit abgelaufen, bekomme ich "false" zurück und lese die Daten aus der Datenbank. Bei Aktiviertem Cache erhalte ich die gecachten Daten.
So übel finde ich das gar nicht.

Zitat von dominikkv:

Zu deinem Parameter-Problem: ich würde das nicht über einen Parameter steuern. Ich würde der Klasse Cache selbst die Entscheidung überlassen, ob eine bestimmte Abfrage gecached werden soll oder nicht. Du kannst dir ja eine Zeitspanne überlegen, nach der die zwischengespeicherten Informationen verfallen. Das kannst du sogar für jede Abfrage getrennt verwalten.

Ein Zeitlimit ist vergeben. Nur zu Testzwecken möchte ich bsp. den Cache deaktivieren, dass ich sichergehen kann, mit den aktuellen Daten zu arbeiten.

Notfalls lege ich den Cache-Status über eine Konfigurationsdatei fest. Es wäre halt schön gewesen, das übers Admin-Panel zu erledigen.

Grüße, Matze

[Christian Seehase]

Moin Matthias,

Zitat von Matze:

Nur zu Testzwecken möchte ich bsp. den Cache deaktivieren, dass ich sichergehen kann, mit den aktuellen Daten zu arbeiten.

Dann solltest Du aber auf jeden Fall eine Methode oder Eigenschaft vorsehen, um das zu regulieren.

Über den Konstruktor initial den Cache ein- bzw. auszuschalten kannst Du dann auch zusätzlich machen, wenn Du hierbei Einschalten als Defaultwert annimmst, hast Du wahrscheinlich auch das Problem mit den Configdaten erschlagen.

[Matze]

Hallo Christian

Zitat von Christian Seehase:

Über den Konstruktor initial den Cache ein- bzw. auszuschalten kannst Du dann auch zusätzlich machen, wenn Du hierbei Einschalten als Defaultwert annimmst, hast Du wahrscheinlich auch das Problemt mitsallo Chri den Configdaten erschlagen.

Genau so habe ich es aktuell. Der Standardwert ist "true".

Ich kann mal den genauen Code zeigen, wie ich die Daten zur zeit hole. Nur ob das zu einer Lösungsfundung beiträgt, weiß ich nicht:

Code:

$data = $cache->get('somedata.php');
if ($data === false) // Cache abgelaufen oder Cache deaktiviert
{
   $data = ...; // aus der Datenbank holen
   $cache->put('somedata.php');
}

Ich könnte natürlich die ganzen Codestellen so abändern, aber das gefällt mir nicht sonderlich:

Code:

if ($cache_enabled)
{
   $data = $cache->get('somedata.php');
   if ($data === false) // Cache abgelaufen oder Cache deaktiviert
   {
      $data = ...; // aus der Datenbank holen
      $cache->put('somedata.php');
   }
}
else
{
   $data = ...; // aus der Datenbank holen
}

Wobei das zur Not sicher ginge.

Edit: Wobei ne, da hätte ich das gleiche Problem.

Grüße, Matze

[nat]

also irgendwie würde ich das anders designen. dein code will daten anfordern...
dann geht es ihn doch eigentlich nichts an ob die daten nun aus dem cache kommen
oder direkt aus der DB. ich würde noch eine daten-klasse dazwischen klemmen
die dann entscheidet ob aus dem cache gelesen wird oder aus der DB.

Code:

class Data
{
    private $cache;
    
    public $forceDB = false;
    
    public function __construct()
    {
        $this->cache = new Cache();             
    }
    
    public function get($name)
    {
        $data = false;
        if(!$this->forceDB)
            $data = $cache->get($name);
            
        if($data === false)
        {
            //aus DB lesen
            $data = ...;
            $cache->set($name, $data);
        }

        return $data;
    }
}

$data = new Data();
$data->forceDB = true;
echo $data->get('blabla');

und ob forceDB auf true gesetzt wird kannst du dann ja auf verschiedene
art und weise implementieren. du könntest das z.B. über einen parameter
machen den du deinem script übergibst. oder du stellst das im admin-panel
ein und speicherst es in deiner session.
wenn ich das richtig verstanden habe soll der cache ja nur für dich zum
testen deaktiviert werden, oder? dann wär das ja vollkommen ausreichend.

[shmia]

Ich denke dass "nat" auf der richtigen Spur ist.
Eigentlich benötigt man eine Proxy-Klasse, die einen Cache benützt.
Und es gibt noch ein Dateninterface; also die Schnittstelle über die Daten geholt werden.
Ein ganz einfaches Interface sieht so z.B. so aus:

Delphi-Quellcode:

IDataInterface = interface
  // liefert einen Wert anhand eines Schlüssel
  function GetData(key:string):string;
end;

Das heisst jetzt nicht, dass man wirklich Interfaces verwenden muss; es dient nur zur gedanklichen Vorstellung.
Dann sähe das "Objektschaltbild" so aus:

Code:

Konsument <-- Datenobjekt

Jetzt schalten wir ein Proxyobjekt zwischen den Konsument und das Datenobjekt.
Das Proxyobjekt hat die gleiche Schnittstelle wie das Datenobjekt.
Sowohl das Proxyobjekt als auch das Datenobjekt implementieren die gleiche Schnittstelle.
Der Konsument merkt also gar nicht, ob es direkt auf dem Datenobjekt arbeitet oder mit dem Proxy redet:

Code:

Konsument <-- Proxy <-- Datenobjekt
                |
                |
              Cache

Die Proxyklasse erhält im Konstruktor das Datenobjekt übergeben.
Der Datenfluss durch den Proxy geht im Bild oben nur in eine Richtung.
Man kann den Proxy aber auch so bauen, dass auch Daten vom Konsument zum Datenobjekt fliesen.

Code:

Konsument/Produzent <--> Proxy <--> Datenobjekt
                          |
                          |
                        Cache

Hierbei gibt es mindestens drei Varianten:
1.) Der Proxy schiebt die Daten nur in den Cache und markiert sie (dirty bit) als verändert.
Später werden alle veränderten Daten zum Datenobjekt zurückgeschrieben
2.) Der Proxy schreibt direkt durch zum Datenobjekt (write-through)
3.) Der Proxy schreibt direkt durch zum Datenobjekt und zusätzlich in den Cache

Man braucht so mehr Klassen, aber dürfte so kein Problem sein, den Proxy zur Laufzeit
in den Transparentmode zu versetzen.
Vielleicht arbeitet auch irgend jemand am Proxy vorbei und es könnte nötig werden den Cache zu löschen,
weil die Daten nicht mehr aktuell sind.

[alcaeus]

Moin,

@nat: implementier doch auch gleich Dependency Injection:

Code:

class Data
{
    private $cache;
    
    public $forceDB = false;
    
    public function __construct($cache)
    {
        $this->cache = $cache;             
    }
    
    public function get($name)
    {
        $data = false;
        if(!$this->forceDB && $this->cache)
            $data = $this->cache->get($name);
            
        if($data === false)
        {
            //aus DB lesen
            $data = ...;
            if ($this->cache)
                $this->cache->set($name, $data);
        }

        return $data;
    }
}

$data = new Data(new Cache());
$data->forceDB = true;
echo $data->get('blabla');

Der Vorteil ist, dass du dann Cache auch als Singleton implementieren kannst:

Code:

$data = new Data(Cache::getInstance());

Greetz
alcaeus

[nat]

Zitat von alcaeus:

@nat: implementier doch auch gleich Dependency Injection

da hast du wohl recht, könnte man machen. wenn die scripte klein und überschaubar sind,
mag ich es jedoch auch, wenn die klasse sich selber darum kümmert was sie benötigt.
wird das ganze allerdings komplexer ist es schon von vorteil, wenn die klasse
nicht von etlichen anderen abhängig ist.

Zitat von alcaeus:

Der Vorteil ist, dass du dann Cache auch als Singleton implementieren kannst:

Code:

$data = new Data(Cache::getInstance());

ich denke hier in diesem fall wird sicher eh nur eine instanz von dem cache erzeugen
um den kompletten page-content auszugeben, von daher ist das denke ich mal nicht zwingend nötig.
wenn man jedoch nur einzelne elemente quer über den source hinweg cached (z.B. alle DB-queries)
macht es sicher sinn.