PHP osztálytervezés
2014-04-16T15:46:59+02:00
2014-04-17T20:31:39+02:00
2022-06-29T14:51:38+02:00
  • Nocsak, nem is tudtam, hogy PHP-ben is van interface

    Már több, mint egy évtizede...
    Mutasd a teljes hozzászólást!
  • Valóban, van olyan egyszerű feladat, amire az ORM is jó. A tábla-objektum közvetlen megfeleltetésnek nagyon kicsi a hatósugara.  Már az egyszerűbb lekérdezések is több táblát használnak.  
    SELECT * FROM tabla1,tabla2 WHERE tabla1.id=tabla2.id
    Karbantartás (update) is dolgozhat több táblával. 
    Minek a táblákkal külön szórakozni? Speciális esetben a második legjobb megoldás. Egyébként felejtős.
    Mutasd a teljes hozzászólást!
  • Nocsak, nem is tudtam, hogy PHP-ben is van interface
    Egy kicsit nem figyel az ember, és tovaszalad a világ
    Mutasd a teljes hozzászólást!
  • Szóval, a tábláknak nem érdemes külön osztályt létrehozni.

    Pedig ezt hívják ORM-nek  

    Hogyan alakítod át a relációkat hierarchikus leírássá


    $writersOfBook = BookTable::findOneById($book_id)->getWriters();
    $bookOfWriter = BookTable::findByWriterId($writer_id);

    Amúgy a hierarchikus adatszerkezet nem ez. De a legtöbb ORM arra is nyújt megoldást (Nesteedset, tree, pl:propel)
    Mutasd a teljes hozzászólást!
  • Az adatbázis kezelés hálózatos kapcsolatokat használ, az objektumok hierarchikus szerkezetben léteznek. Az adatbázis a program környezete, globálisan elérhető ha akarom. Az objektum lokális, egy-egy célfeladatra készül.
    Hogyan alakítod át a relációkat hierarchikus leírássá? Mely programozási minta (design pattern) ad használható javaslatot erre a helyzetre? Láthatod a válaszok és a linkek számából: üres a lista.
    Adatmodell,  integritás vizsgálat , stb az már programozható objektummal is. Alacsony szinten adat elérési réteg használható, de nem konkrét táblákkal megvalósítva. Szóval, a tábláknak nem érdemes külön osztályt létrehozni.
    Mutasd a teljes hozzászólást!
  • Mondjuk az User objektumot valóban nem szerencsés a recordot prezentáló osztályból származtatni.

    De általánosságban nem annyira rossz elképzelés hogy van egy Record osztályod és abból származik a Product, Book, vagy bármilyen más néven létrehozott osztályod, ami pontosan leképezi az adatbázisban lévő táblákat (product, book). Ennek a Rekord osztálynak lehetnek olyan metódusai, amik használhatók minden tábla esetén. Például insert, update, delete, read (byId, byName, byAkarmi), vagy akár save. Lehetnek eseményei, például beforeDdelete, beforeUpdate, stb. Én egy abstract osztályt képzelnék el, mert nyilván nem ugyanazok a mezők lesznek a product és a book táblában és ezért mondjuk egy getFieldNames() metódus biztosan csak abstract lehet. Ebből származna a konkrét Book, vagy Product osztály. Aztán én még létrehoznék egy Record-View réteget is a hierarchiában (ProductView, BookView). Mert mondjuk amikor egy MVC rendszerben kirakod a viewnak a modelt megjelenítésre, akkor a megjelenítéshez kapcsolódó függvényeket jó lenne elválasztani az üzleti logikától.

    Egyébként érdemes lenne pár ORM-et megnézned, úgymint Doctrine, Propel.

    Ennek a hátulütője lehet az, hogy csak egy őse lehet egy osztálynak (javítsatok, ha tévedek).

    Traitekkel azt hiszem már túljutottunk ezen. Persze hogy mennyire jó ez, arról nem tudok nyilatkozni.
    Mutasd a teljes hozzászólást!
  • A származtatást én nem javaslom, mert ez ahhoz vezethet, hogy akaratlanul olyan funkcionalitást is elérhetővé tehetsz az osztályon keresztül, ami elé nem építetted be a jogosultságellenőrzést. Ráadásul nem is látom hol lehetne jelentősége a származtatásnak, hiszen nyilván nem lesz majd nagyon olyan kód, amiknek mind a két fajta objektumon kell majd dolgozniuk. (Ha mégis, akkor is ott van még a duck typing meg az interface-ek.)

    Szóval a több (ti. egy az adatmodellt egy az egyben leképező, és egy már ellenőrzésekkel megspékelt funkcionális műveletvégző) rétegre bontás jó ötlet, sőt, ezt pont így kell csinálni, viszont származtatásra nem, hogy nincs szükség, de egyenesen veszélyes és értelmetlen is a két rétegeket implementáló osztályok között.
    Mutasd a teljes hozzászólást!
  • Üdv!
    Még igencsak kezdő php programozóként szeretnék tőletek segítséget kérni. Szeretnék egy "sablont", egy módszert kialakítani, amit elkészíthetek magamnak, majd később erre építhetek. A legfontosabb kérdés számomra most az osztályok, és azok függvényeinek összekapcsolása az adatbázissal. Úgy tudom, érdemes az adatbázis réteget külön venni, ezért is gondoltam ki a következő megoldást:

    class User extends DBUser {
         public function Login(...) {
              <validáció>
              parent::Login(...)
         }
    }

    class DBUser {
         protected Login(...) {
              <itt csak adabázis műveletek, sql parancsok>
         }
    }

    Tehát minden osztálynak van egy DB* megfelelője, ahol ugyanazok (és esetleg egyéb szükséges függvények) vannak. A példából jól látszik, hogy hogyan képzelem el. Ennek a hátulütője lehet az, hogy csak egy őse lehet egy osztálynak (javítsatok, ha tévedek). Másik megoldásként gondoltam ugyanezt, minden osztálynak egy DB* megfelelő, viszont nem extendelt megoldással, hanem csak require_once, és így nem lövöm el a származtatás lehetőségét. Perpillanat még csak ezek az ötletek jutottak az eszembe, szerintetek hogyan lehetne ezt okosabban megoldani? Milyen módszert ajánlanátok? A kérdés nem csak a User osztály és az adatbázis műveletek összekapcsolása, hanem az, hogy egy komplett rendszerben ez hogyan működhetne?
    Mutasd a teljes hozzászólást!
abcd