[PHP] nette manier om naar een globale Logger te verwijzen

[kinderpindakaas]

In een php project maak ik in een index.php file een Logger aan met:

code:

$log = new Logger("MyLog");

Elk keer als je een nieuwe Logger aanmaakt, genereert hij een nieuwe txt file op de server.
Ik wil me beperken tot 1 log file waar ik vanuit elke class naar toe kan schrijven.

Nu doe ik dat vanuit elke class als volgt:

code:

class Pietje {
    private .....
    private .....
        global $log;

    // Declare a public constructor
        public function __construct() { }
    
    public function get_RSSitems() { 
        $log->logWrite("werkt dit?");
        }

}

Het werkt wel, maar iets zegt me dat dit niet de juiste manier is.
Stel iemand vergeet later een globale Logger aan te maken.
Dan liggen al de logWrite() functies op zijn gat.

Hoe verwijs je op een stabiele manier naar globale objecten?

[X_lawl_X]

Maak gebruik van een singleton.

PHP:

<?php
class Logger
{
    private static $instance;
    
    public static function instance()
    {
        if (self::$instance === NULL)
        {
            self::$instance = new self();
        }
        return self::$instance;
    }
    
    protected function __construct() {}
    
    protected function __clone() {}
}

$logger = Logger::instance();

Of nog beter, maak gebruik van dependency injection

[ Voor 87% gewijzigd door X_lawl_X op 07-12-2011 20:47 ]

[kinderpindakaas]

Aha singleton, nog nooit eerder van gehoord, maar het werkt wel mooi.
Kun je jezelf ook nog eens dwingen dat er geen nieuwe Logger instance aangemaakt mag worden.

Ook wel goede uitleg -> http://www.talkphp.com/ad...leton-design-pattern.html

[HMS]

Singletons zijn evil. Maar dat merk je wel zodra je dingen wil gaan unit testen.

[kinderpindakaas]

HMS schreef op woensdag 07 december 2011 @ 21:04:
Singletons zijn evil. Maar dat merk je wel zodra je dingen wil gaan unit testen.

Hmm, hoe zou jij dit oplossen dan?

[alex3305]

HMS schreef op woensdag 07 december 2011 @ 21:04:
Singletons zijn evil. Maar dat merk je wel zodra je dingen wil gaan unit testen.

Want? Singletons zijn erg goed, wanneer ze op de juiste manier toegepast worden. Het is überhaupt onzin om bepaalde (doordachte) applicatie-ontwerpen als 'evil' neer te zetten. Er zal namelijk vast een reden voor zijn dat het zo bedacht is.

On-topic. Een Singleton logger is een goed idee. Wel zou ik dan een statische functie maken zoals Logger::log(object, string), waarbij je dan via get_class automatisch de klassenaam ophaalt en via de string-waarde de eventuele log kunt uitschrijven, zodat je weet wat er gedaan wordt. Dan hoef je maar één methode aan te roepen .

[kinderpindakaas]

alex3305 schreef op woensdag 07 december 2011 @ 21:19:
[...]

Wel zou ik dan een statische functie maken zoals Logger::log(object, string), waarbij je dan via get_class automatisch de klassenaam ophaalt en via de string-waarde de eventuele log kunt uitschrijven, zodat je weet wat er gedaan wordt. Dan hoef je maar één methode aan te roepen .

Daar was ik toevallig net mee bezig
Logger maakt voor mij al per dag een nieuwe log file aan.

Het liefste heb ik per log regel:
12-07-2011 @ 21:15:33 - Pietje:get_RSSitems() succesvol uitgevoerd

Kun je ook de functienaam opvragen van waaruit je aan het loggen bent?

[MueR]

Alleen als je hem als argument meegeeft aan je logger, of door het uitlezen van de stack trace (nee, dat wil je niet doen)

[alex3305]

MueR schreef op woensdag 07 december 2011 @ 22:27:
Alleen als je hem als argument meegeeft aan je logger, of door het uitlezen van de stack trace (nee, dat wil je niet doen)

Zou wel kunnen met de met de magic constant __FUNCTION__. Of het netjes is om te gebruiken is een tweede .

Let trouwens wel op dat met excessief loggen je ook de prestatie van je applicatie negatief kan beïnvloeden. Alhoewel dat je dat nu niet merkt, kan dat met het schalen van de applicatie wel lastig worden.

[YopY]

