PHP adatobjektumok használata

  • Szükséges tudás: Hasznos a PHP és az SQL ismerete
  • Igényel: Webszerver (például Apache), betöltve a PHP-t, és relációs adatbázis-kezelő rendszer, amely képes OEM-kapcsolatra (például MySQL); Az ODBC és a 2. Tan választható extrák
  • Projekt idő : 1-3 óra (vagy több, attól függően, hogy milyen tanulási utad van és milyen képességekkel bírsz)
  • Forrás fájl

Ez a cikk először itt jelent meg 231. szám of .net magazin.

A dinamikus weboldal- és alkalmazásfejlesztés manapság mindennaposabbnak tűnik, mint a statikus weboldal-készítés, és dinamikus fejlődéssel együtt jár az adatok tárolásának szükségessége is.

A PHP nyelv mellett használt népszerű adatbázis-kezelő rendszer a MySQL adatbázis, a Microsoft SQL, a PostgreSQL és az Oracle is meglehetősen gyakori. A PHP fejlesztői csoport kezdetben megkönnyítette a kapcsolatot a PHP és az adatbázis rendszerek között olyan adatbázis-rendszer-specifikus funkciók használatával, mint például:

MySQL: erőforrás mysql_query (string $ lekérdezés [, erőforrás $ link_identifier])
Microsoft SQL: vegyes mssql_query (string $ lekérdezés [, erőforrás $ link_identifier [,
int $ batch_size = 0]])
PostgreSQL: erőforrás pg_query ([erőforrás $ kapcsolat], karakterlánc $ lekérdezés)
Oracle adatbázis: bool oci_execute (erőforrás $ utasítás [, int $ mode = OCI_
COMMIT_ON_SUCCESS])



Amint az a definíciókból kiderül, nincs szabványosított formájuk, így ha az Oracle-ről MySQL-re kellene cserélnie az adatbázis-rendszerét, akkor át kell dolgoznia a kódot, és módosítania kell az adatbázishoz való csatlakozás módját. A PHP-ben az adatbázis-összeköttetés megismerésének tövise is: nem csak a például PostgreSQL-ből adhatja át a tudását a Microsoft SQL-be.

01. A PHP Data Objects (PDO) filozófia

Szerencsére létezik adatbázis-kapcsolati megmentő a PHP-ben - ez pedig a hárombetűs PDO rövidítés, amely a PHP Data Objects rövidítést jelenti. A PDO könyvtár ötlete az, hogy szabványosított alapot biztosít, amelyen keresztül csatlakozhat bármely olyan relációs adatbázis-kezelő rendszerhez (RDBMS), amely lekérdezhető az SQL segítségével.

Kis szerencsével az OEM-készítő szkriptnek létre kell hoznia egy érvényes táblázatot, hasonlóan a fentiekhez, az adatbázisában

Kis szerencsével az OEM-készítő szkriptnek létre kell hoznia egy érvényes táblázatot, hasonlóan a fentiekhez, az adatbázisában

A cikk írásakor ez magában foglalja a CUBRID, Firebird, Interbase, IBM DB2, Informix, Microsoft SQL Server, MySQL, Oracle, PostgreSQL, SQLite, 4D - és minden olyan adatbázist, amely ODBC-n keresztül csatlakoztatható.

Gyors fogalmi példát véve a változásokra, korábban láthattuk:

_ lekérdezés ($ sql);

Most egy szabványosított funkciókészletet látunk, amely kissé így néz ki:

$ conn-> lekérdezés ($ sql);

De ez egyelőre elégséges elmélet - vessünk egy pillantást erre az erőteljes könyvtárra! Az OEM-nek két külön aspektusa van, az első a kapcsolat - ami egyértelműen szükséges elem -, míg a második oldal a lekérdező elem.

02. Csatlakozás adatbázis-kezelő rendszerhez

Mielőtt bármilyen adatot lekérdeznénk, csatlakoznunk kell egy már telepített és beállított adatbázis-kezelő rendszerhez. Az első példához csatlakozunk egy MySQL adatbázishoz, amely a localhoston fut.

OEM ('mysql: host = localhost; dbname = sajátneved', 'felhasználónév', 'jelszó');

Hasonlítsuk össze ezt a PostgreSQL adatbázishoz való csatlakozással:

w OEM ('pgsql: host = localhost; dbname = yourdbname', 'felhasználónév', 'jelszó');

