MVC kérdés: blog modell-jének kialakítása
A probléma a következő: adott egy MVC rendszer, amivel megvalósítunk egy blog-ot. A blog modell-jének van egy olyan metódusa, mely visszaadja az utolsó X bejegyzés adatait, melyek a következők: cím, bevezető rész, hosszabb rész, dátum, szerző, cimkék.
A kérdés pedig a következő, logikailag hogyan érdemes megoldani azt, hogy a cimkéket is lekérjük?
1. Legyen egy függvény, mely visszad minden információt az bejegyzésekről:
2. Legyen egy függvény, mely visszaadja a bejegyzések infóit, kivéve a cimkéket
A működése ugyanaz, mint fentebb, kivéve, hogy a cimkéket nem kéri le.
A cimkelekérdezést az előbb leírt módon egy külön modell metódust hajtja végre, melyet a kontroller hivogat.
A három megoldás közül melyik a célszerűbb?
Az első szerintem a legtisztább logikai szempontból, mert egyszerre megkap a kontroller minden infót az egyes bejegyzésekről. A cimkék lekérést megvalósító külön modell metódus letisztultabbnak látszik, a nagy metódushoz képest (áttekinthetőbb lesz a fő metódus).
A második megoldás végülis az első különválasztása, mely nem tudom, hogy mennyire szerencsés, azaz érdemes-e a kontrollerre bízni, hogy külön kérje le az egyes bejegyzések cimkéit.
■ A kérdés pedig a következő, logikailag hogyan érdemes megoldani azt, hogy a cimkéket is lekérjük?
1. Legyen egy függvény, mely visszad minden információt az bejegyzésekről:
- Lekéri az utolsó X bejegyzést
- Kigyűjtögeti mindegyikhez a cimkéket
- A cimkéket hozzáadja a megfelelő post-hoz (amit egy tömb reprezentál)
- Visszaadja a post minden adatát
- lehet egy olyan metódusa a modell-nek, ami a kapott ID-jű post-hoz tartozó cimkéket adja vissza
- a cimkelekérést a függvényen belül oldajuk meg külön függvény felhasználása nélkül
2. Legyen egy függvény, mely visszaadja a bejegyzések infóit, kivéve a cimkéket
A működése ugyanaz, mint fentebb, kivéve, hogy a cimkéket nem kéri le.
A cimkelekérdezést az előbb leírt módon egy külön modell metódust hajtja végre, melyet a kontroller hivogat.
A három megoldás közül melyik a célszerűbb?
Az első szerintem a legtisztább logikai szempontból, mert egyszerre megkap a kontroller minden infót az egyes bejegyzésekről. A cimkék lekérést megvalósító külön modell metódus letisztultabbnak látszik, a nagy metódushoz képest (áttekinthetőbb lesz a fő metódus).
A második megoldás végülis az első különválasztása, mely nem tudom, hogy mennyire szerencsés, azaz érdemes-e a kontrollerre bízni, hogy külön kérje le az egyes bejegyzések cimkéit.
DB
Ha foglalkozol ilyen dolgokkal, akkor én azt ajánlom próbálj ki egy ORM-et. Szerintem nem jó ráerőltetni az MVC-t egy projektre, pusztán az MVC kedvéért.
A cimkék nem szövegként ...
Ami az ORM-et illeti, tervezem, hogy meglesem hogyan működik (az eddigi WL-es topic-ok alapján nem szimpi), de a mostani project-ben biztoan nem fogom még használni (így is jelentős csúszásban vagyok vele).
group concat
kapcsolat?
Re
Jelenleg egyébként úgy működik, hogy lefut egy query a getLastPosts() függvényben, ami lekéri az utolsó 10 post-ot, majd egy másik qruery, ami lekéri az egyes post-okhoz tartozó cimkéket (ID-t és nevet a tags táblából a tag_relationship tábla segítségével), majd a cimkéket tartalmazó tömböt beteszem a $posts[i]["tags"] változóba.
Amit szeretnék:
POSTS táblából lekérni: id, title, preview, details, date
AUTHORS táblából: name
TAGS táblából: name (rájöttem, hogy az ID nem kell, mert a tag nevére linkelek, nem ID-ra)
Táblák
POSTS - id, title, preview, details, date, author_id
TAGS - id, name
TAG_RELATIONSHIP - post_id, tag_id
AUTHORS - id, name
Hogyan oldaható meg a legoptimálisabban, hogy visszakapjam az utolsó 10 post-ot dátum szerint csökkenően rendezve, a megadott adatok alapján (a tag-ek lehetnek összefűzve)?
Nem vagyok egy SQL guru, tehát én csak 2 lekéréssel tudom megoldani, amit fentebb le is írtam.
Látom, kárhozatra ítélted a negyedik posztot :)
Nem ítéltem, de ...
Valahogy így...
Jól szemlélteti viszont a "többeszám" elnevezési konvenció hiányosságát:
authors.id = author_id
mennyivel szebben fest:
author.id = author_id
vagy esetleg:
author.id = post.author
De persze mindenkinek a saját édesanyja alegszebb :)
Thx
javítás
GROUP_CONCAT(tags.id ORDER BY tags.name) AS tids
nem szabványos query
Szabványosan?
aggregátor függvény
De mint sok esetben a programozásban, ha valamit nem tudsz "szépen" megcsinálni, akkor ott jó eséllyel nem jó a megközelítés: jelen esetben is nem biztos, hogy szerencsés a cikkek adatait a tagekkel együtt lekérdezni. Vonzó, hogy egy lekérdezéssel megvan, de pl. ha 100 cikket szeretnél így lekérdezni, és mindegyiknek van mondjuk átlag 5 tagje, akkor már ez a megközelítés jelentősen növeli az eredményhalmaz méretét.
Sejtettem ...
orm és az m
Persze lehet ORM nélkül is, interfészek definiálásával, szépen, csak kérdés, hogy a postok 6 féle nézetére (főoldal, szerző főoldala, tag szerinti listázás, "legfrissebb" box stb stb) - ahol más-más mezőkre vagyunk kíváncsiak szeretnénk-e 6 különböző interfészt létrehozni.
Pl:
???
Az eredeti felvetéssel nekem az volt a bajom, hogy nem lehet az MVC-t párhuzamba állítani az ORM-mel ("használj MVC helyett ORM-et"), nem egy "szinten" vannak. Az MVC-ből az ORM az M betű egy része.
Akkor pontosítok
Amire gondoltam az, hogy az általa vázolt eljárásoknál egy ORM általában jobb lehetőségeket ad.
Az ORM egy eszköz, az MVC egy fejlesztési stratégia. Ha MVC-t használunk, akkor az ORM a modell része. Viszont egy ORM használható anélkül is, hogy az MVC stratégiával élnénk.
Modell vagy nem modell, ez itt a kérdés
Az utóbbi időben már elég jól be tudom lőni, hogy mi kerüljön a modellbe és mi maradjon a kontrollerben, de a következő dolog kifogott tarjtam.
Tehát adott egy getPostList action. A getPostList azt csinálja, hogy megjelenít bizonyos számú bejegyzést, megfűszerezve azzal, hogy lapozhatóságot valósít meg. Azaz első körben mondjuk az utolsó 10 bejegyzést jeleníti meg, aztán ha úgy alakul, akkor a korábbi bejegyzések közül 10 darabot.
Namost jelenleg ebben az action-ben van megvalósítva az előző és következő oldalra mutató link előállítása. A dilemmám az, hogy egy ilyen link előállítása a kontroller vagy a modell feladata?
Ha abból indulok ki, hogy a kontroller funkcionalitása korlátozódik az adatok összegyűjtésére, azok validálására, a modellel való oda-vissza kommunikációra (adatok szolgáltatása a modellnek, adatok kérése a modelltől), valamint a nézetek kezelésére, akkor nem illik a képbe két ilyen link előállítása.
Ki hogy látja, a kontroller vagy a modell feladata előállítani a lapozásért felelős linket?
Adat
Szóval szerintem modell.
Üdv:
Gábor.
Adat forrás
Azaz van mondjuk egy cookie-ban tárolt adat, amiről azért ellenőrizni kellene, hogy megfelel-e a formai követelményeknek. Ezen ellenőrzés a modell vagy a kontroller feladata? Vagy a cookie az nem a modell része, hanem bejövő adat és így a kontrollernek kell validálnia?
Ha nem megfelelő az adat formája (pl. xyz karakterek lehetnek csak benne, de van benne m karakter is) és a modell részének tekintjük, akkor mi történik? Mert a modell nem szólhat vissza, hogy bocsi nem megfelelő az adat, mert ez kb. olyan, mint amikor valaki az adatbázisban kézzel írja át a kérdéses adatot.
Szerk.: Belegondolva, mivel a kéréssel együtt érkezik a cookie-ból az adat, ezért bejövő adatnak érdemes tekinteni. Ergó úgy kezeljük, mint ha GET paraméterként érkezne, így pedig a kontroller validálja.
van egy reteg
Nekem altalaban csak 1 kerdes szokott felmerulni, mi van ha 1xre tobb modellel is dolgoznom kell egy adott uzleti logika megvalositasahoz?
-cs-
Sanyi
Abstract osztály, extends
...
-cs-
Sanyi