Idealiter gebruik je een logging framework waar je log levels mee kunt definiëren, dwz waarbij je logstatements (en de code die uitgevoerd wordt om die statements aan te maken) mee uit kunt schakelen afhankelijk of je in dev, test of productie zit. In dev zet je het logniveau dan op debug, in productie op warnings / errors. Google eens naar 'php logging framework' oid, dan kom je o.a. op zend_log en een PEAR iets voor logging uit.

[TJHeuvel]

Waarom kan je de logger klasse zelf niet static maken?

Oftwel:

PHP:

class Logger
{
 public static function Init($filename);
 public static function Log($line);
}

[YopY]

TJHeuvel schreef op donderdag 08 december 2011 @ 09:28:
Waarom kan je de logger klasse zelf niet static maken?

Oftwel:

PHP:

class Logger
{
 public static function Init($filename);
 public static function Log($line);
}

o.a. omdat het dan geen class is, maar een namespace (met wat scoping) . Je kunt dan immers net zo goed een normale log() functie ergens global neergooien.

[storeman]

Ik denk dat voor een logger een Singleton niet een heel goed idee is. Het is natuurlijk wel handig om te gebruiken en je hebt er weinig omkijken naar. Maar stel nu dat je twee logfiles wilt gebruiken. Éen voor database/query, 1 voor route logging, enz. Met een singleton moet je kunsten uit gaan halen en in de class LogClass defineren wat te doen. Dat is niet erg wenselijk. Door dependency injection kun je verschillende instances van een logger aanmaken en in verschillende classes (of dezelfde, maar verschillende instances) gebruiken.

Een van de weinige goede ideeen voor een Singleton is eigenlijk een database-connectie. Er zijn vast nog een paar implementaties die te rechtvaardigen zijn, maar zoveel mogelijk vermijden dus.

[RobIII]

Ik ben geen PHP kenner, maar ik zou eens kijken of 't niet op te lossen is met wat AOP. En dan heb ik best wat, op 't oog althans, relevante en interessante hits: [google=php aop]. Maar pin me er niet op vast want ik heb er niet mee gewerkt en alles op 't moment pas schuin gelezen.

http://blog.jonnay.net/ar...t-to-other-languages.html
http://stackoverflow.com/...5/aop-realization-for-php
http://stackoverflow.com/questions/2984570/codeigniter-aop

[ Voor 5% gewijzigd door RobIII op 08-12-2011 10:13 ]

[MueR]

alex3305 schreef op woensdag 07 december 2011 @ 22:32:
[...]

Zou wel kunnen met de met de magic constant __FUNCTION__. Of het netjes is om te gebruiken is een tweede .

Ja, en wat geeft die terug? De naam van de huidige functie, dus je log functie. Je zal deze in elke aanroep mee moeten geven, wat best een pokkewerk is. Met fatsoenlijke logmeldingen moet je ook wel kunnen afleiden wat er waar gaande is.

[kinderpindakaas]

Ik heb het nu nog even zo.

code:

$log = Logger::getInstance(); 
$log->log(get_class() . "::" . __FUNCTION__, "no data found");

Erg elegant is het niet.
Het is een relatief klein php project, maar een logging framework is misschien nog iets beter

[RobIII]

kinderpindakaas schreef op donderdag 08 december 2011 @ 11:18:

code:

$log = Logger::getInstance(); 
$log->log(get_class() . "::" . __FUNCTION__, "no data found");

Kan dat niet zo?

code:

Logger::getInstance()->log(get_class() . "::" . __FUNCTION__, "no data found");

[kinderpindakaas]

Dat is nog korter en werkt ook.
Thanks

[mbarie]

Sinds PHP 5.0 is er volgens mij ook de __METHOD__ magic constant :-)
Dus dan kan je zo doen:

code:

Logger::getInstance()->log(__METHOD__,"no data found");

[TJHeuvel]

dmv debug_backtrace kan je ook nog is de stacktrace ophalen, waardoor de methode parameter niet meer noodzakelijk is.

[kinderpindakaas]

Nu we het toch over singletons hebben.
Ik hoor zowel negatieve als positieve verhalen over het gebruik van singletons voor een database class.
Helaas heb ik te weinig tijd rond dit project om dit haarfijn uit te pluizen, dus wil ik de gok nog wel wagen.

Zelf maak ik veel gebruik van de ADOdb class om met mijn database te communiceren.

Nu wil ik bijvoorbeeld zelf een Database class maken waarbinnen er een connectie via ADOdb met de database gemaakt word.

