In Radical abbiamo un interessante problema: tutto, ma proprio tutto, è basato su Dependency Injection e Invertion of Control.
Questo in soldoni significa che concetti come DI e IoC devono essere ben chiari al nostro utente finale.
Falso.
L’assunzione è semplicemente falsa, Radical è stato disegnato con l’intenzione di nascondere la necessità di DI e IoC semplicemente perché per un uso tradizionale del framework non sono necessarie, non lo sono veramente.
Al fine di semplificare ulteriormente la barriera d’ingresso facciamo largo uso di convenzioni. Ne abbiamo parecchie, sia per la fase di boot che per quella di runtime.
Mai scelta fu più nefasta
Sarò sincero dopo 10 anni posso dire che “convention over configuration”, nelle mani di qualcuno che non ha ben chiaro cosa sta succedendo, si trasforma molto rapidamente in magia voodoo.
“Convention over configuration” comporta che:
- Vai a caso e ogni tanto le cose funzionano ogni tanto no
- Devi per forza leggere la documentazione altrimenti vai a caso e torni al punto 1
- Se le convenzioni sono tante, e in un sistema complesso come una LOB in WPF sono tantissime, devi conoscere a menadito la documentazione, quindi torni al punto 2 oppure ti ritrovi al punto 1
Il problema è che 1, 2 e 3 riducono la facilità d’adozione drasticamente in un sistema complesso.
Configurazioni esplicite
Le configurazioni esplicite hanno il vantaggio che se non funziona è solo perché non l’ho configurato. Attenzione che questa cosa ha un interessante impatto dal punto del framework stesso:
- l’utente cerca di fare una cosa
- la cosa non è configurata
- l’utente si becca una bella eccezione che gli spiega perché
Nel caso delle convenzioni il motore è obbligato a fare un po’di ipotesi e “tirare” eccezioni non è sempre così facile o ovvio, con la conseguenza che ritorniamo a rendere fondamentale la lettura della documentazione.
Quindi?
Probabilmente la risposta non c’è, al di sotto di una certa soglia di complessità la configurazione esplicita è vincente, oltre diventa talmente tediosa che è più sensato comprendere a fondo la documentazione. È ovvio che se mettete il cappello di quelli che sviluppano il framework, la risposta mica vi piace :-)