Logowanie.

Logowanie zdarzeń jest dokładnie tym, co sugeruje nazwa - zapisywaniem zdarzeń zaistniałych w aplikacji. Zwykle czynność ta jest ściśle powiązania z logowaniem wiadomości o błędach i informacji o uwierzytelnianiu, aczkolwiek z logowania można skorzystać w znacznie szerszym zakresie. Można dzięki temu śledzić czynności użytkownika, przesyłanie formularzy i czynności związane z korzystaniem z baz danych. Logowania można nawet użyć do śledzenia wykonywania skryptu krok po kroku, co pozwala projektantom dokładnie określić, gdzie dokładnie pojawia się problem. W większości aplikacji internetowych to właśnie do logowania błędów i uwierzytelniania najczęściej stosuje się logowanie, aczkolwiek zawsze można trochę pokombinować i stosować to rozwiązanie do bardziej złożonych problemów.

Przy podejmowaniu decyzji, gdzie przechowywać logi, warto zadać sobie pytania postawione w drugim rozdziale. Ja osobiście preferuję przechowywanie logów w bazie danych, aby nie mieszać danych dynamicznych i statycznych. Jest jednak mały problem - co w przypadku, gdy nie można się połączyć z bazą?

Wtedy z pomocą przychodzi właśnie system plików. Kiedy piszesz klasę logującą zdarzenia do bazy, mądrze jest zabezpieczyć się(:D) i dodać do swojego loggera możliwość przełączania pomiędzy bazą a plikami. Przyjrzyj się poniższej, jakże prostej klasie logującej:

<?php
class Log
{
 var $settings;
 var $dbh;
 var $method;
 function Log(&$settings, &$dbh) 
 {
  $this->settings = &$settings;
  $this->dbh = &$dbh;
  $this->method = 'db';
  if (gettype($this->dbh) != 'resource') 
  {
   $this->dbh = mysql_connect($settings['db']['host'], 
                 $settings['db']['user'],
                 $settings['db']['pass']);
  } 
  if (gettype($this->dbh) != 'resource') 
  {
   $this->method = 'file';
  }
 } 
 function record($message) 
{
 switch ($this->method) 
 {
  case 'file' : 
return $this->recordToFile($message);
   break;
  case 'db' :
   return $this->recordToDb($message);
   break;  
 }
}
}
?>

Intencje są jasne - nie implementowałem więc metod “recordToDb" i "recordToFile" - nie ma w nich nic specjalnego, możesz sobie je samemu wyobrazić. Oczywiście musi być znana ścieżka do pliku, gdzie mają być logowane wiadomości - możemy więc dodać odpowiednią wartość do konfiguracji systemu, albo bezpośrednio w metodzie logującej. Możemy także rozszerzyć tą klasę w ten sposób, aby obsługiwała różne formaty logów lub wręcz stworzyć nowe podklasy dla różnych typów.

Możesz także użyć swojej wyobraźni i powiązać klasę logującą z obsługa błędów. Poniższy przykład demonstruje prosty sposób na skonfigurowanie obsługi błędów z funkcjami logującymi, a także wykorzystuje kilka poziomów debugowania, aby dokładnie określić, które informacje zostaną zapisane. Przyjmijmy, że wszystkie potrzebne klasy i plik konfiguracyjny zostały już załączone do tego kodu. Użytych jest także klika nowych funkcji obsługi błędów, ale ich działanie jest oczywiste, więc nie będę ich implementował.

<?php
define('DEBUG_LEVEL', 1);
require_once('class.log.php');
$log = &new Log(&$settings, NULL);
if (DEBUG_LEVEL > 0)
{
 $log->record('PID '.getmypid().' Started');
}
require_once('class.error.php');
$errorHandler = &new Error();
$errorHandler->setLog(&$log);
set_error_handler(array(&$errorHandler, 'setError'));
if (DEBUG_LEVEL > 0)
{
 $log->record('Trying database connection');
}
$dbh = @mysql_connect($settings['db']['host'], 
        $settings['db']['user'],
        $settings['db']['pass']);
if (gettype($dbh) != 'resource') 
{
 trigger_error('Unable to connect to database');
}
elseif (DEBUG_LEVEL > 0) 
{
 $log->record('Database connection established');
}

if (DEBUG_LEVEL > 0)
{
 $log->record('PID '.getmypid().' Ended');
}
?> 

W powyższym przykładzie, ustawienie stałej "DEBUG_LEVEL" na 0 powoduje logowanie tylko błędów krytycznych, podczas gdy ustawienie tejże stałej na 1 spowoduje zapisywanie wszystkich zdarzeń.

Najważniejszą dobrą praktyką związaną z logowaniem, jest samo użycie logowania. Logowanie jest potężnym narzędziem wspomagającym konserwację aplikacji. Jest jedynym sposobem na późniejsze odczytanie informacji o sytuacjach zaistniałych podczas użytkowania programu. Jeśli odpowiednio zapiszesz błędy, odnalezienie i usunięcie problemu może być naprawdę proste.

Prawdopodobnie zauważyłeś, że nie użyłem warstwy abstrakcji bazy danych w moich przykładach. Miałem kilka powodów - pierwszym z nich jest zwięzłość kodu. Po drugie, większość aplikacji w PHP nie wymaga przenośności na inne bazy danych. Jeśli już zajdzie taka potrzeba, powinniśmy używać tychże klas rozważnie i unikać ich niepotrzebnego użycia.

Pod koniec, chciałbym obalić częste twierdzenie, że warstwy abstrakcji bazy wymuszają jednolity dostęp do metod w całym kodzie. Każdy kto miał okazję pracować z ADODB i PEAR::DB wie, że pakiety te są jednym wielkim bałaganem, zapewniającym interakcję z bazami danych na wiele sposobów, z których każdy jest niezgodny z innymi pod względem teorii i implementacji. Mimo iż abstrakcja bazy często się przydaje, zwykle nie znajduje zastosowania na stronach WWW.