Hoe zorg ik ervoor dat ik bijvoorbeeld de volgende aanroep kan doen zonder dat ik zelf in de Database class de functie update() heb?

code:

Database::getInstance()->update("hier query");

ADOdb heeft namelijk al een update() functie en die wil ik dus aanroepen

[RobIII]

kinderpindakaas schreef op donderdag 08 december 2011 @ 13:05:
Hoe zorg ik ervoor dat ik bijvoorbeeld de volgende aanroep kan doen zonder dat ik zelf in de Database class de functie update() heb?

Zorgen dat getInstance() het ADOdb object returned

[Janoz]

Een singleton in PHP is helemaal geen echte singleton. En precies bij dit probleem is dat goed te zien. TS wil 1 bestand. Om dat te bewerkstelligen heb je eigenlijk maar 1 ding nodig dat schrijft naar dat log bestand (om race condities te voorkomen).

Bij een echte singleton kun je een bestand aanmaken danwel openen wanneer de singleton gestart wordt en elke log aanroep kun je synchroniseren en weg laten schrijven in het log. Pas wanneer je applicatie afgesloten wordt, wordt je singleton weggegooid. Wat veel mensen hier een 'singleton' noemen is in werkelijkheid gewoon een 'thread local'. Alle php implementaties genereren een enkel object per request. Bij elk request moet opnieuw het object gemaakt worden en bij elk request wordt het log bestand opnieuw geopend. Wanneer er meerdere requests tegelijk afgehandeld worden zijn er dus rustig meerdere singletons actief die hetzelfde bestand (proberen te) openen.

Kortom, singletons in php zijn onzin. Een echte singleton heeft de restrictie dat er maar 1 instantie in de hele applicatie is. Bij php kom je niet verder dan 1 instantie per request.

[kinderpindakaas]

Ik heb her en der van het net wat bij elkaar geraapt.

code:

<?php

require_once('/adodb/adodb.inc.php');

class Database {
    // Store the single instance of Database
    private static $m_pInstance = null;
        
    private function __construct() { }
    
    public static function getInstance() {
        if (!self::$m_pInstance)
        {
            self::$m_pInstance = ADONewConnection('mysql://user:pwd@localhost/mydb');
        }

        return self::$m_pInstance;
    }  
        
    function __destruct() { }
        
}

?>

Gek genoeg lijkt het erop dat ADONewConnection geen class is meer een functie

[armageddon_2k1]

Janoz schreef op donderdag 08 december 2011 @ 13:25:
Kortom, singletons in php zijn onzin. Een echte singleton heeft de restrictie dat er maar 1 instantie in de hele applicatie is. Bij php kom je niet verder dan 1 instantie per request.

Is dat niet een beetje de aard van het beestje? Een php-script wordt immers uitgevoerd per request?

[RobIII]

kinderpindakaas schreef op donderdag 08 december 2011 @ 13:26:
Gek genoeg lijkt het erop dat ADONewConnection geen class is meer een functie

quote: http://phplens.com/lens/a...dodb.htm#adonewconnection

Whenever you need to connect to a database, you create a Connection object using the ADONewConnection($driver) function.

Maar hoe is dat verder relevant?

Ik zie overigens helemaal geen Update() methode waar jij 't over hebt, alleen een Execute()

[ Voor 47% gewijzigd door RobIII op 08-12-2011 13:39 ]

[Janoz]

armageddon_2k1 schreef op donderdag 08 december 2011 @ 13:30:
Is dat niet een beetje de aard van het beestje? Een php-script wordt immers uitgevoerd per request?

Uiteraard dat is mijn punt. Kijk je bijvoorbeeld naar .NET of JEE dan is dat heel anders. Daar heb je gewoon een application scope. Daar kun je echte singletons gebruiken. Daar kun je het pattern gebruiken om problemen op te lossen die door dat pattern opgelost zouden moeten zijn. Het bij php ook een singleton noemen geeft de illusie dat je daarmee specifieke problemen op zou kunnen lossen. Dan kun je in de literatuur wel lezen dat je probleem X oplost met het pattern, maar dat is dan helemaal niet zo. Ik zeg dan, noem het gewoon geen singleton.

[Xuj]

Als je toch bezig bent met het singleton patroon, kun je jezelf meteen ook het volgende aanleren:
Dependency Injection

Want iedereen houdt van testen.

[kwaakvaak_v2]

Janoz schreef op donderdag 08 december 2011 @ 13:49:
[...]

Uiteraard dat is mijn punt. Kijk je bijvoorbeeld naar .NET of JEE dan is dat heel anders. Daar heb je gewoon een application scope. Daar kun je echte singletons gebruiken. Daar kun je het pattern gebruiken om problemen op te lossen die door dat pattern opgelost zouden moeten zijn. Het bij php ook een singleton noemen geeft de illusie dat je daarmee specifieke problemen op zou kunnen lossen. Dan kun je in de literatuur wel lezen dat je probleem X oplost met het pattern, maar dat is dan helemaal niet zo. Ik zeg dan, noem het gewoon geen singleton.

Dat hangt er maar net vanaf wat 'probleem' je wilt oplossen in een stateless request. Als je wilt voorkomen dat je DB class maar één keer geinitieerd wordt voldoet het nog steeds aan de eis van een singleton patroon. Dat het in een statefull taal meer nut heeft is daar inrelevant aan. Grotere PHP applicaties, waarbij de code over meerdere php bestanden verdeeld is, kunnen nog steeds baat hebben bij een singleton patroon.

Dat het een aantal jaren geleden erg hip was om alles maar in singletons te proppen (*schuldig*) en dat het op die manier meer een anti-patern werdt is aan ander verhaal. Maar jouw preek over dat het geen echte singleton is omdat het per request scope is en niet op applicatie scope slaat als tang op een varken, want binnen php is het request op dat moment je applicatie scope.

[Janoz]

kwaakvaak_v2 schreef op donderdag 08 december 2011 @ 17:52:
[...]


Dat hangt er maar net vanaf wat 'probleem' je wilt oplossen in een stateless request. Als je wilt voorkomen dat je DB class maar één keer geinitieerd wordt per request voldoet het nog steeds aan de eis van een singleton patroon. Dat het in een statefull taal meer nut heeft is daar inrelevant aan. Grotere PHP applicaties, waarbij de code over meerdere php bestanden verdeeld is, kunnen nog steeds baat hebben bij een singleton patroon.

Even voor je aangepast . Het is met het php 'singleton' nog steeds mogelijk om een heleboel connecties met de database te krijgen. Gelukkig kan de database daar wel mee omgaan. Een geopend bestand daarentegen niet.

Dat het een aantal jaren geleden erg hip was om alles maar in singletons te proppen (*schuldig*) en dat het op die manier meer een anti-patern werdt is aan ander verhaal. Maar jouw preek over dat het geen echte singleton is omdat het per request scope is en niet op applicatie scope slaat als tang op een varken, want binnen php is het request op dat moment je applicatie scope.

Precies het probleem van de topicstarter laat zien waarom er een verschil is tussen de literatuur omtrent het singleton pattern en waarom het in de praktijk in php niet altijd toepasbaar is. Met het 'singleton' pattern zoals in php pak je alleen het lazy evaluation en het overal toegankelijk zijn van de class op. Een ander belangrijk punt, garanties kunnen bieden in een multithreaded omgeving, los je in php niet op. Dat maakt verder niet uit, zolang je je daar maar bewust van bent. Het klakkeloos maar een singleton noemen schept de onterechte illusie dat je alle problemen waarbij het singleton pattern als oplossing geboden wordt ook toe kunt passen.

[T-MOB]

kwaakvaak_v2 schreef op donderdag 08 december 2011 @ 17:52:
[...]
Dat hangt er maar net vanaf wat 'probleem' je wilt oplossen in een stateless request. Als je wilt voorkomen dat je DB class maar één keer geinitieerd wordt voldoet het nog steeds aan de eis van een singleton patroon. Dat het in een statefull taal meer nut heeft is daar inrelevant aan. Grotere PHP applicaties, waarbij de code over meerdere php bestanden verdeeld is, kunnen nog steeds baat hebben bij een singleton patroon.

Voor het probleem dat je wil oplossen (1 databaseconnectie, globaal aan te roepen) is een singleton een hele beroerde keuze. Je beperkt er namelijk de bruikbaarheid van je databaseklasse mee tot applicaties die maar met 1 databaseconnectie hoeven te werken. Als je de globale beschikbaarheid buiten de databaseklasse om verzorgt - bijvoorbeeld met een registry - heb je daar geen last van. Als je het heel simpel wil houden kun je zelfs met 6 regels klaar zijn:

PHP:

function DB() {
  static $conn;
  if(is_null($conn)) {
    $conn = new DatabaseConnection('foo','bar','quux');
  }
  return $conn;
}

Alle voordelen van een singleton database class, niet alle nadelen .

Verder zijn 99% van de PHP "singletons" zelfs binnen de request scope niet gegarandeerd "single" omdat bijna niemand __clone() en __wakeup() afvangt. Maar dat is vooral van theoretisch belang...

[Patriot]

Janoz schreef op donderdag 08 december 2011 @ 20:13:
[...]

Even voor je aangepast . Het is met het php 'singleton' nog steeds mogelijk om een heleboel connecties met de database te krijgen. Gelukkig kan de database daar wel mee omgaan. Een geopend bestand daarentegen niet.


[...]

Precies het probleem van de topicstarter laat zien waarom er een verschil is tussen de literatuur omtrent het singleton pattern en waarom het in de praktijk in php niet altijd toepasbaar is. Met het 'singleton' pattern zoals in php pak je alleen het lazy evaluation en het overal toegankelijk zijn van de class op. Een ander belangrijk punt, garanties kunnen bieden in een multithreaded omgeving, los je in php niet op.

Dat is natuurlijk nogal voor de hand liggend. Het is ook maar net hoe je het ziet. Als iedere request een thread in je applicatie is (valt best wat te zeggen voor die analogie, imo), dan is het inderdaad zo dat een singleton binnen PHP in die zin niet hetzelfde effect heeft als een singleton in zijn puurste vorm.

Dat maakt verder niet uit, zolang je je daar maar bewust van bent. Het klakkeloos maar een singleton noemen schept de onterechte illusie dat je alle problemen waarbij het singleton pattern als oplossing geboden wordt ook toe kunt passen.

Nouja, het is een singleton. De kanttekening die nodig is, is het feit dat je er rekening mee moet houden dat je applicatie mogelijk vaak meerdere keren gaat draaien. Als je dat doet met een .NET-applicatie moet je daar ook rekening mee houden. Dat doet imo niet af aan of het wel of niet een singleton is.

[RobIII]

T-MOB schreef op donderdag 08 december 2011 @ 20:22:
Je beperkt er namelijk de bruikbaarheid van je databaseklasse mee tot applicaties die maar met 1 databaseconnectie hoeven te werken.

Onzin. Uit de losse pols:

PHP:

class MySingleton 
{ 
    private static $instance = array();
     
    public static function instance($name = 'default') 
    { 
        if (!isset(self::$instance[$name]))
            self::$instance[$name] = new mysqli(...); //Afhankelijk van de name van de instance haal je natuurlijk even de juiste connectiegegevens op...
        return self::$instance[$name]; 
    } 

    protected function __construct() {} 
     
    protected function __clone() {} 

    //...
} 

$x = MySingleton::instance();
$y = MySingleton::instance('b');
$z = MySingleton::instance('c');

Et voila; "named instances"

[ Voor 12% gewijzigd door RobIII op 08-12-2011 21:07 ]

[storeman]

@armageddon, dat is volgens mij helemaal waar. Je scope is immers je request en niet je applicatie. Als je een C-app hebt en op meerdere computers hebt geinstalleerd, dan heb je ook meerdere instanties. Het is maar hoe je de scope defineerd. Alhoevwel Janoz natuurlijk niet ongelijk heeft, is dit inherent aan de PHP-methode.

[ReenL]

RobIII schreef op donderdag 08 december 2011 @ 21:03:
[...]


Onzin. Uit de losse pols:

PHP:

(...)

Et voila; "named instances"

Aldus, geen singleton.

@De rest: Come on niet weer deze discussie, het komt namelijk altijd neer op 2 groepen die het nooit met elkaar eens worden.

@TS:
Zoals je ziet zijn de meningen verdeeld over een singleton. In jou geval zul je sowieso de file moeten locken en vrijgeven zie: "flock" om te voorkomen dat 2 loggers door elkaar heen gaan schrijven.

Daarnaast lijkt het me in de meeste situaties niet verstandig om 1 globale logger te hebben, zo wil ik bijvoorbeeld bij een shop niet de gedetaileerde betaalinformatie tussen de login pogingen hebben staan bijvoorbeeld.

offtopic:
Als je dan toch mijn mening over singleton's wilt weten, nee dank u, een van de bedenkers van het pattern zelf is het met mij eens (of ik eigenlijk met hem).