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.

Condividi:
Facebook
LinkedIn
error: