Nell’ultimo anno ho avuto la possibilità, grazie ad Evermind, di concentrarmi sullo sviluppo di un software basato su AngularJS e dotnet (c#, Entity Framework 6) e composto da un centinaio di view; prima in modo alquanto superficiale, nell’ultimo quadrimestre sicuramente più intensamente.

Partiamo da un presupposto: AngularJS sta suscitando un interesse sempre crescente nel panorama degli sviluppatori. Interesse che, tuttavia, non corrisponde ad un effettivo utilizzo nei software presenti sul mercato. Questa difformità mi porta a riflettere, anche alla luce dell’esperienza che sto vivendo in prima persona.

Probabilmente questa incongruenza è da ricercarsi nell’elevata curva di apprendimento del framework di casa Google, soprattutto nelle prime fasi di utilizzo ?!

La prima domanda cui trovare risposta è: perchè scegliere AngularJS?

Per moda? Pessima scelta.

Per “provare” un nuovo scenario tecnologico? Pessima scelta.

Prima di iniziare a valutare AngularJS quale possibile soluzione, devi essere consapevole ed avere una grande maturità su alcuni concetti chiave, come ad esempio il pattern MVC (MVW), come JavaScript ed ancora di più sull’architettura software, meglio se test-driven.

AngularJS non è jQuery. Il primo è un framework, anche sufficientemente complesso; il secondo, invece, è una libreria, cioè un insieme di funzionalità che possiamo usare in vari contesti – e questa non è una differenza banale 🙂

La prima difficoltà che ho dovuto affrontare è il cambio di paradigma concettuale nel progettare l’architettura software. Abituato ad uno sviluppo basato su asp.net, piuttosto che asp.net mvc, con un largo uso di chiamate Ajax, controller e servizi web api, AngularJs mi ha portato all’inizio fuori strada nel non capire correttamente cosa sia e come si deve gestire lo $scope, i filtri, i servizi, i controller e le direttive. E poi la domanda ricorrente, che tuttora ogni tanto mi pongo (soprattutto quando sono solo a dover gestire alcune parti dell’applicativo): ma perchè questa (in)utile complessità?

I motivi che ci devono portare a scegliere AngularJS per lo sviluppo di un’applicazione software sono sostanzialmente tre:

• routing;
• two way binding;
• view engine

Inoltre, devi valutare bene le risorse a disposizione: strutturare un’architettura software che sia figa, riusabile e test-driven è la strada migliore, ma da quante persone è composto il tuo team di lavoro?

Per esperienza, se questo numero è inferiore a 3 ti sconsiglio di perseguire una strada del genere. In aggiunta, valutiamo sempre correttamente le skills di ogni singolo attore: riuscire a parallelizzare il lavoro di tutti, consente di sfruttare al massimo l’architettura software modulare che AngularJS nativamente ci porta a progettare.

Quindi, nel caso in cui dovessimo realizzare qualcosa di easy, come una pagina HTML piuttosto che un POC basic, beh forse AngularJS non è la strada da perseguire. Se, invece, vuoi lanciarti nello sviluppo di SPA (Single Page Application), AngularJS è di certo la soluzione che ti consiglio vivamente.

Ti lascio con un progetto trovato su GitHub che potrebbe tornarti utile: Angular Seed