Design Pattern

[strofo]

[carco]

[strofo]

[carco]

[kelye]

[strofo]

Acum pot sa recunosc ca astfel de raspunsuri asteptam pe forum si ma bucur ca aceasta discutie nu s-a blocat in dictionar ci au aparut si ceva coduri sursa. Recunosc ca nu am mai scris de ceva timp php si nu mai sunt la curent cu scripturile actuale. Poti detalia "business-logic" si "presentation-logic"?
Mie unul mi se pare un lucru bun sa scrii cod incat sa fie usor de urmarit mai ales cand un script e spart in 3-4 fisiere distincte.
Da, sunt un fan Vista, si imi pare rau sa te dezamagesc, dar nu am furat nici un script pana acum. Faza cu timpii mici nu a iesit tocmai cum am vrut sa iasa - aveti dreptate; dar la faza cu resursele, e o diferenta intre eficienta si cat mai putine!

[carco]

In mare si nu prea stintiific, "" e partea ce se ocupa de modelarea si interconectarea entitatilor din lumea reala (ex. Utilizatori, Drepturi de acces, Datorii, Plati, ...) In aceasta bucata se extrag informatiile din baza de date, se fac updatari, se fac calcule, se inmulteste/imparte, adica se pregatesc datele de iesire.
"Presentation logic" se ocupa doar cu afisarea datelor puse la dispozitie de bucata de mai sus.

Cred ca articolul urmator spune mai multe decat as putea spune eu:
http://www.paragoncorporation.com/Artic ... ticleID=21

Referitor la problema ridicata de tine (separarea HTML de PHP, adica folosirea unui 'template engine'):
http://www.phppatterns.com/docs/design/ ... te_engines

[strofo]

[kelye]

[strofo]

[ExcalIbvr]

Raspunsul la intrebarea asta tine mult de circumstante.

1. Daca in aplicatia mea am nevoie sa creez un user, sa-i editez datele personale si sa-l si sterg, mi s-ar parea natural sa am o clasa User unde sa procesez tot business logic-ul.

2. Daca, insa, tot ce-am nevoie e sa inserez un user (putin probabil, totusi) atunci e OK si varianta a 2a.

[Dodo]

[strofo]

[punctweb]

[carco]