[Zend Framework] -MVC

[Jigs]

Hallo allemaal,

Ik heb meer soort van architectonische vraag welke (voornamelijk) gebasseerd is op de implementatie van het zend framework. Mijn probleem is als volgt. Laten we als voorbeeld nemen een webapplicatie die iets doet met de gebruikers, evenementen en abonnementen. Het idee is dat gebruikers zich kunnen abonneren voor evenementen en dat admin's de inschrijvingen kunnen beheren. So far so good.

Nu is het zo. Het Zend Framework is zeer duidelijk over de controller en Views. Het probleem is over het model waarover Zend (volgens mijn bescheiden mening) niet zo duidelijk is.Hier heb ik een aantal vragen over.

Als je hier en daar leest over MVC zie je dat een applicatie over het algemeen één controller heeft (die op zijn beurt meerdere subcontrollers kan hebben). Ik heb mijn applicatie heb ik het opgesplitst in 3 belangrijke controllers (eventController, personController en inschrijving controller). En vandaag was dacht ik hierover na en kwam tot de conclusie dat dit niet erg handig is , aangezien je altijd overlapiinghebt tussen bijvoorbeeld evenmententen en inschrijvingen. Dus ik dacht van 2 mogelijke oplossingen.

OPLOSSING 1: Houd 3 controllers die alleen een verbinding met het model door middel van één (model) controller. één van de nadelen hierbij is dat je blijft zitten met zaken die overlappen.
OPLOSSING 2: Het samenvoegen van de 3 controllers tot één controller en het gebruiken om verbinding te maken met het model. Dit zal de meeste overzicht bieden, maar een grote controller.

Dus mijn vraag aan u is wat denk je van deze analyse? Welke oplossing zou je kiezen of is er een derde, een betere oplossing?

Alvast bedankt.

[Pete]

Binnen het framework heb je controllers en acties. Een controller kan meerdere acties hebben. De indeling met eventController, personController en inschrijvingController lijkt mij een logische (op de mix van engels en nederlands na). Een eventcontroller heeft dan bijvoorbeeld de acties, list, add, edit.

Het is niet duidelijk wat je bedoeld met de koppeling met het model. In dit geval zou je 3 classen aanmaken in het model. Al deze 3 klassen kun je aanroepen vanuit je controllers.

voorbeeld

PHP:

class eventController {
    function indexAction {
        $event = Event::getEventById($id);
        $inschrijvingen = $event->getInschrijvingen();

        // do view stuff
    }
}

In dit geval zou je ook alleen het event object aan je view kunnen geven, waarna de view de inschrijvingen ophaalt

[ Voor 7% gewijzigd door Pete op 15-08-2008 10:19 ]

[Jigs]

phsmit schreef op vrijdag 15 augustus 2008 @ 10:18:
(...)

Het is niet duidelijk wat je bedoeld met de koppeling met het model. In dit geval zou je 3 classen aanmaken in het model. Al deze 3 klassen kun je aanroepen vanuit je controllers.

(...)

Ik zal het proberen nog wat duidelijker uit te leggen. Het is mij bekend dat de ZF ook met Actions werkt en dat je binnen een controller meerdere actions kan definieren.
Het probleem wat je hebt met drie controllers is dat je de scheiding tussen de controllers (die in deze voorbeeld applicatie soms flinterdun is ) moelijk kunt bepalen waar een bepaalde action thuis hoort.

Bijvoorbeeld ik heb een action listEvent met id =1. Bij deze action laat het systeem alle gegevens van event id = '1' laten zien. Maar bij de zelfde action laat het systeem ook alle inschijvingen van deze event zien. Dus je hebt een mix an inschijvingen en events. Daarom dacht ik juist dat het verstandig zou zijn om maar één controller te maken.

Verder ga ik denk ik wel een apparte application controller maken om te voorkomen dat er een te grote rotzooi ontstaat. Wat je krijgt is dus:


View -> Controller-> Application-Controller -> Model


Voor duidelijke overzicht van de opties heb ik in google docs een opzetje gemaakt. Zie http://docs.google.com/Doc?id=djrcvbh_1186gvgg7xf2

