 |
Forum PHP Romania - Discutii despre PHP, MySQL, Javascript, AJAX, etc Comunitatea PHP Romania
|
| Subiectul anterior :: Subiectul următor |
| Autor |
Mesaj |
w31rd0
Data înscrierii: 15/Mar/2004
Mesaje: 165
Locație: Timisoara
|
| Trimis: Lun Mar 15, 2004 10:43 am Titlul subiectului: Some design patterns |
|
|
Cam ce Patterns foloseste lumea in ziua de azi? :), Am folosit MVC pana acuma in JSP, si in PHP5B3, am insa o mare problema de design in acest sens.
Aplicatia JSP (proiect de diploma), era functionala in stadiul final insa implementarea la nivel de design era total aiurea :(, nu am mai urmat de la inceput ceea ce ne-am propus (eram 2).
La fel pot spune ca am avut ceva probleme la aplicatia realizata in Php5B3, cu toate ca nu este mare si poate fi destul de usor modificata (cam o sapt).
Problema mea la nivel concret este faptul ca imi doresc o separare clara pentru un layer care se se ocupe cu tranzactiile de date.
Altfel spus sa existe o clasa sau un set de clase care sa abstractizeze lucrul cu o sursa de date, iar rescrierea acestora (fara modificarea restului aplicatiei) sa poate schimba sursa de date (de exemplu o un server de Mysql, sau un server de IMAP pentru o aplicatie ce se ocupa de mailuri, care in primul exemplu sunt redirectionate intr-o BD).
Care este problema?:
Pai intr-o aplicatie OOP de genul, avem un obiect Mail. Un alt obiect poate fi Folder (o colectie de Mail-uri cu anumite proprietati).
Metodele de operare asupra acestor obiecte vor fi inglobate in clasele amintite sau intr-o alta clasa ?(ceva de genul DbTranzaction), pentru a putea obtine o definire clara si logica a codului?
Acesta este doar un exemplu,:) din ceea ce am citit pe net si din cateva coduri sursa studiate (date ca exemplu pt implementarea MVC), nu am gasit o solutie care sa ma faca sa o consider logica ca si structurare.
Exemplele aveau o clasa ce modela un obiect, iar metodele de "lucru-modificare" a datelor la nivelul unei DB erau intr-o alta clasa care se ocupa de realizarea query-urilor. Partea ciudata era ca aceste query-uri erau trimise ca parametru din Clasa Obiect-ului (cum ar fi in exemplul dat de mine Mail). Cum se poate schimba atunci sursa de date?, daca nu se mai doreste sa fie o BD.
Sper ca nu am fost prea vag, scuze daca nu se intelege exact ce subiect am vrut sa tratez, va rog sa imi puneti intrebari ca sa ma pot face inteles. :)
mersi,
Seba |
|
| Sus |
|
arond
Data înscrierii: 11/Mar/2004
Mesaje: 580
Locație: 127.0.0.1
|
| Trimis: Lun Mar 15, 2004 6:05 pm Titlul subiectului: |
|
|
Din ce am inteles, ce iti doresti tu de fapt este abstractizarea accesului la sursa de date pe care o folosesti.
In principiu asta se realizeaza folosind o ierarhie de clase intermediara, care expune layer-ului superior (de obicei clasele care implementeaza business logic-ul) o interfata standard, detaliile de acces la sursa de date fiind implementate in aceasta ierarhie intermediara. E cam ce ai vazut tu in implementarile MVC de care pomeneai.
Problema ta este nivelul de abstractizare si aici lucrurile sunt destul de delicate. Daca iti doresti o abstractizare mai viguroasa decat SQL, atunci n-ai decat sa creezi inca un nivel intermediar care sa expuna o interfata standard de acces la inregistrari (date), ie. retrieve, add, update... si sa folosesti in implementare ce vor muschii tai (cu drivere, etc... un exemplu bun e PEAR::DB).
Dar aici trebuie pastrat un echilibru... in sensul ca in general cu cat abstractizarea merge mai sus cu atat performanta scade. Un exemplu concret este SQL vs. o abordare generica, in sensul ca vei face multe scamatorii (probabil mari mancatoare de resurse) sa definesti interfetele pentru/sa implementezi functionalitatea echivalenta unui JOIN (chiar si a unuia simplu).
Ptiu, ce post lung :). |
|
| Sus |
|
Emil
Data înscrierii: 16/Noi/2003
Mesaje: 301
Locație: echo $REMOTE_ADDR
|
| Trimis: Lun Mar 15, 2004 7:27 pm Titlul subiectului: |
|
|
Intr-adevar , cu abstractizarea se poate merge pana la ce nivel se doreste ,insa cu pretul performantei , lucru care trebuie luat in considerare .
Personal folosesc Pear::DB , care spre norocul meu e unul din putinele pachete carora li s-a dat o importanta si rigurozitate foarte mare in dezvoltare si documentare .
In benchmark-uri se comporta acceptabil , deci raportul ergonomie/performante mi se pare mai mult decat rezonabil .
Mai bine se pare ca se claseaza ADODB , care inca nu l-am folosit din cauza ca am pornit la drum cu PEAR in ceea ce dezvolt acum si sunt pretty happy cu el . Pe viitor o sa-i acord o atentie mai mare , daca a folosit cineva ADODB m-as bucura sa aflu pareri ... |
|
| Sus |
|
PHPRomania Bot
Bot Member
Data înscrierii: 27/Dec/2007
Mesaje: 1
Locaţie: Server Google |
| Trimis: Mie Dec 26, 2007 7:01 pm Titlul subiectului: Ad |
|
|
|
|
|
| Sus |
|
| |
|