Blog | Febbraio 2008

07/02/08

Web Application: accoppiamento o disaccoppiamento?

Ancora a proposito di web framework… discorso inflazionato è vero ma a quanto pare tutt’altro che concluso! Il topic in questo caso è se in una web application sia meglio codificare tutto in una action oppure separare nettamente la web logic dalla business logic. La risposta parrebbe ovvia, ma non tutti sono dello stesso avviso.
Si possono catalogare fondamentalmente 4 approcci:

  1. Due classi: 1 action basata (*) sul framework e 1 business logic non basata sul framework
  2. Due classi: 1 action non basata sul framework e 1 business logic non basata sul framework
  3. Una classe: action e business logic nella stessa classe basata sul framework
  4. Una classe: action e business logic nella stessa classe non basata sul framework
    (*) si legga “che estende classi del framework”

Tra tutte l’approccio preferito è sicuramente il numero 1, la 2 rappresenta il totale disaccoppiamento (ad esempio in Struts 2 / Webwork le azioni possono essere POJO e quindi totalmente disaccoppiate dal framework), mentre 3 e 4 sono generalmente considerate bad practise. Esistono sicuramente buone ragioni per disaccoppiare la business logic dalla action:

  • Testability: se disaccopiata la business logic può essere testata in maniera indipendente (es. JUnit)
  • Web services: la business logic può essere utilizzata in un web-service o in servizi remoti
  • Caching: riferito alle business facades

Mentawai (un framework ad approccio programmatico con supporto per l’injection di cui esiste anche una versione Ruby) sembra offrire la libertà sufficiente per implementare tutti gli approcci (1,2,3,4). A voi la scelta…

Leggi anche l’articolo originale.

07/02/08

Introduzione ad Apache Wicket

Una lunga discussione sull’ennessimo web framework, Apache Wicket che viene qui paragonato al “fratello” Apache Tapestry, con divagazioni su JSF, GWT e sull’onnipresente Struts ovviamente. Tra i suoi punti di forza e innovazioni rispetto agli altri web framework vi sono:

  • Un eccellente supporto built-in ad AJAX;
  • La capacità di modificare la struttura delle pagine programmaticamente;
  • Perfetta separazione tra codice e templates (i templates non possono contenere codice);
  • Un approccio object-oriented
  • Facile apprendimento (per developers Java-oriented)

Naturalmente ci sono pro e contro, come in ogni cosa. Ma la principale ragione dell’esistenza di Wicket è che non esistono altri web framework programmabili in puro codice Java (quasi tutti seguono piuttosto il classico modello dichiarativo, con file di configurazione XML ad esempio). Naturalmente poi è anche questione di gusti, ma gli impatti più evidenti si hanno nell’ottimizzazione e nella versatilità del codice. In ogni caso anche Wicket, come pure Tapestry, Freemarker, JSF (con Facelets) e gli altri framework component-oriented rappresenta una valida alternativa ai precedenti framework Model 2 tipo Struts, tanto per citarne uno famoso 🙂

Leggi anche gli articoli originali: 1, 2 e 3

Facebook
LinkedIn
error: