Delphi - MS SQL adatbázis kezelés Delphi-ből

25. rész

forráskód letöltése
Cikksorozatunk mostani részében az elosztott, többrétegű rendszerek készítésének lehetőségeit boncolgatjuk. Az elosztott rendszerek története tulajdonképpen az egygépes alkalmazásoknál kezdődik, amikor adat és program ugyanazon a gépen foglalt helyet. Az adatbázisok méretének és a felhasználók számának növekedése miatt szükségessé vált, hogy az adatokat elkülönítve, központi helyen tárolják. Az ügyfelek elkérték a szükséges rekordokat, elvégezték rajtuk a műveleteket és az eredményt visszaküldték az adatbázisnak. Ezekben a rendszerekben azonban a kód mindig az ügyfelek gépein futott, az adatbázisok csak az adatok tárolásával foglalkoztak (fájl-kiszolgáló architektúra). Később a szerver oldalt ellátták adatbázis funkcionalitással, és a kliens oldal egyre inkább csak a megjelenítéssel kezdett el foglalkozni. Az ügyfél-kiszolgáló modell tehát két részből, két rétegből áll. Az ügyfél oldal végzi a műveletek egy részét, de leginkább megjelenítéssel foglalkozik, a kiszolgáló oldal végzi a többi műveletet, és az adatbázis kezelés egészét.

A fejlődés következő állomása, hogy az alkalmazásunk által megvalósított feladatot teljesen leválasztjuk az adatmanipulációs részekről, és egy külön rétegben valósítjuk meg azt. Így már három rétegünk van, és innen kezdve többrétegű, elosztott architektúráról beszélhetünk. A klasszikus háromrétegű alkalmazásokban a rétegek a következők:
  • adatszolgáltatási réteg,
  • üzleti szabályok rétege,
  • megjelenítési réteg.


Természetesen az alkalmazásunkat más logika szerint is részekre bonthatjuk, és annyi réteget valósíthatunk meg, amennyi nekünk tetszik.

A Delphi az elosztott adatbázis-alkalmazások írását a MIDAS technológiával támogatja. A MIDAS a programozó számára nem más, mint egy adag komponens, amelyek segítségével könnyen építhetünk magunknak többrétegű alkalmazásokat. Az egyes rétegeket különböző számítógépekre telepíthetjük, és azok különféle protokollokat használva kommunikálhatnak egymással, mint pl. a DCOM, a CORBA vagy TCP/IP.

Az egyes rétegeket megvalósító alkalmazások a következők.
  • Ügyfél alkalmazás. Az ügyfél alkalmazás a megjelenítéssel foglalkozik, és a felhasználóval való kommunikációra összpontosít. Nem kell foglalkoznia azzal, hogy az adatokat hogyan tároljuk, sőt, ideális esetben erről nem is tud semmit.
  • Az alkalmazás kiszolgáló (application server) feladata, hogy az ügyfél alkalmazások munkáját összefogja. Az adatbázis lekérdezések hozzá futnak be, ezeket ő továbbítja az adatbázis szerver felé, és az eredményeket is ő juttatja vissza az ügyfél alkalmazásoknak. E funkció miatt a réteget adat brókernek is nevezik (data broker).
  • Az adatbázis kiszolgálónak már csak az adatbázis műveletek végrehajtása marad (RDBMS).
  • A struktúra előnyeit a következő pontokba lehet összefoglalni:
  • Az üzleti logikát, vagyis alkalmazás tényleges feladatát elég egy helyen, központosítva megvalósítani. Így nem kell a különböző ügyfél alkalmazásokban, redundáns módon, többször is leprogramozni a megvalósítandó üzleti szabályokat.
  • Így az ügyfél alkalmazásunk sokkal kisebb lesz. (Vékony kliens.) Sőt nemcsak helyet nyerünk, de munkát is spórolhatunk, mert az ügyfelek telepítésénél nem kell minden egyes esetben az adatbázis kapcsolatot is telepíteni és beállítani (hiszen az adatbázisműveletekkel nem ez a réteg foglalkozik).
  • Ha az egész munkát több gépen több réteg, sőt a rétegek is több példányban végzik, akkor nyilvánvalóan sokkal jobb a hatékonyság. Terheléselosztást tudunk megvalósítani, illetve nagyobb az egész rendszer hibatűrése is. Hiszen ha egy számítógép kiesik, egy másikon ugyanaz a réteg-példány még működik.


A három rétegből Delphi-ben leginkább az ügyfél alkalmazást és a középső réteget szoktuk megvalósítani, adatbázisszerverünk pedig az SQL Server.

Általánosságban egy többrétegű adatbázis-alkalmazás fejlesztése a következő lépésekből áll.
1. Az alkalmazás szerver, vagyis a középső réteg elkészítése.
2. Az alkalmazás szerver telepítése és regisztrációja.
3. Az ügyfél alkalmazás megvalósítása.

Az alkalmazás szerver elkészítése nem sokban különbözik attól, amikor egy hagyományos adatbázis alkalmazást fejlesztünk. A legfontosabb különbséget az jelenti, hogy az alkalmazásszerver provider-eken keresztül teszi elérhetővé az adatokat. Többféle providert is találtunk a Delphi4-ben, használhattuk a TProvider vagy a TDataSetProvider komponenseket, vagy használhattuk a TDBDataSet leszármazottak Provider property-jét is. Az 5-ös változattól kezdve azonban már csak a TDataSetProvidert használhatjuk. A Provider property-ként megszűnt, a TProvider komponenst is törölték, és bár a Provider unitban szerepel a következő bejegyzés:
  TProvider = class(TDataSetProvider)
  end;
ez természetesen nem azt jelenti, hogy a 4-es változat TProperty-je azonos lenne az 5-ös változat TDataSetProvider-ével.

Kezdjünk egy új alkalmazást és a File/New oldal Multitier füléről válasszunk egy adatmodult. A Remote Data Module választásával COM Automation szervert írhatunk, ami az ügyfelekkel DCOM-on, socket-eken vagy OLEnterprise-on keresztül kommunikál. Ha az MTS Data Module-t választjuk, akkor Active Library-t hozunk létre, amit az ügyfelek a Microsoft Transaction Serveren keresztül érnek el. Végül ha a CORBA Data Module-t választjuk, akkor corba szervert írhatunk.

Az adatmodulra feltehetjük a szokásos adatbázis komponenseket, mint pl. tábla, query, tárolt eljárás; és beállíthatjuk őket, hogy a szokásos módon érjék el az adatbázist. Ezután minden olyan adathalmazhoz, amit az ügyfél alkalmazásból el szeretnénk érni, tegyünk az adatmodulra egy-egy provider (TDataSetProvider) komponenst. A provider komponensek DataSet property-jét beállítva kapcsolhatjuk őket össze a dataset komponensekkel. Ezután meg kell írnunk azokat a funkciókat, amiket az alkalmazásunknak meg kell valósítania, vagyis le kell programoznunk az üzleti logikát. Mentés és fordítás után már csak a regisztráció és a telepítés van hátra.
Ha az alkalmazás szerverünk DCOM-ot, socket-eket vagy OLEnterprise-t használ kommunikációs protokollként, akkor Automation szerverként funkcionál és ugyanúgy be kell regisztrálnunk a Windowsban, mint az ActiveX vagy COM szervereket. Ha a Transaction Servert használjuk, az alkalmazás szerverünket nem kell beregisztrálnunk, de telepítenünk kell azt az MTS-ben (Run|Install MTS Objects). Ha CORBA-t használunk, a regisztráció nem kötelező, csak ajánlott.

Az ügyfél alkalmazás megírása ugyanazt jelenti a többrétegű környezetben, mint az ügyfél-kiszolgáló architektúrában. A különbség csak annyi, hogy a többrétegű ügyfélnek használnia kell bizonyos komponenst arra, hogy elérje az alkalmazásszervert, illetve használni kell egy vagy több TClientDataSet komponenst, hogy kapcsolódhasson az alkalmazásszerver providereihez. A vizuális komponensek ehhez a TClientDataSet-hez lesznek rendelve az alkalmazás szerver táblái és query-jei helyett.

Kezdjünk egy új alkalmazást, és tegyünk bele egy adatmodult. Az adatmodulra tegyünk egy olyan komponenst, ami majd kapcsolatot fog tartani az alkalmazás szerverrel. Hogy ez konkrétan melyik komponens, az természetesen attól függ, milyen kommunikációs protokollt használunk. Ha DCOM-ot, a komponens a TDCOMConnection, ha Windows socket-eket, akkor a TSocketConnection, ha OLEnterprise-t, akkor TOLEnterpriseConnection, végül ha CORBA-t, akkor TCorbaConnection. Ez a komponens az IProvider nevű interfészt valósítja meg, az ügyfél alkalmazás client dataset komponense ezen a felületen keresztül fog kommunikálni az alkalmazás szerver providereivel. A programozónak mégsem kell erre az interfészre odafigyelnie, csak indirekt módon használja a client dataset metódusain keresztül. Természetesen, ha nagyon muszáj, direkt módon is el lehet érni.

A kapcsolattartó komponens kiválasztása után hivatkozunk az alkalmazás szerverre. A beállítandó property-k természetesen attól függnek, hogy melyik komponenst választottuk. Ezután elhelyezünk az adatmodulon annyi TClientDataSet komponenst, amennyire szükségünk van, és a RemoteServer property-n keresztül hivatkozunk a kapcsolattartó komponensre. Végül beállítjuk az egyes TClientDataSet komponensek ProviderName property-jét. Ha tervezési időben csatlakozunk az alkalmazás szerverhez, akkor a ProviderName mezőben választhatunk az elérhető providerek közül. Az ügyfél alkalmazás többi részét a szokásos módon programozzuk.

A két alkalmazás megírásának sorrendje nem teljesen mindegy. Ha az alkalmazás szervert írjuk meg korábban, teszteljük, és ha jól működik, sokkal könnyebb lesz megírnunk az ügyfél alkalmazást, hiszen a kapcsolat részt már tervezési időben tesztelgethetjük.


Példaprogram

Példaképpen készítünk egy alkalmazás szervert és egy kliens alkalmazást.

Az alkalmazásszerver készítésének a lépései a következők.
1. File/New Application.
2. File/New, Multitier fül, Remote Data Module ikon. A wizardban a class name legyen MyDataServer, a többi jellemzőt ne változtassuk meg. Az OK gombra kattintva létrejön egy új unit, benne a TMyDataServer objektummal, ami a TRemoteDataModule közvetlen leszármazottja. Ő fogja megvalósítani azt az interfészt, amin keresztül a client dataset kommunikálni tud az alkalmazás szerverrel. Az IMyDataServer nevű interfész az IDataBroker interfész leszármazottja lesz.
3. Az adatmodul lapra teszünk egy TDatabase komponenst, amit a Test1 aliason keresztül összekötünk az SQL Server pubs adatbázisával. Egy TTabla komponensen keresztül megszólítjuk a titles táblát. Továbbá leteszünk egy TDataSetProvider komponenst a MIDAS lapról, ez fogja szolgáltatni a tábla adatait az ügyfelek felé.
4. Fordítás után az alkalmazás szervert be kell regisztrálni, ami nagyon könnyen megy, egyszerűen csak el kell indítani egyszer.

