Legutóbbi munkám során már használtam MVC-t (bár néven nem neveztem, de így tűnt logikusnak a felépítés), aholis egy Flash program volt a View, PHP volt a Controller, tehát abban volt az üzleti logika és MySQL volt a Model.
Most viszont felvetődött bennem egy kérdés. Model adott. PHP a Controller, HTML a View. Mármost, készítek egy PHP osztályt, ami az üzleti logika, HTML-t nyomokban se tartalmaz. Ez eddig oké. Van a HTML rész, ahol felépítem az oldalt, CSS-sel meglayoutolom, a PHP osztály megfelelő tagfüggvényét meghívva pedig kiírom a tartalmat.
Eddig tök jó, nem kell vegyíteni a PHP-t és a HTML-t, tiszta marad az egész, csak egy "echo" kell mindenhova.
De mi történik akkor, ha egy listát kell létrehoznom, vagy mint egy fórumnál a kommenteket. Itt a HTML ugye függ a PHP által visszaadott elemek számától, tehát muszáj vegyítenem a kettőt. Vagy a PHP-val adok rögtön vissza HTML elemeket, ami nem szép dolog, vagy a HTML oldalon kutyulok és egy cikluson belül echozok PHP-val HTML tageket, ami szintén nem szerencsés, a HTML dokumentum olvashatóságát szépen tökreteszi.
Van erre valami elegáns, vagy áthidaló módszer, hogy ne kelljen ilyeneket csinálnom?
- 2087 megtekintés
Hozzászólások
Template használat.
- A hozzászóláshoz be kell jelentkezni
Utánanézek, köszi!
- A hozzászóláshoz be kell jelentkezni
Szerintem egy picit teves a felfogasod az MVC-rol, a modell nem csak az adatok tarolasaert felelos (DB, filesystem, stb.), hanem itt valosul meg az uzleti logika nagyresze is. A kontroller inkabb csak osszekoti a masik kettot.
Az aktualis problemadra amugy mint amr emlitettek, egy template engine a szep megoldas, pl. smarty.
----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
- A hozzászóláshoz be kell jelentkezni
Ha arra gondolsz, hogy a lekérdezések is az üzleti logika része, és amit lehet, azt a DB oldja meg, ne a PHP, akkor igen, próbálok így tenni :) Egyébként tényleg kicsit fura még nekem ez az egész MVC, viszont jól használható dolognak tűnik. Egyébként, nekem például a szeparáláson kívül azért lenne érdekes, hogy adott adathalmazból ne csak pl. HTML, vagy Flash oldalt, hanem HTML és Flash oldalt is létrehozhassak - a megjelenítés piszkálásán kívül - nulla változtatással.
Smartynak utánanézek, köszi!
- A hozzászóláshoz be kell jelentkezni
Ha arra gondolsz, hogy a lekérdezések is az üzleti logika része
A db queryk meg fajlmuveletek ("adathozzaferes") reszei a modellnek, ugyanugy, mint az uzleti logika. Elvihetned a teljes uzleti logikat a DB-be stored procedure-ok meg triggerek formajaban, de ez nem mindig jo...
amit lehet, azt a DB oldja meg, ne a PHP
Ezt meg honnan vetted?
----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
- A hozzászóláshoz be kell jelentkezni
"Ezt meg honnan vetted?"
Onnan vette, hogy ezt igy szoktak csinálni. Az adatot kezelje az adatbaziskezelo.
Végtére is nem php arrayt sort()-olsz "order by" helyett...remélem.
- A hozzászóláshoz be kell jelentkezni
Az adatot kezelje az adatbaziskezelo.
Fenntebb irtam, hogy MVC-ben az M nem csak az "adatok kezeleserol" szol. Vagy elbeszelunk egymas mellett..?
----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
- A hozzászóláshoz be kell jelentkezni
ez esetben elbeszelunk :) de értem mit akarsz mondani.
- A hozzászóláshoz be kell jelentkezni
Szerintem itt is az "attol fugg" a helyes valasz. Van, amikor a DB a jo, maskor (pl. bonyolultabb szamitasok eseten) inkabb nem.
--
Az emberek azt állítják, hogy múlik az idő, az idő viszont csak mosolyog, mert látja, hogy az emberek múlnak. - tibeti közmondás
- A hozzászóláshoz be kell jelentkezni
Az adatokat kezelje az adatbázskezelő, de az üzleti logikát legritkább esetben érdemes átvinni dbrétegbe, ugyanis az adatbázis még mindig kevésbél elosztható rendszer, mint az alkalmazásréteg. Persze a db-ből order by-al kérsz le, de az nem jelenti azt, hogy az árkalkulációt is ott végzed mondjuk. Véleményem szerint a db-rétegbe úgy éri meg elmozgatni az üzleti logikát, ha normálisan clusterelhető az adatbázis, és jól dokumentáltak a tárolt eljárások, hogy az alkalmazásréteg-fejlesztőknek ne egy fekete doboz legyen a cucc.
_____________________
OWASP AntiSamy Javaban
- A hozzászóláshoz be kell jelentkezni
igen, ez mindig tervezés kérdése :-)
- A hozzászóláshoz be kell jelentkezni
Igen ez pl. kissé zavaros (és nem csak ebben a nagy emvécézésben) hogy az "üzleti logika" [bahh :-Z] részben jelen van az aktuális programnyelvben is és az adatbázisban is. Szerintem ez elég hülyén van így kitalálva, mert nem választható szét "üzleti logika" értelmesen. Ráadásul egy csomoó járulékos problémát is okoz. pl. valaki tud[ van jogosultsága] ftp-zni, de nem tud StoredP-t írni/módosítani, mert a db-hez már csak korlátozottan fér hozzá.
Lehetne csak a db-ben az üzleti logika. Előny, h minden egy helyen, akárki csesztetheti desktop program , webservice mindenkinek egyfomrán műxik. Oké, de egyrészt jóval nehezebb a teljes logikat implementálni a db-be, másrészt nem is erre lett tervezve egy db.
Lehetne csak a programnyelvben. Itt is meglenne az az előny, h csak egy helyen kell változtatni. Hátrány az adott programnyelv korlátja, atomizált adatárolásra van szükség (mert ellenkező esetben a specializált adatbázis struktúra az üzleti modell része lenne). Tehát ebben az esetben a db valójában csak a "storage" szinten jelenik meg, és mentes minden korlátozó struktúrától v. implementálandó üzleti logikától.
- A hozzászóláshoz be kell jelentkezni
Az MVC-nel elegge adja magat, hogy mi mi, ha az M adatbazisban van, a V Flash, a C meg PHP (vagy masik 3 teljesen mas nyelv/technologia).
Viszont azzal is szetvalasztod a V es C reteget, ha mindketto PHP, de nem C-bol generalod a HTML-t, hanem V es C kozt van valami jol elhatarolhato interface (valami adatszerkezet, objektumok, tombok, serializalhato dolgok), de mindketto PHP. Mert akkor mar - ezt az interface-edet ujraimplementalva mas nyelven - letre tudsz hozni uj view-okat (vagy ugyanolyan nyelven masikat, mas eszkozre pl.).
Olyan is van, amikor egy-egy ilyen reteget vagsz megint kette: mondjuk Ajaxnal tipikusan ilyen, a V reteg egyik fele a kliens bongeszojeben fut, a masik (esetlegesen nagyon vekony resze) meg a serveren.
--
Az emberek azt állítják, hogy múlik az idő, az idő viszont csak mosolyog, mert látja, hogy az emberek múlnak. - tibeti közmondás
- A hozzászóláshoz be kell jelentkezni
peldanak okaert nezd at a Ruby on Rails (igentudom, nem php, de attol meg nezd meg), a CakePHP es a Symfony mukodeset.
- A hozzászóláshoz be kell jelentkezni
+1 , illetve ha Debian-t használ akkor az általam karbantartott Kohana Framework-öt is. Csomagnév: libkohana3.2-php
- A hozzászóláshoz be kell jelentkezni
A konkret kerdesedre a konkret valaszt az alabbi papiros tartalmazza:
http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf
Magyaul az inkluziot egy alelemre megengedve, ill. a letezes alapjan if-elest (if not null) es a foreachet kozvetlenul alelemekre engedve kapsz egy teljes template nyelvet, ami meg mindig mentes az uzleti logikatol.
Abban itt sok embernek igaza van, hogy az mvc es a data-logic-presentation rendesen keveredik a fejekben, mindegy, en a most elterjedt modellt az entities-services-templates -nek szoktam hivni, ugye a kulonbozo haromretegu architekturak es modellek majdnem ugyanolyanok, de megsem, az entity nem feltetlenul data, a model nem feltetlenul entity csak, stb. Mindegy, amit kerdeztel, arra a valaszt leirt Parr.
- A hozzászóláshoz be kell jelentkezni
Te most kb. azt akarod csinalni, ami miatt szivok egy csomot a korabbi projektem miatt :)
A modell az meg csak veletlenul sem az adatbazis. Vonatkoztass el teljesen az adatbazistol vagy, hogy egyaltalan miben vannak tarolva az adataid.
A modell az azon adatosztalyok, muveletek, folyamatok osszessege a kodban, amelybol osszeall az alkalmazasod. Es itt gyakori hiba, hogy valaki raall valamilyen ORM megoldasra es felreertelmezi es azt csinalja, hogy az adatbazisnak csinal egy 1-1 lekepezest objektumokkal. Ennel sokkal bovebb a modell reteg.
Pl. van egy kosar objektumod. A kosarnak van egy termek hozzaad/termek elvesz, kosar lead, stb. metodusa. Vagy mondjuk metodus a kosar osszertekenek kiszamitasara. Ezek mind-mind a kosar objektumhoz tartoznak. Persze, ehhez tartozhat meg tovabbi segedosztalyok is, pl. ha command patternt hasznalod, vagy pl. allapotgepet, stb.
Masreszt gondolj bele abba is, hogy akar egy kepfajlhoz is tartozhat modell osztaly, amelynek lehet, hogy koze nincs a DB-hez.
A view meg egy erdekes temakor. Pl. most lett egy elegge smarty hivo kollegam, vitazunk is eleget, hogy mi az, amit en korabban blokknak hivtam (kicsit mar atlog a ViewModel-be az MVVM-bol, persze XAML es mindenfele ilyesmi nelkul).
A controller meg csak amolyan ragaszto. Ne tevesszen meg a neve, nem az iranyitja a folyamatokat, az csak "lapatolja" a dolgokat.
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
A dolog picit bonyolultabb.
Az eredeti MVC-ben (Krasner & Pope) a model az absztrakt rendszer, ahogy te is irod.
A view viszont ezen rendszer osszes kimenetet (UI) a controller pedig osszes bemenetet (joystick, eger, bill, kobalta..) kezeli.
Tehat kapsz egy ilyet:
input ---- [controller] ---- > model ---- [view] ----> output
A controller tehat nem ragaszto, hanem altalanos nev a joystickre (lasd xbox 360)
A szazforintos kerdes, hogy egy nagyobb modelt hogy erdemes megirni?
Es itt jon be az, hogy entitasok es szolgaltatasok paros grafjakent ertelmezed a modelt. Ez ugyan papiron nem tul OOP-s (leginkabb a strukturalt programozas vilaga) a gyakorlatban viszont mukodik.
Ezen paros ertelmezesre alapul a Rational Analysis Classes (ott a UI-t az un. boundary class-ok adjak, amik true OOP osztalyok).
A masik nagy kerdes, hogy infrastrukturaban hogy szolgalod ki, ez pedig a data-logic-presentation lesz, amiben minden,amirol eddig beszeltunk, az csak a logic.
Namost a te peldaddal elve, egy entity-services felosztasban van egy kosar service-ed, ami kosar es elem entity-ket hasznal, de hogy ez epp milyen implementacio, arrol a service hasznaloja nem feltetlenul tud, cserebe nem piszkalja az entitasokat kezzel.
Ezek a harmas felosztasok a gyakorlatban viszont nagyon osszekeveredtek, meg az OOP-sek allitjak, hogy true OOP-t kell es foleg hogy lehet irni absztrakt modelkent, hat ez mindenkinek lelkiismeretere van bizva.
- A hozzászóláshoz be kell jelentkezni
Köszönöm a válaszokat, kezd tisztulni a kép!
- A hozzászóláshoz be kell jelentkezni