PSR-loggningsgränssnitt (och varför loggning är viktig)
Två funktioner i PHP som jag tror ofta överanvänds när det kommer till "debugging" är att använda echo och var_dump. Jag har pratat om detta i några olika artiklar om felsökning (som här och här ).
Och lika mycket som jag är ett fan av att använda en debugger, tror jag att det också är viktigt att implementera en typ av loggningssystem så att du eller din klient kan gå tillbaka och granska aktiviteten som har hänt i systemet som de eller deras användare har gjort. har, du vet, använt det.
Det finns dock två aspekter av att göra detta, särskilt om du funderar på att följa PSR-loggningsgränssnittet och de är:
- reglerna för själva loggningsgränssnittet,
- ett projekt som korrekt implementerar nämnda loggningsgränssnitt.
Så varför inte ta itu med båda i det här inlägget?
PSR-loggningsgränssnittet
PSR – loggningsgränssnittet (eller PSR-3) täcker ett antal saker som du kan läsa mer om på själva sidan.
Dessa inkluderar:
- Det grundläggande
- Meddelanden
- Sammanhang
- Hjälparklasser
- Paket
- Gränssnitt
- Logga nivåer
- Och mer.
Men för den här artikelns syften vill jag prata specifikt om själva gränssnittet, ett projekt som implementerar det, och varför det är viktigt.
Loggningsgränssnittet
På hemsidan för dokumentationen står det:
Detta dokument beskriver ett vanligt gränssnitt för loggning av bibliotek.
Huvudmålet är att tillåta bibliotek att ta emot ett PsrLogLoggerInterface-objekt och skriva loggar till det på ett enkelt och universellt sätt.
Ur utvecklingssynpunkt är det bra, eller hur? Jag menar, det ger ett enda, konsekvent sätt som vi kan satsa på för vilket loggningsbibliotek vi än väljer att använda i våra projekt. Jag kommer att täcka mitt föredragna bibliotek senare i artikeln.
För dig som är ny på objektorienterad programmering eller helt enkelt nyfiken på hur ett konsekvent gränssnitt gynnar oss, tänk på det så här: Oavsett vilket system du väljer kommer du garanterat att ha en viss uppsättning funktioner, tillstånd och så vidare. kan använda i din ansökan.
Att lägga till ett loggsystem som har en standard som det måste följa ger i slutändan en mängd fördelar oavsett vilket bibliotek du väljer (så länge det överensstämmer med PSR-3).
Testa Monolog
Monolog är mer eller mindre det de facto loggningsverktyget för PHP-applikationer.
Det är enkelt att lägga till projektet via Composer men det innehåller också en mängd olika sätt att mata ut data:
Monolog skickar dina loggar till filer, sockets, inkorgar, databaser och olika webbtjänster. Se hela listan över hanterare nedan. Specialhanterare låter dig bygga avancerade loggningsstrategier.
Personligen har jag använt det bara inom ramen för att skicka utdata till filer; Men att ha möjligheten att mata ut det till andra system (särskilt databaser som när man arbetar med WordPress) är trevligt. Den förmågan vill man förstås inte missbruka.
För det andra är det viktigt att inse att även om du kan instansiera Loggern inom en funktion eller en annan klass, så finns det andra, mer objektorienterade sätt att göra detta. PSR-3 täcker detta (som nämnts ovan).
Kort sagt, du vill se till att din klass accepterar en instans av en klass som implementerar LoggerInterface. Monolog implementerar nämnda gränssnitt, så det är inga problem.
Dessutom, vad händer när du har en grupp relaterade klasser som alla behöver implementera loggning?
- Ärver dessa klasser från en gemensam förälder?
- Implementerar dessa klasser en egenskap? (Detta är ett alternativ som en vän nyligen presenterade för mig.)
- Accepterar varje klass helt enkelt beroendet via konstruktorinjektion?
Det finns en mängd olika sätt som loggare kan läggas till i en klass och det beror på hur ditt projekt är organiserat.
Mer om loggning
Hur som helst är det viktigt att införa inloggning i en applikation av en mängd olika anledningar som att kunna felsöka när något inte beter sig som förväntat i både utveckling, iscensättning och speciellt i produktionen.