A kliens alkalmazás készítésének lépései:
1. File/New Application
2. Adjunk a projecthez egy új adatmodult. Az adatmodulra tegyünk a MIDAS lapról egy TDCOMConnection komponenst. A ServerName property-ben kell beállítani az alkalmazás szerver nevét. Nyissuk le a property lenyíló dobozát, és válasszuk ki az előbb megírt alkalmazás szervert. A példában appsrv.MyDataServer. A ServerGUID mező ekkor automatikusan kitöltődik. Nagyon fontos a ComputerName property kitöltése is akkor, ha az alkalmazás szerver egy másik gépen fut. Ha nem adunk neki értéket, a komponens feltételezi, hogy az alkalmazás szerver az ügyfél gépen van vagy legalább van registry bejegyzése. Az ObjectBroker property-t akkor kell megadni, ha az alkalmazás szervert egyszerre több gép is szolgáltatja. Az object broker a szerverek listáját tartalmazza, amiből a komponens a csatlakozáskor egyet elkér. Ha a szerver nem elérhető, veszi a következőt a listáról. Sikeres kapcsolatfelvételkor a bróker megjegyzi a szerver paramétereit, és a következő csatlakozáskor ezeket felhasználja. (Megjegyzés: az OLEnterprise és CORBA technológiáknak saját bróker-mechanizmusuk van, ilyenkor ne használjuk ezt a property-t.)
3. Tegyünk egy TClientDataSet property-t az adatmodulra. Ezzel létrehozzuk a kapcsolat ügyfél oldali interfészét is. A RemoteServer property-be írjuk be a TDCOMConnection objektum nevét. A ProviderName property-ben állítsuk be az alkalmazás szerverbeli provider nevét, amihez majd a client dataset csatlakozni fog. Ha rákattintunk a property-re az Object Inspectorban, a már korábban megírt alkalmazás szerverünk elindul, és szolgáltatja az elérhető providerek nevét.
4. Innentől kezdve a client dataset-eket úgy tekinthetjük, mintha közvetlenül az SQL Server adathalmazait látnánk, és a hagyományos módon programozunk tovább. Tegyünk a Form-ra egy DBGrid-et és egy navigatort, a datamodulra egy datasource komponenst, és rajta keresztül kössük össze a két vizuális komponenst a client datasettel.
5. Futtassuk az alkalmazást.

MS SQL cikksorozat

MS SQL adatbázis kezelés Delphi-ből - 1. rész
MS SQL adatbázis kezelés Delphi-ből - 2. rész
MS SQL adatbázis kezelés Delphi-ből - 3. rész
MS SQL adatbázis kezelés Delphi-ből - 4. rész
MS SQL adatbázis kezelés Delphi-ből - 5. rész
MS SQL adatbázis kezelés Delphi-ből - 6. rész
MS SQL adatbázis kezelés Delphi-ből - 7. rész
MS SQL adatbázis kezelés Delphi-ből - 8. rész
MS SQL adatbázis kezelés Delphi-ből - 9. rész
MS SQL adatbázis kezelés Delphi-ből - 10. rész
MS SQL adatbázis kezelés Delphi-ből - 11. rész
MS SQL adatbázis kezelés Delphi-ből - 12. rész
MS SQL adatbázis kezelés Delphi-ből - 13. rész
MS SQL adatbázis kezelés Delphi-ből - 14. rész
MS SQL adatbázis kezelés Delphi-ből - 15. rész
MS SQL adatbázis kezelés Delphi-ből - 16. rész
MS SQL adatbázis kezelés Delphi-ből - 17. rész
MS SQL adatbázis kezelés Delphi-ből - 18. rész
MS SQL adatbázis kezelés Delphi-ből - 19. rész
MS SQL adatbázis kezelés Delphi-ből - 20. rész
MS SQL adatbázis kezelés Delphi-ből - 21. rész
MS SQL adatbázis kezelés Delphi-ből - 22. rész
MS SQL adatbázis kezelés Delphi-ből - 23. rész
MS SQL adatbázis kezelés Delphi-ből - 24. rész

MS SQL adatbázis kezelés Delphi-ből - 25. rész

MS SQL adatbázis kezelés Delphi-ből - 26. rész
MS SQL adatbázis kezelés Delphi-ből - MS SQL 27. rész
MS SQL adatbázis kezelés Delphi-ből - MS SQL 28. rész
MS SQL adatbázis kezelés Delphi-ből - MS SQL 29. rész
MS SQL adatbázis kezelés Delphi-ből - MS SQL 30. rész
MS SQL adatbázis kezelés Delphi-ből - MS SQL 31. rész
MS SQL adatbázis kezelés Delphi-ből - MS SQL 32. rész