model of niet?
Een vraagje. Ik ben een (op zichzelf staande) controller class aan het maken die iets heel simpels doet. Namelijk kijken of het subdomein van een URL voldoet aan een bepaalde waarde. Zo ja, dan doorsturen naar een andere url.
Nu gaat het maar om een stuk of 3 subdomeinen die ergens naar moeten worden doorgestuurd:
subdomein1.mijnsite.nl
subdomein2.mijnsite.nl
subdomein3.mijnsite.nl
Alle andere subdomeinen moeten worden genegeerd.
Die controller doet dus niet veel meer dan kijken wat de opgevraagde URL is. Komt het subdomein overeen met een van de voorgedefinieerde subdomeinen dan doorsturen naar andere url. Komt het niet overeen, dan niks doen.
Nu vraag ik me af... zal ik die 3 subdomeinen in dezelfde controller class, als property, opslaan? Of misschien in een config (.ini) bestandje? Of behoor je die subdomeinen via een model op te halen? Omdat het er maar een stuk of 3 zijn, vraag ik me af of ik daar dan speciaal een model voor moet aanmaken?
Gebruik je normaal gesproken een model alleen om iets uit de database te halen?
Als je in je controller zowel gaat controleren of de waarde overeenkomt met bepaalde toegestane waardes, alsook gaat bepalen wat de toegestane waardes zijn, dat doet hij dus twee dingen. Oftewel niet in de controller zetten.
Gewijzigd op 02/01/2013 11:07:38 door Erwin H
kortom...het is niet gewoon op zoek naar een model, maar naar een model dat past bij je wensen en eisen...
@Hense: nee, niet zoals hyves. Het redirect naar sites die ik zelf host.
Erwin H op 02/01/2013 11:06:51:
Regel 1 van een class: zorg dat elke class altijd maar 1 doel heeft.
Als je in je controller zowel gaat controleren of de waarde overeenkomt met bepaalde toegestane waardes, alsook gaat bepalen wat de toegestane waardes zijn, dat doet hij dus twee dingen. Oftewel niet in de controller zetten.
Als je in je controller zowel gaat controleren of de waarde overeenkomt met bepaalde toegestane waardes, alsook gaat bepalen wat de toegestane waardes zijn, dat doet hij dus twee dingen. Oftewel niet in de controller zetten.
Hier ben ik het niet mee eens, volgens mij haal je hier methodes en classes door mekaar. Dit wordt denk ik een soort van dispatch controller. Die kan best kijken of hij mag forwarden naar een nieuwe url én het forwarden zelf
Echter, als de controller de waardes krijgt (bijvoorbeeld in een array) vanuit een ander object, dan kan je deze controller een volgende keer ook weer gebruiken. Je hoeft dan alleen de class aan te passen die de waardes levert (en dat klopt, immers de waardes zijn anders in een volgende applicatie).
En dan waar moeten de waardes vandaan komen: uit een model. Daarbij moet je in mijn ogen het model niet gelijkstellen aan de database. Het model levert de data. Hoe en waar het vandaan komt is daarbij niet van belang (in elk geval niet voor de controller). In deze applicatie, omdat het er erg simpel is, zou je een model class kunnen schrijven die maar 1 methode heeft en die ene methode geeft een array terug met 3 waardes. Een volgende keer schrijf een model class die er een hele database infrastructuur achter heeft zitten. Weer een volgende keer krijgt het model de waardes van een externe website. Heck, desnoods zit er een kabouter achter die elke keer de waardes uit zijn hoofd inklopt. Als de model class maar elke keer dezelfde interface implementeert is er niets aan de hand en krijgt de controller gewoon de waardes die die nodig heeft.
@Not Moose: precies zoals jij het omschrijft. Een methode mag inderdaad maar 1 ding doen.
@Erwin: ja, daar zit ook wel weer wat in. Maar de vraag is of je het hier "moet" doen, omdat het zo weinig subdomeinen zijn.
Gewijzigd op 02/01/2013 11:25:15 door Ozzie PHP
Not Moose op 02/01/2013 11:17:22:
Hier ben ik het niet mee eens, volgens mij haal je hier methodes en classes door mekaar. Dit wordt denk ik een soort van dispatch controller. Die kan best kijken of hij mag forwarden naar een nieuwe url én het forwarden zelf
Nee, im mijn ogen absoluut niet. De reden is heel erg simpel. Als je deze functionaliteit allemaal in 1 class stopt kan het prima doen wat je nu wilt. Echter, wil je de volgende keer (bij een andere applicatie) ook kunnen forwarden, maar in een heel andere situatie, dan kan je je code niet nog een keer gebruiken. Het hele idee van OOP is dat je functionaliteiten scheidt, zodat je componenten kunt hergebruiken. Essentieel is dan wel dat je functionaliteit goed gescheiden houdt.
Toevoeging op 02/01/2013 11:33:20:
Ozzie PHP op 02/01/2013 11:23:42:
@Erwin: ja, daar zit ook wel weer wat in. Maar de vraag is of je het hier "moet" doen, omdat het zo weinig subdomeinen zijn.
Ja. Ik zou er niet eens over nadenken. Zie ook mijn reactie hierboven. Het gaat niet om de situatie nu. Als je alleen naar de situatie nu kijkt kan je het heel simpel in spaghetti code in 2 of 3 regels doen. Dat is niet wat je wilt, je wil het in OOP, doe het dan goed in OOP.
Ozzie PHP op 02/01/2013 11:23:42:
@Not Moose: precies zoals jij het omschrijft. Een methode mag inderdaad maar 1 ding doen.
Nee, dan heb je het over functioneel programmeren, niet over OOP. Binnen OOP zijn het de classes die je herbegruikt, niet de functies (methodes). Daarom gaat het erom dat je binnen OOP de functionaliteiten scheidt tussen de classes, niet tussen de functies.
Wouter J op 02/01/2013 11:34:21:
Goed, ik begrijp beide kanten. Erwin lijkt het alleen wat moeilijker te maken, wat volgens mij niet nodig is. Is het nu niet zo dat je nu het probleem opschuift? Als je het in de controller opslaat hoef je alleen de controller aan te passen, als je een model maakt en daar de info van de controller instopt dan moet je de model aanpassen. Het lijkt me hetzelfde, behalve dat je een andere klasse hebt die je moet aanpassen?
Noem het zoals je wilt. Waar ik naar kijk is hoe je het binnnen een grotere applicatie zou doen. Als je een omgeving hebt waarbinnen de mogelijke correcte waardes van meer dingen afhankelijk zijn en dus niet simpel uit te schrijven zijn, waar zou je de waardes dan bepalen? Als dan je antwoord is: in de controller, dan kan je het nu ook in de controller doen. Als je antwoord dan is: in een model, dan zou ik het nu ook in het model doen.
Erwin H op 02/01/2013 11:35:24:
Nee, dan heb je het over functioneel programmeren, niet over OOP. Binnen OOP zijn het de classes die je herbegruikt, niet de functies (methodes). Daarom gaat het erom dat je binnen OOP de functionaliteiten scheidt tussen de classes, niet tussen de functies.
Ozzie PHP op 02/01/2013 11:23:42:
@Not Moose: precies zoals jij het omschrijft. Een methode mag inderdaad maar 1 ding doen.
Nee, dan heb je het over functioneel programmeren, niet over OOP. Binnen OOP zijn het de classes die je herbegruikt, niet de functies (methodes). Daarom gaat het erom dat je binnen OOP de functionaliteiten scheidt tussen de classes, niet tussen de functies.
Daarom vroeg ik ook of het vaker zou voorkomen. Mocht je een gigantische waslijst hebben van data die geforward moet worden dan zou ik het zelf opslaan in de database. Maar aangezien het maar 3 domeinen zijn kan je dit ook gewoon in een constante opslaan. Je kunt ook overabstraheren he