Importanta abstractizarii ?

[kelye]

[Pirahna]

[aurelian]

[johnny]

[kelye]

concret .. ce ati recomanda :
1. adodb
2. propria clasa de mysql_connect (evident numai pt mysql )

parca ma tenteaza a doua varianta .. la o adica statement-urile sql difera putin intre un mysql si postgre sau altele (din ce am auzit eu) ..deci chit ca folosesc adodb.. tot trebuie sa modific si query-urile

[aurelian]

[carco]

eu sunt adeptul KISS (nici nu lucrez la proiecte supercomplexe) si nu-mi place sa depind de chestii foarte complexe asa ca fol. . Tot din categoria "lite" exista si un insa nu-l folosesc, prefer sa folosesc direct php-ul.

[PCPbSlack]

Chiar saptamana trecuta discutam cu cineva problema abstractizarii. Problema se punea asa: sa presupunem ca ai ocazia sa dezvolti un proiect foarte mare, avand la baza PHP/MySQL. Termini proiectul, esti fericit si continui sa lucrezi la altele. Dupa vreo 6 luni te suna firma careia i-ai facut proiectul de care vorbeam anterior si doreste ca toata aplicatia sa fie portata pe Oracle (nu conteaza motivul). In cazul de fata lucrul cu PEAR (de exemplu) este extraordinar, deoarece modificarile la nivel de cod sunt minime.

Insa personal cred ca abstractizarea avand la baza framework-uri dezvoltate de altii poate avea si avantaje, dar si dezavantaje.
Avantajele sunt numeroase si au in general la baza sintagma "de ce sa reinventez roata?".
Personal cred ca cel mai mare dezavantaj al unui framework este lipsa libertatii. Devii practic ingradit de ceea ce au gandit altii, si asta in timp te poate transforma intr-o "masina" de scris cod.

Concluzia este, foloseste framework daca ai nevoie de rapiditate in scrierea codului, evident excluzand timpul alocat studiului sintaxei framework-ului.

Legat de template-uri, eu unul folosesc SMARTY. Nu este perfect (si intre noi fie vorba nu cred ca exista un template engine perfect, obiectiv vorbind), dar imi satisface nevoile de zi cu zi , iar cand SMARTY nu poate face ceva, exista intotdeauna {php} {/php}.

[beeuser]

Eu personal trec incet incet pe Ruby On Rails. Merita sa dai o geana sa vezi macar cum functioneaza. Desigur nu o renunt la PHP....

