[PHP/Zend Framework] Probleem met implementatie Models

Pagina: 1
Acties:

Onderwerpen


Acties:
  • 0 Henk 'm!

  • compubink
  • Registratie: September 2000
  • Laatst online: 11-09 20:14

compubink

...====...

Topicstarter
Ik ben al enige tijd bezig met het ontwikkelen van een applicatie met Zend Framework, hierbij gebruik ik de laatste versie. De modelarchitectuur is redelijk vrij gelaten door Zend, aangezien deze veel applicatie specifieke code bevatten. Hierdoor zijn er nogal wat verschillende implementaties beschikbaar. Ik heb hier al veel over gelezen (onder andere uit dit boek; http://www.survivethedeep....database.access.patterns), maar kom er nog niet helemaal uit met mijn implementatie.

Ik heb een aantal databasetabellen, ik zal enkele hieronder uitwerken;
item
  • item_id
  • user_id -> user.user_id
  • postdate
user
  • user_id
  • username
general (1-1 relatie met item)
  • item_id -> item.item_id
  • title
general_description
  • item_id -> item.item_id
  • description
various (1-many relatie met item)
  • item_id -> item.item_id
  • var1
  • var2
  • var3
Ik heb in de DbTable classes de relaties aangegeven en kan dus ook via item->findDependentRows(various) de gekoppelde rijen ophalen. Maar hoe kan ik dit het beste implementeren in mijn MVC applicatie? Het is natuurlijk zeer verleidelijk om enkele acties rechtstreeks op de DbTable classes uit te voeren, maar is dit de bedoeling of hoe kan ik dit via het model laten lopen?

Acties:
  • 0 Henk 'm!

  • storeman
  • Registratie: April 2004
  • Laatst online: 11:48
Ik spreek het model vrij vaak direct aan vanuit mijn controllers. Soms overrule ik de insert, update en delete methods om extra checks in te bouwen. Dit los ik liever niet op met andere functies in de tabel klasse, omdat je dan het risico loopt dat je per ongeluk toch direct de tabel aanspreekt en de wijziging niet gecontroleerd wordt. Dit kun je nooit helemaal ondervangen, omdat je met $adapter->query() alles kan doen.

In de controllers sla ik wijzigingen op naar de tabel of haal ik tabelrijen op. Als er bijzondere verrichtingen gedaan moeten worden, maak ik vaak extra functies aan in de tabel klasse of tabelrij klasse.

Een geformat adres kan ik bijvoorbeeld aanroepen vanaf klant, afhankelijk van het land:

PHP:
1
2
$rClient = $mdlClients->fetchRow(array('id = ?'=>1));
$address = $rClient->getAddress( $rCountry );

[ Voor 6% gewijzigd door storeman op 04-10-2010 13:01 ]

"Chaos kan niet uit de hand lopen"


Acties:
  • 0 Henk 'm!

  • Cartman!
  • Registratie: April 2000
  • Niet online
Waarom zet je title en description eigenlijk niet in je item tabel als het 1:1 relatie is, of bedoel je 1:many ? Ook var1, var2, var3 ziet er naar uit dat je verkeerd zit na te denken.

Acties:
  • 0 Henk 'm!

  • compubink
  • Registratie: September 2000
  • Laatst online: 11-09 20:14

compubink

...====...

Topicstarter
Het datamodel komt van een metadateringsstandaard (http://www.edustandaard.nl/afspraken/001). Ik heb er daarom voor gekozen mijn eigen toegekende variabelen (item_id ed.) te plaatsen in de overkoepelende tabel item. Alle containers vanuit de metadateringsstandaard zijn gekoppeld via het item_id. Dit is natuurlijk beter te normaliseren, maar met het oog op eventuele aanpassingen van de standaard leek mij deze implementatie de best mogelijke oplossing.

Het is een vrij groot dataschema dat geïmplementeerd moet worden, wat zou resulteren in een zeer groot model. Zou ik dit eventueel op moeten splitsen in meerdere modellen?

Acties:
  • 0 Henk 'm!

  • mithras
  • Registratie: Maart 2003
  • Niet online
Je moet modeleren naar functie en gedrag. Je moet niet zomaar alle velden in losse tabellen gaan stoppen, dat geeft veel te veel overhead.

Een voorbeeld: je hebt een user model. Deze user heeft een naam, email, id, password etc. Ook heeft een user een adres (straat, huisnummer, woonplaatst etc). Op dit moment kan je adresgegevens direct aan je user koppelen, maar feitelijk is het wel wat anders. Het is dan "gerechtvaardigd" om een apart user en apart adres model te maken. Zeker handig met het oog op mogelijk later meerdere adressen per gebruiker.

Om meer in te gaan op je vraag: momenteel gebruik ik Doctrine, een zeer handige ORM die direct je modellen mapt naar de database. De DbTable van ZF werkt met een Mapper. Je hebt een User model en een UserMapper die je user properties mapt naar database velden. En vervolgens stuurt de mapper alle operaties naar je UserTable.

Je kan in je controllers makkelijk werken met User. Dat gaat dan intern naar UserMapper en UserTable. Zie ook de quickstart van ZF.

[ Voor 29% gewijzigd door mithras op 04-10-2010 15:34 ]