9. Háttérlogika – Üzleti logika réteg
9.
81
Háttérlogika – Üzleti logika réteg
A jegyzetben több helyen is bemutattuk a rétegezett architektúrát és lehetséges rétegeket. Ezen rétegek közül a megjelenítés és a perzisztencia szükségessége, feladata magától értetődő: szükség van a felhasználói események minél gyorsabb lekezelésére és szükség van az adatok tartós tárolására is. Az üzleti logika, vagy más néven a szolgáltatás réteg feladata azonban nem ilyen világos. Ha megnézzük a ma használt alkalmazás architektúrákat akkor gyakran látjuk, hogy ez a réteg mintha hiányozna.
33. ábra A 33. ábra A oszlopa mutatja JEE által javasolt szolgáltatás réteg kiemelt helyzetét. A B ábra azt az esetet ábrázolja amikor a szolgáltatás réteg nincs külön kiszervezve, hanem az eseménykezelés részeként van lekódolva. Ekkor a megjelenítés közvetlenül a perzisztencia biztosító réteggel kommunikál. Ez gyakran előfordul amikor a Web konténerben futó servlet-ből JDBC-n keresztül közvetlenül az adatbázist szólítjuk meg. Bár e tervezési minta amikor a szolgáltatás és a megjelenítés réteg összeolvad egyszerű komoly problémákat okoz amikor például nem csak GUI hanem más módon is hozzáférhetővé kell tennünk az alkalmazás logikánkat (pl.: van egy okos kliensünk), a gyorsítótárazást is nehézkesen használjuk ebben a modellben. A viszony réteg szintű klaszterezés szintén megvalósíthatatlan. A nagyon egyszerű alkalmazások kivételével tehát nem érdemes ezt a tervezési mintát követnünk. A C ábra azt az esete mutatja be amikor az üzleti logika a perzisztencia rétegben valósul meg. Ennek a tipikus módja tárolt eljárások használata. A PHP ökorendszerben írt szoftverek nagy része ezt a mintát követi. Vegyük észre, hogy ez esetben a programunk jó részében nem használjuk az objektum orientált paradigmát mivel a tárolt eljárások rekordok és nem objektumok szintjén működik. A biztonság egy másik olyan kérdés amit ez esetben magunknak kell megoldani gyakran a tárolt eljárásokhoz csapott „where” feltételekkel. Ez a módszer tehát nem igazán produktív. E két példából jól látható annak az előnye, ha van egy szolgáltatás rétegem. Ez a réteg különös jelentőséggel bír az AJAX-ot aktívan használó alkalmazásoknál mivel a itt tudunk hatékony gyorsítótárazás megoldásokat biztosítani. Nem mindegy, hogy a felhasználónként beérkező másodpercenkénti kéréseket memóriából vagy adatbázisból szolgáljuk ki. Az sem mindegy, hogy a szolgáltatás logikában egy objektumorientált nyelven (pl.: JAVA) vagy egy csak adatmanipulációra szakosodott nyelven valósítom meg (SQL). Azokat a keresztülívelő problémákat/ /szolgáltatásokat mint a biztonság, naplózás, tranzakciók, ... nem mindegy, hogy hogyan veszem igénybe, valósítom meg. Egy jó szolgáltatás réteget kiszolgáló köztesréteg/tároló ezeket a szolgáltatásokat magas szinten biztosítja a programozó számára. Egy jó kérdés az, hogy mit érdemes a szolgáltatás rétegbe helyezni és mit a többi rétegbe. Egy ökölszabályként azt mondhatjuk, hogy ami a felhasználói eseménykezeléshez © Bilicki Vilmos, SzTE
www.tankonyvtar.hu