Anyway, in PHP pentru separare logic/design folosesc phpSavant (www.phpsavant.com). Imi place ca foloseste php ca si template scripting. Nu trebe sa inveti alte sintaxe.
Si ca abstractizare pentru baza de date folosesc DB_DataObject de la PEAR.
(http://pear.php.net/package/DB_DataObject/)

Da-i bataie.

[aurelian]

[PCPbSlack]

[PCPbSlack]

Stiu ca acest mesaj poate fi foarte offtopic, dar kelye m-a pus pe ganduri cu acest topic.

Am ajuns in punctul in care am ceva aplicatii complexe dezvoltate si deja se pune problema actualizarii lor. Adica adaugarea de noi facilitati, scoaterea unora vechi etc. (stiu ca toti stiti ce inseamna actualizare, dar am tinut mortis sa spun asta ). Orice client are dreptul de a evolua, atat in ceea ce face, cat si in aplicatiile pe care le foloseste. Si asta nu poate fi decat de bine. Pana la urma toti ar trebui sa evoluam. Normal, iar am inceput sa bat campii ... !!! Sa revin totusi cu picioarele in apa.

Recunosc ca nu am folosit pana acum un framework. Am folosit cateva librarii de la PEAR. In rest, toate aplicatiile pe care le-am dezvoltat au fost facute in mare parte de la zero, pornind de la niste functii si clase deja dezvoltate. Am incercat sa dezvolt un framework propriu in jurul a ceea ce aveam, dar se pare ca nu am stofa necesara si recunosc asta. Dar pana atunci nu pot sa spun decat ca m-a fascinat un articol scris de h3raLd ().

Stiu ca, kelye se astepta la raspunsuri de genul: "Eu folosesc Mojavi pentru ca" sau "Eu folosesc phpMVC deoarece.", insa pana acum se pare ca nu le-a primit.

Eu voi incerca CakePHP si Mojavi, sa vedem ce iese. Daca imi place voi reveni cu detalii.

Numai bine.

[johnny]

Nu folosesc cake pentru ca partea de model este incarcata cu prea multe relatii (hasOne, hasMany sunt, ok, dar belongsTo, hasAndBelongsToMany - nu am ce face cu ele si uneori e mai bine sa scrii direct ceea ce vrei sa obtii in functiile tale din model), iar modul in care este structurat uneori te limiteaza si in cazul unui model mai complex ajungi sa suprascrii in modelul propriu tot ce era in Model si atunci nu prea mai este mostenire...
view-ul este relativ usor de folosit, nu foloseste template engine-uri cu sintaxa proprie s.a. Au pastrat o abordare clean. La controller mai am obiectii, dar sunt mai subiective ....

Mojavi este un framework matur, care a trecut prin cateva versiuni ... m-am limitat la a-l studia destul de superficial... paseaza mult obiectele de la o componenta la alta... a implementat si functii dedicate pentru a "pasa" referinte si nu obiectul intreg... Din cauza logicii au fost nevoiti sa continue in 2 directii: php4 (mojavi 2) si php 5(mojavi 3)

Oricum in Mojavi3 au mult de lucru, iar in trac se observa deja un ...

Fiecare developer are viziunea lui asupra unui framework, si la un moment dat isi identifica nevoile cu unul existent. Este importat sa studiezi ce exista deja, pentru ca nu are sens sa reinventezi roata (cu toate ca inveti ceva in timpul procesului). Daca nu isi identifica nevoile cu un framework existent, isi va crea unul propriu inspirat din cel care se apropie mai mult de nevoile si viziunea lui.
Daca in php nu gasiti un framework care sa va multumeasca, mai exista si alte limbaje de programare (Python - zope, django, cherrypy, Java cu framework-urile proprii - Tapestry, Struts, etc, etc, etc... ca sa nu mai mentionam si ruby cu rails...)
Alegerea este a ta. Nimeni nu poate sa isi impuna o opinie, pentru ca acea persoana nu poate sa gandeasca pentru tine.
Recomand sa iei la mana fiecare framework care te intereseaza, si sa realizezi cu el un proiect simplu: todo, lista de cumparaturi, ce vrei tu... dar sa implice o listare, editare, adaugare, validare, etc...Apoi, iti alegi unul si il folosesti...

[kelye]

[w31rd0]

Hai ca imi dau si eu cu parerea. Reciclarea codului nu este buna intotdeauna. Totul depinde destul de mult de cum iti concepi proiectul si ce anume se poate modifica in viitor. Deci privesti proiectul mai putin ca si programator si mai mult ca si potential utilizator.

De multe ori mai bine faci copy paste si ai 2 clase aproape identice, decat sa extinzi una abstracta, in ideea ca pe viitor se pot cere niste modificari majore la una dintre ele, si in acel moment sa ai cod reciclat nu va mai fii optim, va trebui sa split-ui logica.

Abstractizarea unei baze de date este foarte utila pentru aplicatiile mari si foarte mari, vei avea mai putine dureri de cap in cazul migrarii spre un alt server SQL, sau o alta sursa de date, dar pentru aplicatii mici medii, mai mult iti ingreunezi munca.

Dupa parerea mea, keep it clean & simple. Gandeste-te ca poate dupa tine va veni alt developer sa modifice ce ai scris tu, deci fa o structura cat mai logica.
Comenteaza codul si logica aplicatiei. Este vorba si despre lucrul in echipa aici.
Daca te complici cu un Framework, s-ar putea sa dureze mai mult sau egal studiul acelui framework, in raport cu timpul necesar modificarilor, in cazul unui programator care nu le-a incercat pe toate.

Daca lucrezi pe obiecte sau procedural, este tot o alegere de genul acesta.
Pentru treburi simple trimiti un eventual programator prin tz clase, cand nu isi avea sensul, de multe ori si functiile sunt destul de bune pentru o impartire logica a codului.

Inainte de PHP am lucrat un pic JSP, am ajuns la PHP ca si job, si clar am lucrat procedural, pentru ca suportul pt OO al PHP pe vremea aceaa mai mult isi batea joc de idee, mai mult te fortai sa lucrezi OO, decat sa lucrezi OO pentru ca asa este natural.

Si in ultimul rand Template-urile. Clar nu este de folosit vreun template engine. Mai mult pierzi performanta si te scarpini dupa cap.

Am citit la un moment dat un articol in care se vorbea despre faptul ca un template engine ar trebui sa separe logica de cod de logica de afisare, si nu logica de model de afisare. Si partea de afisare are logica ei, de ce sa folosesti un {foreach} cand are PHP deja asa ceva. Majoritatea template engine-urilor nu prea fac asta, nici chiar smarty, si atunci ce faci ajungi tot la {php} {/php}.

Codul tau poate fi usor delimitat de <?php ?>. Daca nu te zgarcesti la linii noi devine foarte usor de urmarit.
Eu folosesc "template-uri" care sunt defapt fisiere php, cu logica de php, dar in care predomina cod HTML. Logica de php lucreaza cu acesta din urma.

Cam atat din cum vad eu treburile.