Probléma
Adatbáziselérés. Három lehetséges megoldás:
- Relációs adatbázis - nem OOP nyelv
- Relációs adatbázis - OOP nyelv
- OO adatbázis - OOP nyelv
Célok:
- Alkalmazás programozás - Adatbázis programozás szétválasztása <-> költség
- Teljesítmény
- Rugalmasság <-> Bonyolultság
- Már létező adatbázisok használata
Egy példa
Relational Database Access Layer Pattern
- Physical Access Layer: Adatbázishoz közeli
- Logical Access Layer: Alkalmazáshoz közeli
- Broker: A kettőt köti össze (elmaradhat)
-
HierarchicalView: Absztrakt ôsosztálya a
ConcreteHierarchicalView-knak. A requestDelete() a
destruktorhoz hasonló, commitáláláskor
törlôdik valójában.
-
ConcreteHierarchicalView: Az alkalmazás egy-egy
adattípusát reprezentálják. Tudja hogyan kell
kiírni/beolvasni magát az adatbázisba/ból.
-
PhysicalView: Absztrakt ôsosztálya a
ConcretePhysicalView-knak.
-
ConcretePhysicalView: Egy
adatbázistáblát reprezentál.
Denormalizáció esetén esetleg többet. Automatikusan
generálhatóak ezek az osztályok.
-
Transaction: Tranzakciót kezel.
-
ViewFactory: ConcreteHierarchicalViewkat gyárt, ha
már létezik, akkor azt adja vissza.
-
ViewCache: Tartalmazza a betöltött Viewkat.
-
Database: Adatbázikkezelô rendszert kezeli.
Következmények
- Alkalmazói programnak nem kell ismernie az adatbázis
szerkezetét.
- Megvalósítás: 0.5 - 30 emberév.
- Egyszerûen használható.
- Öröklôdés, többalakúság
nincs.
- Rugalmas (fôleg ha can QueryBroker).
- Bonyolultság: van-e QueryBroker.
- Teljseítmény: Alig lassabb a szinetk miatt.
- Meglévô adatbázis használható.
Implementáció:
- Tömeges
update?
- Kötegelt adatbázis elérés (vannak ilyen
cikkek).
- Multiple Read Patterns?
- Cursor Stability?
- Dinamikus SQL : Query Broker, statikus SQL: ConcretePhysicalView.
- Állandó adatbázis kapcsolat.
- Triggerek, tárolt eljárások nem
használhatóak.
Változatok
- ViewCache nem kell ha nincsenek hosszú tranzakciók.
- Traditical transaction monitors?
- Használható nem-relációs
adatbázisnál is.