[ Voor 5% gewijzigd door Jigs op 15-08-2008 11:19 . Reden: Toevoegen Url ]

[Orphix]

Je moet meerdere controllers hebben. Gedeelde behaviour moet je op andere (tradtionele)OO manieren oplossen: compositie of inheritance. Dit staat verder los van de opdeling in je MVC framework. De controller is de spin in het web, vaak doet het niet veel meer dan simpele coordinatie-taken. Voor het ophalen van data heb je je datalaag (repositories), het verwerken van transacties eventueel je applicatielaag (services) en de business-rules worden gecontroleerd door je model. Al deze code hoort dus niet in je controller.

Als er teveel functionaliteit in je controller zit dat ook handig blijkt te zijn in andere controllers duidt dit vaak op geen of een verkeerde scheiding van functionaliteit en wordt het tijd om gedeelde code ergens anders onder te brengen.

[YopY]

Controllers moet je in dit geval niet verwarren met je models. Bij je voorbeeld zeg je dat een Event hebt, die ook een aantal Inschrijvingen heeft. In zo'n geval kun je zeggen mijn Event heeft een X-aantal Inschrijvingen, da's (volgens mij) duidelijk alleen in je data.

In je model-laag (Zend_Db_Table, in dit geval) zet je vervolgens de logica die de Inschrijvingen koppelt aan de Events (zo van, als je event 1 ophaalt, haalt 'ie en plakt 'ie er gelijk de inschrijvingen die daarbij horen aan). De action / controller heeft daarbij, als het goed is, helemaal niks te maken met de inschrijvingen van dat Event - het enige wat die doet is het Event uit de model-laag halen en die doorsturen naar de View, die er vervolgens zelf de eventuele inschrijvingen uit haalt.

[Gremen]

Even een vraag over het model gedeelte:

model-laag (Zend_Db_Table, in dit geval) zet je vervolgens de logica

Zo ben ik het ook gewend bij het werken met MVC applicatie's / framework.

Ik zag alleen in de quickstart tutorial van zend dat ze een model classe hebben, maar daaronder nog een aparte DB_table classe welke door het model word gebruikt. Vinden jullie dit logisch en hoe doen jullie dit meestal? Dus:
- Een model classe extend Zend_Db_Table
of
- Een model classe met daaronder een aparte db classe extend Zend_Db_Table

[Jigs]

Gremen schreef op vrijdag 31 oktober 2008 @ 12:06:
Even een vraag over het model gedeelte:


[...]


Zo ben ik het ook gewend bij het werken met MVC applicatie's / framework.

Ik zag alleen in de quickstart tutorial van zend dat ze een model classe hebben, maar daaronder nog een aparte DB_table classe welke door het model word gebruikt. Vinden jullie dit logisch en hoe doen jullie dit meestal? Dus:
- Een model classe extend Zend_Db_Table
of
- Een model classe met daaronder een aparte db classe extend Zend_Db_Table

Zend heeft geen model class. Dit is omdat het model alles kan zijn. Ene keer is het een tekst bestand, andere keer een database en weer een andere keer een webservice.

[Gremen]

Inderdaad, het viel me al op dat in hun voorbeeld het model verder geen extend oid had.
En vandaar dat ze het model los hebben getrokken van de data laag, zodat je model ook op iets anders dan een database kan werken.

[YopY]

Gremen schreef op vrijdag 31 oktober 2008 @ 12:06:
Ik zag alleen in de quickstart tutorial van zend dat ze een model classe hebben, maar daaronder nog een aparte DB_table classe welke door het model word gebruikt. Vinden jullie dit logisch en hoe doen jullie dit meestal? Dus:
- Een model classe extend Zend_Db_Table
of
- Een model classe met daaronder een aparte db classe extend Zend_Db_Table

In Zend Framework heb je eigenlijk twee abstracties - een database rij (= 1 record, je model) en een database tabel (de DB_Table). Je kunt de Table-abstractie in dit geval zien als een Data Access Object, een manier om bij je rijen (models) te komen. Het model is de gegevens, de table is de manier om bij de gegevens te komen. Zo hou je de verantwoordelijkheden gescheiden, en is het model (de rij) niet verantwoordelijk voor zijn eigen opslag.