Business Logic hol illeszkedik az MVC-be?
Mostanában kicsit el-elmaradtam a fejlesztésből. Mivel inkább a rendszergazdai oldalával foglalkoztam, sosem jutottam el odáig, hogy föltegyem a most fölteendő kérdést.
Hova fér bele az MVC modellbe a business logic nálatok? Hogy válnak szét az elemi adatbázis-műveleteket végző modellek és a magasabb szintű logikát megvalósítók (ha egyátalán)?
■ Hova fér bele az MVC modellbe a business logic nálatok? Hogy válnak szét az elemi adatbázis-műveleteket végző modellek és a magasabb szintű logikát megvalósítók (ha egyátalán)?
Röviden
Én is. Az más kérdés hogy
Pl. van Db modelled meg van Form modelled mondjuk webnél.
model
A controllerben lévő űzleti logika általában "spagetti" jelleget vesz, és elég körülményesé (gyakorlatilag lehetetlenné) válik az egységtesztelés is. Ráadásul pont az egységbezárást, és a kódduplikációt teszi lehetetlenné.
model
Ok
view helper
Átirányítások
ennek az eldöntése nem a
nyilván a view függhet a modeltől-üzleti logikától. ez általában a controlleren keresztül van megoldva, megfelelő template berángatással, paraméterátadással a viewnek, néha perverzebb esetekben pedig View Helperrel, ami adott esetben model-t hív. (Bár kerülendő a dolog).
ilyesmire gondoltál?
Igen
bárhol
Inkább modulok (osztály) / alkalmazások (domain) szerint szeparálnék, sőt sql-be is raknék dolgokat, hibrid modell, az mvc-t inkább ezek alatt képzelem el, mint programozási paradigma.
szerintem pont a php
Szia, szerintem ezt nem
szerintem ezt nem gondoltad át teljesen... :)
lehet
Dagadt modell, sovany kontroller
az (altalaban) elfogadott irany az ugynevezett: Skinny Controller, Fat Model (Sovany kontroller, Dagadt modell)
link
Tehat amit csak lehet, a modellbe nyomsz bele.
--iM
Bár lehet hogy ez csak nekem
A lényeg szerintem - mint mindig - hogy ne ragaszkodjunk általános konvenciókhoz, hanem jó érzékkel alkalmazkodjunk a környezethez és a felmerülő (megoldandó) problémákhoz, találjuk meg a megfelelő arányt az elosztásban. Rengeteg módja lehet a bus.log. elosztásának, a hangsúly az arányokon van. Kerülhet a bus.log egy-egy része: adatbázis oldalra (tárolt eljárás/függvény), a modelbe, a vezérlőbe, a megjelenítőbe, külső szolgáltatásba stb.
nem véletlen
Ezen kívül kb. OOP-vel is némileg ellentétes, hisz alap szabály, hogy az összetartozó dolgokat tartsd egyben, viszont ez nem teljesül, ha az üzleti logikád egy része szanaszét van szórva a kontrollerekben.
Szintén nem szerencsés, ha a kontroller validál, hisz annak a modelben a helye. Aki a modellt írja, az fogja tudni, hogy mire is kell ellenőrizni, plusz szintén az egységbe zárással ellentétes lenne, ha a kontroller végezné. Technikailag persze lehet így, de akkor a validáció szabályai a modelltől kell jöjjenek.
Nekem a következő felállás szimpatikus:
- Vannak az alap adat objektumok (ez lehet ORM, de bármi egyéb is), pusztán a perzisztáció és a puszta adat reprezentálása a feladatuk. Ezek lehetnek value objectek vagy entitások (ökölszabály szerint utóbbi, aminek van egyedi azonosítója).
- Vannak az üzleti modellt megvalósító osztályok. Ezek használják az előbbi osztályokat, plusz definiálják a velük elvégezhető műveleteket, meg az egyéb mindenfajta logikákat.
- Az előbbi réteg még kb. kicsit általános, ezért van egy újabb service réteg, ami már konkrét használati eseteket valósít meg. Ez szintén a domain model része, de ebben kb. konkrét forgatókönyvek vannak megvalósítva. Pl. user vesz valamit az oldalon: ezt csinálom, aztán emezt csinálom stb. Ezt egyik előbbi réteg beli osztályba sem érdemes tenni, mert tipikusan abban a rétegben lévő osztályok együttműködéséből áll.
A kontrollerek a 2. és 3. réteg beli osztályokat használják, és tipikusan elég vékonyak, minimális huzalozás tartozik beléjük.
+1
Workflow!
Ha a folyamatot mint gráfot ábrázolod akkor az egyes lépések/csomópontok lesznek a view-k, köztük lévő kapcsolatot mindig a kontroller adja.
Kontoroller-t valóban érdemes minél jobban soványítani, de a folyamat irányát meghatározó lépéseket mindig érdemes oda rakni, különben nagy lesz a káosz.
A model-t mindig érdemes funkció halmaz alapján csoportokba szedni és alkalom adtán egymásra építeni. I/O műveletek, adatstruktúrák, módosító műveletek, ellenőrzések... stb...
Ezek alapján - szerintem - ki lehet mondani, hogy a kontroller teljes egészében üzleti logikához kapcsolódik, a model-nek pedig részei.
Szerintem :)
Másrészt a "fat model" nekem nem igazán illik a képbe, a model adatkezelésre való, nem pedig business logic implementálására (nem hiszem hogy a C-t meg az M-et jó ötlet összemosni). Persze azt is érdemes figyelembe venni, hogy a php alkalmazások (eddigi tapasztalataim szerint) erősen adatbázis-orientáltak, és a program jelentős részét tulajdonképp érdemes egyszerű CRUD műveletekként tekinteni.
Hogy a validációt hova rakja az ember, az szerintem erősen véleményes, én inkább a frontendbe tenném, mivel a hibaüzenetek előállítása (aminek része lehet a nemzetköziesítés is) a UI-ra tartozik, ezért egyszerűbb az egészet itt kezelni (mellesleg az se feltétlenül biztos, hogy egy formon csak azonos típusú entitásokat vihet be az user).
Na mindennek a jegyében én így szoktam csinálni:
* Model: saját active record ősosztály amely általános metódusokat biztosít, és a származtatott osztályokban írom meg a többi "custom" lekérdezést.
* Controller (ami szerintem a view része:)): én is igyekszem rövidre fogni, a validációt pl. külön modullal oldom meg, leginkább konfigurációs adatnak tekintem hogy melyik inputra milyen validátorokat kell futtatni, így nem lesz a controller kódja spagetti. A jogosultág-kezelést egyelőre a controllerben csinálom (azaz van-e az adott usernek joga az adott művelet elvégzéséhez), de majd később ezt is külön modulban akarom megoldani. Ha az üzleti logika triviális vagy gyakorlatilag nem létezik (egyszerű CRUD művelet) akkor a controller közvetlenül visszanyúl a modellhez - itt sérül az MVC, de így sokkal gyorsabb a fejlesztés. Ellenkező esetben az üzleti logikát külön osztályban (általában Service_* prefixszel ellátott) implementálom.
Emellett a controller gyűjti össze a template számára a paramétereket, tehát nem vagy csak minimális mértékben használok view helper-eket.