Tweetjeim

Legújabb hozzászólások

szjani

2014. április 18. 22:07

Köszi! Képeket valóban akartam, de nincs normális eszközöm hozzá, ami igényes kimenetet is produkál. :( - Hexagonal arch...

inf3rno

2014. április 18. 14:23

Jó cikk, nekem teljesen érthető volt, szépek a példák is. Annyi megjegyzésem lenne, hogy egy kép többet mond ezer szónál...

Jordan

2014. április 1. 17:31

Interesting project. I recommend using ORM Designer (www.orm-designer.com)in conjunction with Doctrine. It's a great to...

mindegy

2014. február 4. 14:55

Tetszik! A DDD-ről, CQRS-ről még nem hallottam de ha ezekkel így lehet szoftvert fejleszteni, akkor rossz már nem lehet....

szjani

2013. június 7. 21:38

"Maga az event egy string..." - itt valóban pongyolán fogalmaztam, javítom. A több esemény kezelésére a példa:...

Loggolás másként - lf4php

Java fejlesztőként találkoztam az slf4j-vel, ami nem más, mint egy logging facade. Önmagában nem sok mindenre jó: mint ahogy a neve is sejteti, elrejti előlünk a konkrét megvalósítást, absztrakt felületet ad. Használatával bármikor válthatunk egyik logging keretrendszerről a másikra. Innen vettem az ötletet, és nem titkoltan az slf4j forráskódját bújva készítettem el az lf4php-t. Egy korábbi írásomban már megemlítettem, most bemutatom, hogyan kell használni, illetve milyen irányelvek vezettek a tervezése és fejlesztése során.

Használat

Az osztályainkban mindössze el kell kérni egy loggert a LoggerFactory-tól és már mehet is a móka. Például:

Jaj, mi ez a statikusság, miért nem DI?!

Jómagam nagy híve vagyok a DI-nak, illetve a DIC használatának. Miért nem adom át akkor (injektálom) a logger objektumokat az osztálynak? Ennek több oka is van:

  1. A DIC konfigurációs fájlomat nem kell megtömni logger függőségekkel.
  2. Az osztályaimat nem kell setLogger() metódushívással díszítenem, illetve valamiféle LoggerAware interfészt implementálnom.
  3. Ha a loggolási szintet finomhangolni akarom, elég csak a megfelelő namespace nevével regisztrálnom egy loggert és onnantól az lesz érvényben minden az alatt található osztályra nézve.
  4. Véleményem szerint a loggolásnak mindenhonnan könnyen elérhetőnek kell lennie, mivel ez egy elemi funkció.

Namespace szerinti konfigurálás

Tegyük fel, van egy lib, ami lf4php-t használ. Tele van szórva különböző szintű logokkal. Mi is lf4php-t használunk a saját kódunkban. Fejlesztés közben viszont nem szeretnénk minden debug üzenetet látni, elég csak az, ami a mi kódunkból jön. Az is elképzelhető, hogy még finomabb beállításokat szeretnénk: hibajavítás során csak abból az osztályból jövő trace logokat szeretnénk látni (és nem akarunk elveszni a log tengerben), amin épp dolgozunk.

Mindez elérhető úgy, hogy a finomhangolni kívánt namespace, vagy osztály nevével beregisztrálunk egy megfelelően konfigurált loggert. A log4php natívan támogatja ezt, nézzük meg, Monolog esetén hogy járhatunk el.

Ha a 'foo\bar' egy namespace és van pl. egy 'foo\bar\Service' osztályunk, akkor az abból jövő összes log esemény a fenti $monolog loggernek kerül átadásra. Egészen addig, amíg be nem regisztrálunk egy másik loggert mondjuk a 'foo\bar\Service' névvel. Tehát az lf4php megkeresi a hierarchia szerinti legközelebbi regisztrált loggert. Ezért érdemes mindig a __CLASS__ névvel elkérni a példányt.

Paraméteres log üzenetek

Az slf4j-hez hasonló módon az lf4php is támogatja a paramétereket. Az üzenetbe tetszőleges számú '{}' párt tehetünk, amelyek lecserélődnek a paraméterben átadott tömb megfelelő elemeivel.

Kivételeket harmadik, opcionális paraméterként adhatunk át.

Oké, de hogy használom mondjuk a log4php-vel?

Az lf4php egy interfészt ad, valamint néhány alapvető segéd metódust, amit aztán a binderek implementálnak, illetve felhasználhatnak. Ahhoz, hogy a log4php-t használjuk, szükségünk lesz az lf4hp-logf4php csomagra. Ez köti össze a két libet. A konfigurációhoz mindösszesen a következőre van szükség.

A binderek nyilvánvalóan függenek az lf4php-től. Ha log4php helyett mondjuk monolog-ot szeretnénk használni, dobjuk ki a meglévő bindert és használjuk a monolog bindert. Az alkalmazásunkban kizárólag a konfigurációt kell megváltoztatni.

És a PSR-3?

Igen, időközben megalkották a PSR-3-mat, ami alapvetően pozitívum, csak épp a megvalósítással (mármint az interfész kapcsán) van néhány problémám. Mindazonáltal úgy gondolom, hogy az lf4php-nek van létjogosultsága. Egyrészt az interfész véleményem szerint tisztább (gondolok itt a paraméterekre, valamint az 'exception' kulcsra). Ráadásul a két megoldás megfér egymás mellett is. Ha egy framework PSR-3 loggerre dependál és mi mondjuk lf4php-t használnánk, akkor felkonfiguráljuk a monologot és hagyjuk, hogy a libek a preferált interfészen keresztül használják azt. Egyébként tervezem, hogy készítek egy PSR-3 bindert, amivel aztán bármilyen "standard" logging keretrendszert felhasználhatunk lf4php-n keresztül.

  • Az e-mail cím nem jelenik meg az oldalon, bizalmasan kezelem.

szjani

2013. január 24. 17:40

Itt (https://github.com/php-fig/log/issues/7) volt egy \"kisebb\" harcom. Elbuktam, dehát nem kötelező nekem PSR-3-mat használnom.

Az adatbázis kezeléshez Doctrine-t használok Az oldal Zend Framework-re épül