A kapcsolatok szabványosítottak az első példának köszönhetően, amely ugyanazt a funkciót használja, míg a második a szabványosított adatforrás név (DSN) rendszert használja. Kezdheti belátni, mennyire könnyű, ha csak át akar váltani az egyik adatbázis-kezelő rendszerről a másikra.

A Drupal 7 az OEM absztrakciós rétegei mögött PDO található. Az ezekről szóló hivatalos Drupal dokumentáció nagyszerű módja annak, hogy többet megtudjon az integrációról

A Drupal 7 az OEM absztrakciós rétegei mögött PDO található. Az ezekről szóló hivatalos Drupal dokumentáció nagyszerű módja annak, hogy többet megtudjon az integrációról

03. Az eredmények lekérdezése és olvasása

Az adatok lekérdezése kezdetben érdekesebb, mint az adatok létrehozása, és mivel ez az adatkapcsolatról, nem pedig az SQL-ről szóló oktatóanyag, egyenesen a lekérdezéshez jutunk, és később meglátogatjuk a létrehozást, a beszúrást, a frissítést és a törlést.

Feltételezzük, hogy van egy táblánk profil , amely különféle részleteket sorol fel egy hipotetikus webalkalmazás felhasználóiról. Példaként futtassunk egy gyors profilletöltést SQL-ben az OEM-n keresztül, majd egyszerűen visszhangozzuk a teljes neveket. Figyelje meg, hogy a lekérdező függvény hogyan használható iterátorként - egy olyan funkció, amely egy memóriában tárol egy mutatót egy tömb aktuális elemére (vagy ebben az esetben az eredményhalmazra). Ha ezt kombináljuk a az egyes ciklus lehetővé teszi a sorok elérésének gyors és egyszerű módját:

$ conn = új $ conn = új $ conn = új $ conn = neforeach ($ conn-> lekérdezés ('SELECT * FROM profil') mint $ sor) echo
$ row ['teljes név'];

Természetesen ez gyors és egyszerű, de aligha akarunk minden sort beolvasni; ezért adjunk hozzá néhány feltételhez változó befecskendezést. Itt egy robusztusabb lekérdezési módszert alkalmazunk, amely előkészíti a lekérdezést és beadja a változókat:

$ query = $ conn-> Prepar ('SELECT * FROM profil WHERE felhasználónév =
: felhasználónév LIMIT 1 ');
$ query-> bindParam (': felhasználónév', 'knightofarcadia');
$ query-> execute ();
$ profil = $ lekérdezés> lekérés (OEM: FETCH_ASSOC);
echo $ profile ['teljes név'];

A fenti kód csak egy profilra korlátozza a profiltábla keresést a felhasználónévvel knightofarcadia . Az első példánkhoz hasonlóan ezután is egyszerűen kinyomtatja a teljes nevet - de biztosan el tudja képzelni, hogy felépít egy teljes XHTML oldalt, amelyre átadják az adatokat.

A PHP Data Objects könyvtár segíti a Facebook HipHop Engine működését, amely akár 50 százalékkal is csökkentheti a webszerverein a CPU-felhasználást.

A PHP Data Objects könyvtár segíti a Facebook HipHop Engine működését, amely akár 50 százalékkal is csökkentheti webszerverein a CPU-felhasználást.

Előfordulhat azonban, hogy egynél több sort adunk vissza a lekérdezésünkbe, és ezért képesek vagyunk használni a elhozni módszer iterátorként. Itt egy másik lekérdezést látunk, amely többsoros eredménykészletet ad vissza:

$ query = $ conn-> Prepar ('SELECT * FROM profil WHERE szülőváros =: szülőváros');
$ query-> bindParam (': szülőváros', 'Wessex');
$ query-> execute ();
foreach ($ query-> fetch (PDO :: FETCH_ASSOC) mint $ sor) {
echo $ row ['teljes név'];
}

A fenti példány a profiladatbázisban keres, és visszaadja az összes olyan profilt, amely rendelkezik a szülőváros állítva Wessex . A elhozni metódust használnak az összes ilyen eredmény visszaadására, és egy egyszerű példaként egyszerűen kinyomtathatjuk a teljes nevet a képernyőre - bár ez bonyolultabb XHTML oldal művelet lehet.

04. Létrehozás

Bár támogatnám egy SQL-ben közvetlenül létrehozott adatbázis-struktúra létrehozását közvetlenül az adatbázis-kezelő rendszerbe, lehetséges az adatbázis-táblák dinamikus létrehozása az OEM által előkészített SQL használatával:

$ createql = $ conn-> Prepar ('CREATE TABLE profilok (VARCHAR felhasználónév (64), teljes név VARCHAR (128), szülővárosi VARCHAR (128)'));
$ conn-> lekérdezés ($ teremtql);

Kérjük, ne feledje, hogy a lekérdezés Az objektum ebben az esetben nem ad vissza semmi értékeset, mert ez egy létrehozási parancs. Mint már említettük, érdemes megpróbálni elkerülni a táblák ilyen módon történő dinamikus létrehozását egy webalkalmazásban, bár el tudom képzelni, hogy „egyszer futtatott” webalapú rendszerekben (például szerver webalkalmazások telepítőiben) használják, mint pl. valamint egyszerű nem web alapú szerver szkriptekben.

Itt van egy objektum modell, amely megfelel az ebben az oktatóanyagban használt példa PHP kódnak

Itt van egy objektum modell, amely megfelel az ebben az oktatóanyagban használt példa PHP kódnak

05. Beillesztés

Az adatok beillesztése nagyon fontos egy dinamikus rendszerben, különösen a kortárs Web 2.0 és Web 3.0 rendszerekben, amelyek az együttműködésre és az együttműködésre orientálódnak - hogyan tudnak a felhasználók együttműködni, ha nincsenek képesek adatok tárolására és megosztására? Ezért illesszünk be néhány adatot a profiltáblánkba:

$ insertsql = 'INSERT INTO profilok (felhasználónév, teljes név, szülőváros) ÉRTÉKEK (: felhasználónév,: teljes név,: szülőváros)';
$ query = $ conn-> Prepar ($ insertsql);
$ query-> bindParam (': felhasználónév', 'knightofarcadia');
$ query-> bindParam (': teljes név', 'Arthur Pendragon');
$ query-> bindParam (': szülőváros', 'Wessex');
$ query-> execute ();

Mint a lekérdezés függvény a táblák létrehozásában, ez kivégezni function nem ad vissza semmi értékeset, mert egyszerűen egy insert parancs az adatbázisba. Azt is észreveszi, hogy az „előkészítés, bekötés és végrehajtás” technikát alkalmazzuk annak érdekében, hogy a változókat az SQL-be ​​juttassuk.

06. Frissítés

A frissítés, mint például a beillesztés és a törlés, döntő fontosságú az együttműködési rendszerben, és az OEM lehetővé teszi ezt. A frissítés nagyon hasonló a beszúráshoz:

$ query = $ conn-> Prepar ('UPDATE profilok SET fullname =: teljes név WHERE
felhasználónév =: felhasználónév ');
$ query-> bindParam (': teljes név', 'Arthur Pendragoon');
$ query-> bindParam (': felhasználónév', 'knightofarcadia');
$ query-> execute ();

A fenti kódblokk csupán kicseréli a felhasználó teljes nevét, de észreveszi, hogy gyakorlatilag megegyezik a beillesztési kóddal. Kötelezünk egy feltételes eredményt, ebben az esetben a felhasználónevet, és egy beállítási eredményt, ebben a példában az új teljes nevet.

Egyszerű relációs adatbázis-modell, normalizált sok-sok kapcsolatról - nagyjából olyan struktúra, amelyet a Doctrine egy ORM-definícióból épít.

Egyszerű relációs adatbázis-modell, normalizált sok-sok kapcsolatról - nagyjából olyan struktúra, amelyet a Doctrine egy ORM-definícióból épít.

07. Törlés

Végül vessünk egy gyors pillantást a törlésre, amely gyakran egyszerűbb folyamat, mint a beszúrás vagy a frissítés.

$ query = $ conn-> Prepar ('DELETE FROM profilok WHERE' felhasználónév '=
:felhasználónév );
$ query-> bindParam (': felhasználónév', 'knightofarcadia');
$ query-> execute ();

A fenti SQL egyszerűen töröl egy profilt, ahol megegyezünk egy felhasználónévvel. A felhasználónevet egyszerűen a feltételes változóhoz kötjük.

08. Adatbázis-kezelő rendszer váltása

Most, feltéve, hogy az adatbázis tábla felépítése megegyezik, és hogy nem használunk semmit nem szabványosítottként egy saját SQL rendszerben, egyszerűen megváltoztathatjuk adatforrásunk nevét egy RDBMS-re - kezdeti példánkban a Microsoft SQL Server -. egy másikhoz (például IBM DB2). Az egész kód, amelyet onnan készítettünk, működni fog - anélkül, hogy bármilyen SQL-t meg kellene változtatni.

Kezdjük a következő karakterlánccal:

$ conn = új OEM ('sqlsrv: server = localhost; adatbázis = yourdbname',
'felhasználónév',
'Jelszó');
$ conn = új OEM ('ibm: DRIVER = {IBM DB2 ODBC DRIVER}; ADATBÁZIS = az Ön
bname; HOSTNAME = localhost; PORT = 56789; PROTOCOL = TCPIP; ',' felhasználónév ',
'Jelszó');

Az OEM-könyvtár másik kulcsfontosságú felhasználója a MediaWiki, az az alkalmazás, amely a Wikipedia Alapítvány összes projektjét működteti

Az OEM-könyvtár másik kulcsfontosságú felhasználója a MediaWiki, az az alkalmazás, amely a Wikipedia Alapítvány összes projektjét működteti

09. Tranzakciók

A tranzakció, adatbázisban kifejezve, az a hely, ahol lekérdezéseket tárol egy későbbi szakaszos feldolgozáshoz. Az OEM lehetővé teszi a tranzakciók felépítését - de mivel ezek nagymértékben függenek az adatbázis-kezelő rendszertől, az OEM-tranzakciók csak akkor működnek, ha az RDBMS azon részhalmazához kapcsolódnak, amelyet az OEM támogat. Ha olyan tranzakciót próbál megkezdeni egy RDBMS-en, amely nem támogatja a tranzakciókat, akkor egy meglehetősen csúnya OEM tranzakciót kap. Tehát elemezzünk néhány tranzakciós kódot:

próbáld ki {
$ conn-> beginTransaction ();
$ insertsql = $ conn-> Prepar ('INSERT INTO profilok (felhasználónév, teljes név,
szülőváros) ÉRTÉKEK ('wilfred', 'Wilfred Jones', 'Scarborough') ');
$ deletesql = $ conn-> Prepar ('DELETE FROM profilokból WHERE felhasználónév =
'felhasználónév'' );
$ conn-> exec ($ insertsql);
$ conn-> exec ($ deletesql);
$ conn-> kötelezettség ();
} fogás ($ e kivétel) {
$ conn-> rollBack ();
// üzenet elérhető a következővel: $ e-> getMessage ();
}

Először megkezdjük a fogást, hogy minden rossz kivételt el tudjunk fogni, beleértve azokat is, amelyeket tapasztalhat, amikor megpróbál csatlakozni egy RDBMS-hez, amely nem rendelkezik tranzakciós támogatással. Kezdünk egy tranzakciót $ conn-> beginTransaction () mielőtt folytatnánk a lekérdezési végrehajtásaink felépítését, de ezek az adatbázisban csak a $ conn-> kötelezettség () A függvény fut, és hatékony soros sorrendben fognak történni - ez azt jelenti, hogy a végrehajtási parancsok között számos más PHP folyamatot is megtehet, az adatbázisra nincs hatással.

Ha azt találjuk, hogy az adatbázis nem támogatja a tranzakciókat, akkor a tranzakció egyszerűen nem fog megtörténni; ha bármilyen más kivétel merül fel, akkor végrehajtjuk $ conn-> rollBack () , amely visszaveti a tranzakció által végrehajtott esetleges változásokat. Érdemes megjegyezni, hogy amikor egy tranzakcióval támogatott RDBMS-hez csatlakozik, a PDO „automatikus lekötés” állapotba kerül, ahol minden exec parancs maga a saját elkötelezett tranzakciója; ha azonban biztonságos módon szeretne dolgozni, akkor mindig használhatja beginTransaction , és hozzáférhetnek a kötegelt elkötelezettséghez és a visszagörgetési funkciókhoz.

10. Problémák az OEM-mel

A PHP szempontjából nincsenek valós problémák az OEM felhasználásával. Ez objektumorientált, vagyis kibővíthető és rugalmas, és sok rendszerrel működik összekapcsolható módon. A probléma akkor merül fel, ha figyelembe vesszük, hogy míg a relációs adatbázis-kezelő rendszerek többsége az SQL szabványosítását követi (így segítve az egyik rendszerről a másikra való áttérést), sok rendszernek megvan a maga saját szintaxisa és funkciói, amelyek nem általánosak más rendszerekben.

Ezért kulcsfontosságú, hogy az egyik rendszerről a másikra történő zökkenőmentes áttéréshez kövesse az SQL szabványokat, és csak az általánosan megtalálható függvényeket használja. Ennek példaként szolgál a lekérdezésekben általánosan használt függvény: megnézhetjük a randomizálás függvényét az SQL-ben. Itt találhatók a különböző nyelvek funkcióinak specifikációi:

MySQL: SELECT RAND ([mag]);
MS SQL: SELECT RAND ([mag]);
PostgreSQL: SELECT RANDOM (); (a vetőmag beállításához futtatnia kell a SETSEED ([mag])
előzetesen)
Oracle DB: SELECT dbms_random.random FROM dual;
SQLite: SELECT RANDOM ();

Tehát ezt szem előtt kell tartanunk, és meg kell vizsgálnunk, hogy alkalmazhatunk-e szabványosított SQL technikát a saját tulajdonú függvény helyett, vagy használhatunk PHP eljárást, és beírhatjuk az eredményt az SQL lekérdezésbe (a randomizálási példában a sor() funkció, amelyet a PHP nyújt).

A gedit alkalmazás a Linuxon az egyik leggyorsabb módja a kód módosításának, és számos nyelv számára kiemeli a szintaxist. A Doctrine ORM rendszert használja

A gedit alkalmazás a Linuxon az egyik leggyorsabb módja a kód módosításának, és számos nyelv számára kiemeli a szintaxist. A Doctrine ORM rendszert használja

11. Az objektum relációs leképezése példával

Természetesen az absztrakcióban tovább mehetünk, ha belépünk a modellező világba - nem, nem úgy, hogy a projektünket kifutón mutatjuk be, hanem a Plain Old PHP Object-eket hozzárendeljük az adatbázis-táblákhoz. Probléma van ezzel az esetleges PHP-objektumokkal, objektum-orientált modellel, míg az SQL-adatbázisok relációs modellel rendelkeznek. Itt jön létre az objektum-relációs leképezés (ORM): ez lehetővé teszi az objektumok táblákhoz való leképezését, gyakran egy kis varázslat és némi csillogás felhasználásával.

Valószínűleg azt kérdezi, mi az ORM előnye. Egész egyszerűen nem kell semmilyen adatbáziskapcsolattal vagy SQL lekérdezéssel foglalkoznia; egyszerűen csak közvetlenül használja a PHP objektumokat és azok módszereit, és az ORM rendszer foglalkozik az összes kapcsolattal és a létrehozás, olvasás, frissítés és törlés tranzakciókkal a háttérben. Van elég sok ORM könyvtár a PHP-hez, PdoMap , Hajt és Vörös bab néhány jó közül, de a legjobb, amit használtam 2. Tan - annak az előnye, hogy önmagában vagy egy MVC beállítás részeként használható, például a Symfony, a CodeIgniter vagy a Zend.

A 2. Tan és néhány más ORM rendszer segítségével általában meghatároz egy objektumkészletet és azokat a fajta kapcsolatokat, amelyek egymással vannak (például egy a sokhoz; sok az egyhez; sok a sokhoz) , a tulajdonságok és a módszerek közötti kapcsolat speciális részleteivel. Természetesen nincs szükség a normalizált linktáblák definiálására, mert ezek az objektummodellben lényegtelenek. Ezt az ember által végrehajtott folyamatot általában egyedi szintaxissal hajtják végre, például XML-ben vagy YAML-ben, és a 2. Tan lehetővé teszi az objektumok relációs meghatározásait a PHP doc-blokkjain belül. A következő modell és kód egy valós példát mutat be.

használja a Doctrine Common Collections ArrayCollection;
/ ** A tag leírása
* @Entity
* /
osztálytag
/ **
* @Id @GeneratedValue
* @ Oszlop (type = 'egész')
* @nem volt
* /
védett $ id;
/ ** @Column (type = 'string')
* @var karakterlánc
* /
védett $ keresztnév;
/ ** @Column (type = 'string')
* @var karakterlánc
* /
védett $ vezetéknév;
/ ** @Column (type = 'string')
* @var karakterlánc
* /
védett $ email;
/ ** Sok tagnak számos csoportja van
* @ManyToMany (targetEntity = 'Csoport')
* @var Csoport []
** /
védett $ csoportok;
/ **
* Építő
* /
nyilvános függvény __construct () {
$ this-> csoportok = new ArrayCollection ();
// ...
}
// --- Alapvető példák getterre és szetterre --- //
/ ** Megkapja a tag (belső) azonosítóját
* @return int
* /
nyilvános függvény getId () {
return $ this-> id;
}
/ ** Megkapja a tag keresztnevét
* @return karakterlánc
* /
nyilvános függvény getFirstname () {
return $ this-> keresztnév;
}
/ ** Beállítja a tag keresztnevét
* @param string $ keresztnév
* /
public function setFirstname ($ firstname) {
$ this-> keresztnév = $ keresztnév;
}
// --- Összetettebb getter és setter példák --- //
/ ** Megkapja a tag csoporttömbjét
* @return csoport []
* /
nyilvános funkció getGroups () {
return $ this-> csoportok;
}
/ ** Csoportot rendel hozzá egy taghoz
* @param Group $ csoport
* /
public function assignToGroup (Group $ group) {
$ this-> csoportok [] = $ csoport;
}
/ ** Eltávolít egy tagot a csoportból
* @param Group $ csoport
* /
public function removeFromGroups (Group $ group) {
$ this-> getGroups () -> removeElement ($ group);
}
// ...
}
?>

A gép által végrehajtott folyamat ezután létrehozhatja az SQL-t egy adatbázis létrehozásához (ez különféle SQL-szintaxisokban lehet, például MySQL, SQL Server vagy PostgreSQL esetén); ezt megteheti úgy, hogy kidobja az SQL-t, vagy összekapcsolódik az adatbázissal és maga hajtja végre. Maga fogja létrehozni a sok-sok link táblázatot.

doktrína orm: séma-eszköz: létrehozás

vagy

doktrína orm: schema-tool: create --dump-sql

Meg fogja találni, hogy a PHP objektumokat és a táblázatokat a helyén van. Most már kezelheti az objektumokat anélkül, hogy tudnia kellene, hogyan kell csatlakozni az adatbázis-kezelő rendszerhez, vagy a relációs táblák felépítését.

$ group = new Group ();
// a csoport adatainak megadása, kitartás és öblítés (az alábbiak szerint)
$ tag = új tag ();
$ member-> setFirstname ('');
$ tag-> setSurname ('');
$ tag-> setEmail ('');
$ tag-> assignToGroup ($ csoport);
$ entitásManager-> persist ($ tag);
$ entitásManager-> flush ();
echo 'Created Member with ID'. $ tag-> getId (). ' n';

Természetesen egy kicsit többről van szó, mint a fenti kódpéldákról, elsősorban a kapcsolat részleteiről és a rendszerindításról, de úgy gondoltam, ízelítőt kell adnom nektek az ORM és különösen a Doctrine erejéből. Hozzá kell tennem, hogy a 2. Tan és néhány másik PHP ORM könyvtár PDO-t használ a különféle RDBMS-ek támogatásának elérése érdekében.

Hasznos, hogy a Doctrine rendszer kiterjedt beépített segítséget tartalmaz, amikor csak szüksége van rá

Hasznos, hogy a Doctrine rendszer kiterjedt beépített segítséget tartalmaz, amikor csak szüksége van rá

12. Következtetés

Az OEM-t kereskedelmi projektekben használtam, és saját tapasztalataim szerint az objektumorientáltságának köszönhetően nagyban megkönnyíti az adatbázis-csatlakozás - és az adatok utólagos kezelése - egyszerűségét. Nincs szükség az OEM használatára csak a rendszerváltási képesség miatt; a funkciók az Ön számára használhatók, jó hatékonyságúak és ideálisak a kortárs programozási tervezési mintákhoz.

Sok olyan rendszer létezik, amely még mindig az eljárási stílusú rendszerspecifikus funkciókat használja, de bizonyára láttam, hogy a hangsúly az OEM-re irányul. Az OEM-et a vadonban is láthatjuk, mivel a Drupal, a MediaWiki, a WordPress és sok más népszerű nyílt forráskódú webalkalmazás ma már teljes egészében vagy részben támogatja az OEM-ek kapcsolódását az adatbázisokhoz. Van egy elképzelésem, miszerint az adatok már nincsenek szorosan összekapcsolva az adatbázisokkal, és az adatbázisok már nincsenek szorosan összekapcsolva a kóddal, és látjuk, hogy általánosabb rendszert használó rendszerek vannak konfigurálva konkrét alkalmazásokhoz. Úgy gondolom, hogy az ORM rendszerek, a NoSQL és a kapcsolt adatok három dologra kell figyelni a jelenben és a jövőben. A jövőbeli webalkalmazások gyilkos tulajdonságai egyrészt megalapozzák az adatok összekapcsolhatóságát, másrészt pedig az adatok manipulálásának hatékonyságát.

Fedezze fel a 101-et CSS és Javascript oktatóanyagok.

Daniel lewis egy webalkalmazás-fejlesztő, tanácsadó, oktató és előadó.