Continuarea discuției de aici.
@Vilmos_Ioo Corect. Dar apoi apare urmatoarea intrebare: Ce diferentiaza un framework de o aplicatie? Unde se termina una si unde incepe cealalta? Si unde se incadreaza arhitectura de care vorbesti, in aceasta noua situatie?
(Daca este prea off-topic, poate ar fi necesar un fork…)
Un fork ar fii util.
Părerile mele sunt personale apropo.
O aplicație e mai mult product management decât development. Arhitectura/framework-ul afectează developerii, aplicația afectează userii. Aia e diferența.
imagineaza-ti frameworkul ca fundatia unei case, pe baza ei se construieste aplicatia dorita (respectiv pe baza fundatiei se construieste casa)
aplicatia e produsul finit care se poate utiliza de catre utilizatorul final (care habar nu are de cod)
frameworkul consta dintr-un set de librarii si metode de lucru care ajuta dezvoltatorul sa termine aplicatia intr-un timp mai scurt decat daca ar face totul de la 0 (e ca si cand ai cere constructorului sa faca sculele cu care va lucra si apoi sa faca restu - in cazul nostru sculele fiind librariile folosite)
arhitectura in schimb e un concept/motalitate de lucru/implementare bazat pe frameworkul folosit (fiecare framework te forteaza sa adopti un stil propriu de lucru, recomandat, desigur, poti reinventa roata si sa te scarpini dupa ureche cu degetul mic de la picorul stang, dar nu asta e scopul)
A ii atribui rolul de fundatie unui framework mi se pare prea mult.
Intr-o casa construita sanatos, un framework e un fel de instalatie sanitara - toate tevile dintr-o casa. Un framework trebuie sa fie mereu inlocuibil in aplicatiile de cel putin o complexitate medie (adica: vorbim despre case, nu despre colibe sau custi de caini).
Aparent a fost si formalizat conceptul:
partea interesanta de aici:
It asserts that architecture descriptions are inherently multi-view, no single view adequately captures all stakeholder concerns
Legat de intrebare: un framework elimina o parte din complexitatea in dezvoltarea unei aplicatii iar aplicatia este o varianta functionala a ceea ce stakeholders envisioned.
Demarcarea intre ele intre la nivelulul codului depinde de context si nu este ceva fix. In cel mai bun caz este “formalizata” sub forma unor patterns, best practices, principles, etc..
As dori sa prezint o alta persepectia asupra analogiei casa vs. framework. @Birkoff propune ca framework-ul sa fie “fundatia” casei tale. O analogie practicata destul de des, care are avantajele sale, dar si un mare neajuns.
Fundatie unei case trebuie intretinuta, protejata da infiltratiile de apa, consolidata din cand in cand. Ce faci, daca gramework-ul pe care ti-ai construit aplicatie devine abandonat? (Prototype.js anyone?). Daca ti se putrezeste fundatia, ti se darama casa. Va trebui sa il reconstruiesti.
La fel se intampla si cu aplicatiile. Daca iti bazezi aplicatia pe un framework, atata timp cat acel framework va fi intretinut, aplicatia ta va fi OK. Daca va fi abandonat, aplicatia ta va trebui rescrisa din temelii.
Propunerea mea de metafora
fundatia = paradigma de programare aleasa (OOP, functional, procedural) [ imposibil de schimbat fara rescriere totala ]
caramizile = limbajul de programare [ aproape imposibil de schimbat ] 
aranjarea spatiala a interiorului = arhitectura aplicatiei [ dificil de schimbat ] 
utilitatea casei si a camerelor sale = design-ul aplicatiei [ mediu de schimbat ] 
vopseaua = framework-urile (daca nu iti place una, dai cu alta. Azi vopsea Kober, maine Sawana, azi CakePHP, maine Laravel) [ usor de schimbat ] 
utilajele de constructie = frameworkurile de testing pentru TDD si testarea automata, precum si tool-urile de Continuous Integration [ usor de schimbat ]
galeata si lopata = IDE-ul tau preferat [ usor de schimbat ]
vopseaua = framework-urile (daca nu iti place una, dai cu alta. Azi vopsea Kober, maine Sawana, azi CakePHP, maine Laravel) [ usor de schimbat ]
am lucrat o perioada la o firma mare, aplicatia lor web avea aproape 500 mb (doar codul) si functiona pe mai multe frameworkuri (fiecare sectiune din aplicatie fiind scrisa in ani diferiti si de echipe diferite, fiecare echipa a folosit frameworkul pe care il cunostea) - cand trebuia sa rezolv un bug din aplicatie ma apucau damblalele, ba ajungeam in zend, ba in yii, ba in cacke ba in chestii procedurale ba in oop pana dadeam de bug (mai mult imi lua sa sap decat sa rezolv bugu)
acum vazand analogia ta, ma gandesc, ce papagal colorat aveau ei acolo :))