Separarea logicii de continut
Moderatori: Moderatori, Start Moderator
-
aurelian
- Senior Member
- Mesaje: 833
- Membru din: Dum Iun 01, 2003 7:54 pm
- Localitate: Bucuresti
- Contact:
Intrebari clasice:
-> cat de usor poti adauga o functionalitate noua?
-> cat de usor poti modifica aspectul siteului?
-> ce se va intampla cand cerintele se vor schimba?
-> vei fi in stare sa folosesti/citesti codul respectiv dupa o perioada de timp?
Din proprie experienta:
Folosirea celor 30-40 de functii este un lucru foarte rau. Mai devreme sau mai tarziu se va intampla sa te trezesiti cu doua functii cu nume diferite care au insa o comportament identic. Sau, foarte posibil sa uiti practic de anumite functii sau de comportamentul lor. Mentinera in viata a unui astfel de sistem este foarte grea.
Deci, grupeaza functiile cu comportament asemanator in clase, tine cate o clasa/fisier, documenteaza codul scris (cu phpdoc) fara a exagera.
Ar trebui sa stiu sa utilizez si eu codul scris de tine doar citind numele metodei (functiei) al parametrilor pe care ii acepta si eventual al rezultatului returnat. Nu ma intereseaza cum faci sa ajungi la respectivul rezultat.
Tot din experienta iti spun ca in cadrul unui proiect (mediu-mare) in php lucrul care se va schimba cel mai des va fi modul de prezentare a paginii web. Deci logica ramane de foarte multe ori aceiasi. De aici prima mea recomandare, care practic te va obliga sa nu mai folosesti if/else switch/case (decat foarte rar), este folosirea unui template engine.
Smarty este OK, dar webdesignerii am observat ca au ceva probleme in a lucra cu tagurile {}. De curand am descoperit phptal (php 5 only). Probabil sunt in jur de 70-80 de template-engineuri ptr. php.
Un DB Abstraction Layer nu iti va aduce un mare castig (de separarea conceptelor de prezentare/logica nici nu poate fi vorba). Iar portabilitatea este un mare vis, in realitate cred ca este practic imposibil sa scrii o aplicatie care sa mearga fara nici o interventie sau fara nici un rand de cod scris in plus pe doua servere SQL diferite.
Dupa parerea mea, singurul avantaj consta in faptul ca vei avea aceleasi nume pentru metodele apelate indifirent ca folosesti mysql sau pgsql.
Codul procedural nu iti aduce nici un castig de viteza, din contra, aplicatiile procedurale sunt mai lente. (HF)
-> cat de usor poti adauga o functionalitate noua?
-> cat de usor poti modifica aspectul siteului?
-> ce se va intampla cand cerintele se vor schimba?
-> vei fi in stare sa folosesti/citesti codul respectiv dupa o perioada de timp?
Din proprie experienta:
Folosirea celor 30-40 de functii este un lucru foarte rau. Mai devreme sau mai tarziu se va intampla sa te trezesiti cu doua functii cu nume diferite care au insa o comportament identic. Sau, foarte posibil sa uiti practic de anumite functii sau de comportamentul lor. Mentinera in viata a unui astfel de sistem este foarte grea.
Deci, grupeaza functiile cu comportament asemanator in clase, tine cate o clasa/fisier, documenteaza codul scris (cu phpdoc) fara a exagera.
Ar trebui sa stiu sa utilizez si eu codul scris de tine doar citind numele metodei (functiei) al parametrilor pe care ii acepta si eventual al rezultatului returnat. Nu ma intereseaza cum faci sa ajungi la respectivul rezultat.
Tot din experienta iti spun ca in cadrul unui proiect (mediu-mare) in php lucrul care se va schimba cel mai des va fi modul de prezentare a paginii web. Deci logica ramane de foarte multe ori aceiasi. De aici prima mea recomandare, care practic te va obliga sa nu mai folosesti if/else switch/case (decat foarte rar), este folosirea unui template engine.
Smarty este OK, dar webdesignerii am observat ca au ceva probleme in a lucra cu tagurile {}. De curand am descoperit phptal (php 5 only). Probabil sunt in jur de 70-80 de template-engineuri ptr. php.
Un DB Abstraction Layer nu iti va aduce un mare castig (de separarea conceptelor de prezentare/logica nici nu poate fi vorba). Iar portabilitatea este un mare vis, in realitate cred ca este practic imposibil sa scrii o aplicatie care sa mearga fara nici o interventie sau fara nici un rand de cod scris in plus pe doua servere SQL diferite.
Dupa parerea mea, singurul avantaj consta in faptul ca vei avea aceleasi nume pentru metodele apelate indifirent ca folosesti mysql sau pgsql.
Codul procedural nu iti aduce nici un castig de viteza, din contra, aplicatiile procedurale sunt mai lente. (HF)
-
mihnea sim
- Average Member
- Mesaje: 149
- Membru din: Vin Aug 20, 2004 9:15 pm
- Localitate: Alexandria
- Contact:
Eu am lucrat de vreo 3 ori strict cu functii. De doua ori mi-a iesit o treaba buna. Este intr-adevar un pas in fata in domeniul programarii in php (e undeva la nivelul incepator -> medium), trebuie insa sa stapanesti bine cateva notiuni:
- transferul de parametrii (prin valoare, prin referinta, parametrii ce pot lipsi la apel)
- folosirea variabilelor (formale, globale) Atentie .. pt a folosi intr-o functie o variabila globala aceasta tb redeclarata cu global $var; in functie
- diferenta intre functiile care au return si cele gen proceduri.
- lucrul cu return .. care face (dupa mine) toata frumusetea acestui mod de programare
Pentru cei ce reusesc sa lucreze curat vor descoperi ca este o modalitate prin care se pot face lucruri mari prin efort mic. Prima oara mi-a iesit ceva ingrozitor .. vreo 20 de functii .. multe se repetau, multe nu erau folosite pe nicaieri .. iar fisierul ajunsese la 50 Kb
Inca un considerent: nu turnati toate functiile intr-un singur fisier. Tb sa evitati erorile de genul -- function already declared (sau ceva de genul). Si de asemenea .. ingreuneaza scriptul declararea a 20 de functii si utilizarea a numai 3. Incearca pe cat posibil sa declari functiile in locurile in care le folosesti, si doar pe cele "globale" intr-un fisier separat. Poti face ceva de genul: "math_f.php" "print_f.php", "filter_f.php" adika un fel de biblioteci de functii .. clasificate in functie de nivelul de utilizare al lor (aici depinde si de ce proiect vrei sa realizezi). Si nu in ultimul rand .. da nume sugestive functiilor, comenteaza tot ce e ambiguu si poti uita .. si mai ales ai mare grija cu return -ul. In el sta toata puterea. Succes!
- transferul de parametrii (prin valoare, prin referinta, parametrii ce pot lipsi la apel)
- folosirea variabilelor (formale, globale) Atentie .. pt a folosi intr-o functie o variabila globala aceasta tb redeclarata cu global $var; in functie
- diferenta intre functiile care au return si cele gen proceduri.
- lucrul cu return .. care face (dupa mine) toata frumusetea acestui mod de programare
Pentru cei ce reusesc sa lucreze curat vor descoperi ca este o modalitate prin care se pot face lucruri mari prin efort mic. Prima oara mi-a iesit ceva ingrozitor .. vreo 20 de functii .. multe se repetau, multe nu erau folosite pe nicaieri .. iar fisierul ajunsese la 50 Kb
Inca un considerent: nu turnati toate functiile intr-un singur fisier. Tb sa evitati erorile de genul -- function already declared (sau ceva de genul). Si de asemenea .. ingreuneaza scriptul declararea a 20 de functii si utilizarea a numai 3. Incearca pe cat posibil sa declari functiile in locurile in care le folosesti, si doar pe cele "globale" intr-un fisier separat. Poti face ceva de genul: "math_f.php" "print_f.php", "filter_f.php" adika un fel de biblioteci de functii .. clasificate in functie de nivelul de utilizare al lor (aici depinde si de ce proiect vrei sa realizezi). Si nu in ultimul rand .. da nume sugestive functiilor, comenteaza tot ce e ambiguu si poti uita .. si mai ales ai mare grija cu return -ul. In el sta toata puterea. Succes!
"o istorie aberanta si injusta copleseste fiinta si o arunca afara din lumea ei"
Cine este conectat
Utilizatori ce ce navighează pe acest forum: Niciun utilizator înregistrat și 29 vizitatori