06.03.08
Swing şi MVC
După cum se ştie, componentele Swing au un design “model-vedere” separabil. Dar, în realitate, componentele Swing, nu sunt bazate pe arhitectura Model-View-Controller (MVC).
Scopul dezvoltării pachetului de clase/componente Swing a fost: construirea unui set de Interfeţe Utilizator care să permită programatorului o dezvoltare mai rapidă a interfeţelor front-end pentru aplicaţiile comerciale.
Din acest motiv, echipa de dezvoltare a pachetului Swing, de la SUN, şi-a stabilit un set de obiective de proiectare care a dus în final la această arhitectură. Aceste “linii directoare” s-ar putea concretiza în:
- o implementare în totalitate în Java, pentru a promova o coerenţă cross-platform şi o mentenanţă (întreţinere) uşoară
- furnizarea unui singur API, capabil să suporte multiple “look-and-feels”, astfel încât programatorii şi end-userii să nu fie blocaţi într-un singur “look-and-feel”
- activarea puterii de proramare “model-driven”, fără a fi necesară în cel mai înalt nivel de API
- adăugarea lui (a pachetulu Swing) la principiile de design pentru JavaBeans, astfel încât să se certifice o comportare bună a acestor componente în IDE-uri şi alte “build tools”-uri
- furnizarea compatibilităţii cu API-ul AWT, acolo unde există suprapuneri, pentru a eficientiza AWT-ul de cunoştinţele de bază şi portabilitate uşoară.
Arhitectura Swing are rădăcini în design-ul MVC (Model-View-Controller) care datează de la limbajul SmallTalk. Arhitectura MVC, aplicată pentru o aplicaţie vizuală, se împarte în trei componente distincte:
- un model, care reprezintă datele aplicaţiei
- view (vederea), care este o reprezentare vizuală a datelor
- un controller, care să preia datele introduse de utilizator în view şi traducerea acestor modificări în model.
La început, MVC a fost o alegere logică pentru Swing deoarece asigura o bază pentru întrunirea primelor trei principii de proiectare, dar cu probleme pentru stabilirea celorlalte două.
Primul prototip Swing a urmat o arhitectură MVC tradiţională, în care fiecare componentă avea un obiect model separat şi delega implementarea “look-and-feel”-ului la obiecte diferite de view şi controller.
Practica a arătat că acest prototip nu se comporta bine deoarece partea de view şi controller a componentei necesita o strânsă interacţiune (de exemplu: este foarte dificil să scrii un controller generic fără să ştii specificaţii despre view). S-a optat deci, pentru a uni aceste două entităţi într-un singur obiect de UI (User-Interface), aşa cum se arată mai jos:
Aşa cum se ilustrează în desenul de mai sus, arhitectura Swing a “pierdut” principiile de bază, dar nu cele strict de bază, ale unui design MVC tradiţional. În lumea Swing, acest nou design: cvasi-MVC, este uneori definit ca un model separat de arhitectură.
