Mióta világ a világ (na jó, azért nem olyan régóta) a fejlesztők rétegekre bontják az alkalmazásokat. DDD-s fejlesztés során is így járunk el. Viszont ha nem vezetünk be szabályokat, megkötéseket, akkor könnyen olyan helyzetben találhatjuk magunkat, hogy egyes komponenseket rossz helyre teszünk, illetve egyes részek ott is elérhetővé válnak, ahol az nem lenne kívánatos.
Manapság minden valamirevaló keretrendszerben elérhető valamilyen eseménykezelő, ami a publish/subscribe mintát követi. Ezekkel az eszközökkel flexibilisebb alkalmazásokat írhatunk, alacsonyabb lesz a "coupling" az osztályain között.
Múlt héten tartottam egy előadást a DDD-ről, amelynek az anyagát most megosztom veletek.
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.
A tranzakciókezelés alapvetően nem bonyolult dolog, már ami a használatát illeti. Ha minden művelet rendben végrehajtódik, akkor nincs teendőnk. Az érdekesebb viszont az, amikor valamilyen hiba lép fel. Ugye ilyenkor rollbackelni kell. Önmagában ez sem nagy szám, az adatbázis elintézi, amit el kell (ugye nem myisam-ot használunk!), viszont sokszor ez nem elég: el is kell takarítanunk magunk után. Hogy miket? Például a létrehozott/elmozgatott/törölt(!) fájlokat és minden egyéb olyat, amit a tranzakción belül hajtottunk végre.