Adatbázis és laza csatolás
Többször észrevettem már, hogy olyan dolgok mennek az adatbázisba, amik nagyon szorosan csatoltak az adott kóddal, amit írok. Általában olyanokról van szó, hogy 2-3 lehetőség között kell választani, és egy-egy lehetőség neve.
pl:Itt bejelentkezési módokat listázok, ahol az access_method POST, COOKIE és GET értéket vehet fel attól függően, hogy jelszavas, permanent cookies vagy emailben kapott linkes a bejelentkezés. Ez egy a sok eset közül, ahol előfordult ilyesmi, és elég zavaró, hogy nincs laza csatolás a kód és az adatbázis között, és SET formájában megjelennek konkrét megvalósításhoz kapcsolódó értékek az adatbázisban.
Nincs valami bevett módszer ennek az elkerülésére?
■ pl:
access
access_id
user_id
access_method
access_hash
access_expires
Nincs valami bevett módszer ennek az elkerülésére?
Eltérő logikát kell
Nem értem a kérdést. A linkes
Lehet nem jött át teljesen a
Tovább gondolkozva valami olyasmi lehet az adott esetben, hogy logikailag különböző authorizációs módokat sorolsz fel (pl form,trusted,marketing), és a kódban transzformálod ezt a konkrét implementációra. Web esetében pl "post,cookie,get", desktop alkalmazás esetében meg pl "form,hwkey,marketingcode". Viszont így meg elveszted a lényeget, vagyis visszanézve nem fogod látni, hogy melyik bejelentkezés milyen konkrét módszerrel történt. Ebben az esetben pedig kimondott cél ennek letárolása. Illetve amennyiben csak webes a rendszered, akkor egy tök felesleges absztrakciós szintet hoztál be gyakorlati (pl karbantarthatóság, bővíthetőség) haszon nélkül (over-engineering). Ilyen absztrakciónak inkább visszafelé látom értelmét, amikor adott beállítás mellett adott, környezetfüggő implementációt kell kiválasztani és végrehajtani. Pl ha csak formos authentikáció engedélyezett a usernek, akkor a webes rendszer formot, a desktopos alkalmazás meg valami dialogot dob fel neki. De alapvetően az adatbázis a jellegéből adódóan szoros csatolást biztosít, és szerintem ez jól is van így, az absztrakciónak a kódban (üzleti logikában) van a helye.
De lehet a példád kicsit félrevitt :)
Van másik példa is. Van
De ez azért valahol
Hogy pl 10kHUF feletti rendelésre speciális eset van, azt én is configba raknám (hogy ez file, vagy db config, az most mindegy), hiszen ez egy globális paramétere az üzleti logikának. Az, hogy az aktuális megrendelés paypal-es, vagy nem, az már megrendelés szintű információ, a megrendelés egy tulajdonsága, ezért ennek a megrendelésben van a helye.
Vagy az a bajod, hogy az üzleti logikában le kell írnod, hogy
Azt hiszem nem igazán értem még mindig a problémád.
Annyi a bajom, hogy
Enumokkal mi a baj? Az tény,
Ez szerintem nem feltétlenül igaz, mert csinálhatsz konstansokat php oldalon az id-val, és akkor már eleve az id-t tolod le, viszont a kódodban a konstans neve szerepel. A kapcsolótábla meg csak ahhoz kell, hogy ha db oldalon selectet írsz, akkor lásd, hogy melyik érték mit jelent, de az alkalmazásod nem használja azt a táblát egyáltalán. Plusz megvan az az előnye, mint az enumnak is, hogy csak valid értéket tolhatsz le a táblába a constraint miatt.
A fenti hozzászólásban épp
Adatbázis nélkül, tisztán OOP-vel hogy oldanád meg mindezt? Példánál maradva lenne egy abstract fizetési típus osztályod, illetve ebből származtatnád a többit és azokban az egyedi, specializálni kívánt logikát megírnád. Csak azért, mert ezeket adatbázisba mented, ne gondolkodj másképp. Csináld meg úgy, hogy működjön DB nélkül, aztán majd megcsinálod a perzisztálást/visszaolvasást.
Származtatott objektumok adatbázisba mentésére van egy pár megoldás: Single Table Inheritance, Class Table Inheritance, stb. Ezt a kettőt általában támogatják az ORM-ek, de ha nem használsz ORM-et, akkor is megoldható az implementálásuk.
Okés, köszi, utánaolvasok
Ezt nem ismertem, de
Látom PHP-ben gondolkozol, úgyhogy azt mondom, Doctrine, esetleg Propel. Én hanyagolnám az Active Recordot, de az már más téma.
Igazából szinte tökmindegy,
Bár őszintén szólva fogalmam
access_method-ok bele vannak hardkódolva az egyes rekordokba (ezzel különböző anomáliákat okozva), akkor egyszerűen vedd ki azaccess_method-od egy új táblába (normalizálás).Ha azzal van a gond, hogy az eltérő
access_method-ok eltérő implementációt takarnak (tehát pl egy más típusú objektum reprezentálja őket), és ezt az osztályhieararchiát szeretnéd valahogy reprezentálni az adatbázisban, akkor az a helyzet, hogy a relációs adatbázisok nem igazán alkalmasak erre (meg lehet oldani minden további nélkül, csak ezek elég csúnya megoldások)A normalizálás csak ront a
Ahogy nézem az öröklődős megoldás még bonyolultabbá tenné az egészet, akkor már jobb így flagekkel csinálni.
Szerintem az alapvető gond
Azt hiszem rájöttem, hogy hol
Egyébként abban igazatok volt, hogy egy ORM-el szintén ugyanúgy ki lehet alakítani egy réteget php-ben, és onnan küldözgetni a query-ket, viszont az szorosan csatolt lesz az adatbázissal. Szóval ez is egy lehetséges megoldás.
Na hát ilyen az, amikor érzi az ember, hogy hiba van a gépezetben, de nem jön rá, hogy hol. :D
Köszönöm mindenkinek az építő hozzászólásokat!