[php] ong. dezelfde code op meerdere plaatsen

[xces]

Als jullie een "app" bouwen in php, en je list bijv. members op 1 pagina, en je hebt bij een andere pagina ongeveer dezelfde content nodig, hoe doen jullie dat dan?

scenario:
Met php5 classes heb ik nu DB objecten gedefineerd. Ik kan een ->loadRecords(..) doen, en krijg dan een array van die objecten terug. Aangezien ik geen volledig object aan (in dit geval) smarty wil geven, omdat deze dan ook de "save" en "delete" functionaliteit hebben loop ik door alle gevonden objecten en bouw dan een associative array van de waardes die van toepassing zijn voor die template. Maar ik kom erachter dat ik veel van dezelfde code hergebruik, wat natuurlijk niet alles ten goede komt.

Hoe doen jullie zoiets? Ik zou natuurlijk een "read-only" object kunnen teruggeven, maar dit moet dan wel op 1 of andere manier verheven kunnen worden tot een "beheer" object. Ik zal vast niet de eerste zijn met deze soort denkwijzes. Heeft het een naam, is een pattern voor, of is het misschien anders reeds geimplementeerd?

[BCC]

Dat pattern heet DRY Wikipedia: Don't repeat yourself , maar de implementatie ligt natuurlijk nogal aan de situatie.

[xces]

Ik hoor jullie denken; MVC framework maar dat is denk ik weer te zwaar. Iemand ideen?

[ Voor 109% gewijzigd door xces op 29-09-2009 18:47 ]

[disjfa]

Ik zie het probleem al niet.Je hebt de zaken toch al in 1 object zitten. Een smartytemplate kan in inladen waar je wilt. Dus wat heb je al en hoe zou je het liever zien. Je geeft nogal weinig info.

[mithras]

Tja, dat je in je template je object kan aanpassen /behoort/ inderdaad tot een mogelijkheid. Het is afaik gewoon een kwestie van niet doen Ook met MVC ga je dit soort dingen echt niet ondervangen hoor

Ik zou zeggen: het is een kwestie van good practice om in smarty niet de save() method te gebruiken. Ik neem aan dat je geen lutsers aan je template laat klussen, dus dat in weze je die controle zelf in de hand hebt? Het ombouwen van objecten naar arrays is namelijk erg kostenintensief en daarnaast geeft het je meer beperkingen dan je lief is ...

/edit: om specifiek te zijn: je herkent je DRY principe inderdaad, dat is goed! Welk pattern je hiervoor inzet om dit te voorkomen is verder nogal afhankelijk van de situatie wat je wilt bereiken

[ Voor 15% gewijzigd door mithras op 29-09-2009 19:00 ]

[Woy]

In het geval van je scenario zou ik het anders aanpakken, namenlijk gewoon je objecten geen load/save/delete methode geven maar deze in een Repository/Dao object stoppen. Je entity hoeft namenlijk helemaal niets te weten over de manier waarop hij opgeslagen word.

Over het herhalen van code en de manier hoe je dat oplost hebben de mensen hierboven al terecht opgemerkt dat dat nogal van de situatie afhangt.

[BCC]

Kun je een object niet freezen?

[xces]

@Woy; je bedoeld dat je 1 DAO object hebt per record, en 1 Repository object per record, waarbij het DAO dan eventueel het repository object extend?

[Creepy]

Wat concreter dan: Je moet denken aan zaken als:

Customer cust = customerDAO->getcustomer(id);

en

customerDAO->saveOrUpdate(cust);
customerDAO>delete(cust) of misschien wel customDAO->delete(id);

Oftwewel: je maakt per class die je uit een database wilt halen of opslaan een bijbehorende DAO. Die DAO weet hoe je de betreffende class kan opslaan en weer uit de database vissen. Zo heb je de database functionaliteit gewoon gescheiden van de daadwerkelijk class.

[xces]

Wat simpel, dat ik hier niet aan gedacht heb
Hier kan ik wat mee!
thnx