Models in MVC

[ZpAz]

Ik werk al een tijdje met het Zend Framework (PHP) via 'de MVC' manier, nu begin ik me steeds meer af te vragen of mijn 'definitie van model' wel goed is.

Mijn (eerdere) definitie was een beetje 'de data laag' aka, het duwt data op request naar de controller, de controller doet zijn ding er mee en die duwt het naar de view. Vanaf de view gaat input naar de controller, welke het controleert en modificeert als nodig, als de data 'goed bevonden is' gaat het naar de Model toe.

Nu lees ik steeds meer op het internet over 'Fat Models & Skinny Controllers' in deze 'verhalen' wordt er aan een Model veel meer toegekend. Nu vroeg ik me af, wat hoort er nu dan precies in een Model thuis.

Als ik bijvoorbeeld een formulier heb, de knoppen en invoervelden zijn 'view' de data hiervan, wie handeld dat af? Bijvoorbeeld de controle van of 'de data juist is of niet' moet de Model dit nu doen, of is dit toch een taak van de Controller, en de Model slaat 'enkel de toegekende data op'.

En als er vanalles naar de Model moet, wat blijft er dan voor de Controller over om te doen?

edit:
Ik kom nu net deze pagina tegen, en deze legt op zich wel netjes uit hoe je de controle in de Models kan plaatsen. Maar op deze manier kan je volgens mij niet echt lekker gebruik maken van bijvoorbeeld Zend_Form(); (Of gooi je je Zend_Form dan in de Model, en passed de model de view (Zend_Form genereerd immers zelf 'de view kant' van een formulier) van de form terug naar de controller naar je eigen view waar het weer in moet?)

Ik ben wel benieuwd naar jullie kijk hier op.

Ik weet dat hij in SEA staat ipv Programming, mij gaat het dan ook meer om de 'structuur' dan de actuele code, de hoe de wat de waarom. Mocht hij toch beter in programming passen, schop hem dan die kant maar op.

[ Voor 31% gewijzigd door ZpAz op 30-07-2010 19:24 ]

[Sebazzz]

Om op je validatievraag antwoord te geven: Een model hoort zichzelf te valideren, validatielogica gaat in het model. Businesslogica (reageren op validatie e.d, berekeningen, verwerking van data tot model) gaat weer in de controller. Dit heeft ook als voordeel dat de code centraal gebruikt kan worden. Een modelobject komt best vaak voor in de applicatie terwijl er meestal meerdere keren gevalideerd wordt.

Wikipedia vertelt ook dit:

The model is used to manage information. The model is the domain-specific representation of the data upon which the application operates. Domain logic adds meaning to raw data (for example, calculating whether today is the user's birthday, or the totals, taxes, and shipping charges for shopping cart items).

Een view mag ook wel logica bevatten, maar zeer beperkt. Bijvoorbeeld 'moet deze tekst wel of niet weergegeven worden'.
Many applications use a persistent storage mechanism such as a database to store data. MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the model. Models are not data access objects; however, in very simple apps that have little domain logic there is no real distinction to be made. Active Record is an accepted design pattern which merges domain logic and data access code - a model which knows how to persist itself.

[ Voor 6% gewijzigd door Sebazzz op 30-07-2010 20:58 ]

[Kalentum]

Zend_Form is een beetje een raar ding omdat het zowel html formulier kan renderen alsook de input van deze formulieren kan valideren.

Een action in een controller bij mij kan er zo uitzien:

PHP:

public function saveAction() {
    if ($this->request->isPost()) {
        $data = $this->getRequest()->getParams();
        if ($form->isValid($data) {
             $model->save($data);
        }
        else {
            $form->populate($data);
            $this->view->form = $form;
            $this->view->render('edit');
        }

}

Hierin ga ik er dus vanuit dat de model::save() methode een array met data in de vorm van een HTTP POST als argument heeft. De save() methode moet dus die array nog omzetten naar een database call. Dat betekent dus dat het model nog wat code moet hebben om dat allemaal af te handelen. Het is dus wat meer dan alleen een interface op een tabel.

Ik vind validatie niet altijd een onderdeel van een model. Voor een deel volgt validatie uit je databasestructuur (geen letters opslaan in een numeriek veld) maar dat is niet het hele verhaal. Zo kan ik me best voorstellen dat een bepaalde veld alleen verplicht is als een ander veld een waarde heeft. Dat zijn zaken die van de context afhangen en die context weet je in je controller en niet in je model.

De controller doet uiteraard nog veel meer. Zo zal er doorgaans een setje van CSS/JS bestanden gekoppeld moeten worden, waarvan sommige alleen in een specifieke action of een controller. Er zullen nog veel meer stukjes tekst enzo aan een view moeten worden gehangen, dat doet de controller ook.

Voor je model blijft dan alles over wat met de eigenlijke data te maken heeft. Dus het ophalen van gegevens uit een backend, wegschrijven (inclusief geschikt maken voor die backend), transformeren van data etcetera.

[Freeaqingme]

Ik zou eens op deze site (ch. 3 & 9) kijken. Dat hele boek gaat over hoe je nou verder met ZF kan gaan als je de ZF quickstartgudie doorlopen hebt, en gaat veel dieper op bep. onderwerpen in.

[Ssander]

Zoals Sebazzz al zegt wil je de validatie in het model stoppen. Je moet de controller en model als verschillende objecten zien die onafhankelijk van elkaar kunnen bestaan. De controller stuurt de verkregen input van een view naar een onbekend model, en krijgt 'ok' of 'niet ok' (met details) terug. Wat er echter allemaal gebeurt in het model weet de controller niet, en dat is het idee dan ook juist. Zonder dat de controller het weet kun je ervoor kiezen om de model laag te veranderen, door bv. van een relationele database naar een object georiënteerde database te gaan. Als je applicatie voldoende modulair is opgebouwd (dus een juiste scheiding tussen controller en model) hoef je dan niets aan de controllers te veranderen. Sterker nog, een controller weet niet eens hoe de data opgeslagen wordt, dat is geheel het werk van het model.

Ook is het op deze manier makkelijk om je models in andere applicaties te gebruiken. Wanneer je een of meerdere model(s) hebt gemaakt die toegang geven tot de data van een blog, zou je deze models gewoon in een andere applicatie moeten kunnen stoppen en direct moeten kunnen gebruiken door de juiste functies aan te roepen.

Het is ietwat zwart-wit geschetst (er is zeker een grijs gebied), maar in principe maak je de scheiding tussen model en controller mede om bovenstaande voorbeelden te kunnen doen. Hou dit dus in gedachten bij het beslissen wat waar moet gebeuren.

[Freeaqingme]

Let wel dat de M in MVC staat voor je model _laag_, niet per se 1 object. Mijn Model laag bestaat bijvoorbeeld uit een service layer, welke een datamapper benut, welke weer models uitpoept (objecten die een entiteit representeren). In m'n service layer doe ik dan dingen als loggen en authenticatie controleren (business logic), terwijl de datamappers zich enkel bezighouden met de datasource (normaal gesproken rdbms, domain logic).