Framework-free web programming
I presented “Framework-free web programming” at the Webtech conference yesterday. Here are the slides. There’s enough text in them to make them understandable, I hope. If you understand Italian, that is :-) I will translate them sooner or later.
November 12th, 2010 at 02:37
Molto interessante, in molti punti condivido le tue idee, soprattutto in ambito “piccoli progetti”. Ma quando la complessità del progetto cresce i framework ti danno quella marcia in più, ti permettono di condividere convenzioni conosciute, dandoti per definizione soluzione a dei problemi già noti.
Concordo sul passaggio di moda, è un aspetto deleterio, a cui oramai nel bene o nel male ho fatto il callo. Per quanto riguarda errori e feature, un fw sufficientemente maturo (magari con una comunità OS attiva, personalmente non mi inalbererei mai su uno proprietario tipo dotnet o simili) non dovrebbe soffrire di questi inconvenienti.
Pienamente d’accordo sull’utilizzo degli oggetti e dei pattern, a prescindere se si utilizzino fw o meno. Del resto il domain model, nell’ottica di un corretto design, non dovrebbe mai essere manipolato direttamente (a questo servono i dao, i dto, i controller, etc.).
La logica dei repository ti porterebbe a scrivere codice su codice per le relazioni n:m, a dovere gestire lazy o eager collection, etc.
D’accordo anche sulle performance: oggi tra MVC framework, Dependency Injection, ORM, etc. non è difficile arrivare a tempi di deploy di 5 minuti (anche se una buona adozione di TDD limita sensibilmente questi inconvenienti).
In passato ho provato a dominare i DB, ma è una procedura troppo prona agli errori, soprattutto quando si sviluppa in team (troppe convenzioni custom da dover ricordare). Oltretutto il livello di astrazione di un ORM disaccoppia l’applicazione dal DB, aumentandone la portabilità.
La generazione dell’HTML è quella su cui mi trovi meno d’accordo, in queste slide si intravedono le tag library e i component dei principali MVC.
In definitiva perché utilizzare i FW? Beh, la prima cosa che mi viene in mente è: per evitare di reinventare la ruota ogni giorno.
Chiaramente sono solo i miei 2 cent, piuttosto ti faccio i complimenti per l’analisi che hai svolto.
November 12th, 2010 at 02:42
Intanto grazie per la presentazione. Potresti espandere il discorso sul lato oscuro del DDD? Probabilmente nella presentazione dal vivo lo hai anche fatto, ma con le sole slide faccio un po’ fatica. Dal mio punto di vista se il domain model si riduce a uno schema dei dati e una serie di procedure in realtà hai un transaction script travestito, non un vero domain model (zio Brando se ci sei batti un colpo).
Anche se, in realtà, perfino lo stesso uncle Bob dice che ci sono “oggetti” (dati) e “oggetti” (dati e comportamento). Come sempre il confine può diventare labile :-)
November 12th, 2010 at 08:55
@Maurizio: ti faccio una domanda. Per che motivo non implementi tu stesso la soluzione nota ai problemi che capitano frequentemente? Altra domanda: se non “domini il database” allora lasci che sia lui a dominare te? Non lo dico per fare polemica, sono domande per me importanti.
@Andrea: hai già risposto tu, poi Alberto Brandolini ha fatto un’interessantissima presentazione subito dopo la mia e ha detto la stessa cosa. Il DDD non funziona se il domain model è “anemico”, cioè si riduce a replicare lo schema dei dati con “oggetti” che in realtà sono solo strutture dati con getter e setter.
Il problema è che molti leggono il libro del DDD e poi partono a implementare le “entities” come oggetti tristi e i “services” come procedure che lavorano sui dati.
L’altro problema è che *tutti* i framework Java ti spingono in quella direzione. OK, Hibernate non dovrebbe essere usato così, per come lo intendevano gli autori originali, ma non so per quale motivo quasi tutti lo usano per ragionare in maniera procedurale.
November 12th, 2010 at 11:35
Matteo, consider putting the presentation on slideshare
November 12th, 2010 at 11:49
[…] here: Extreme Enthusiasm » Blog Archive » Framework-free web programming Related Posts:Extreme Enthusiasm » Blog Archive » Framework-free web programming I presented […]
November 14th, 2010 at 16:45
Perchè usiamo i framework?
* Spesso nel nostro lavoro il focus è risolvere un problema dell’utente, non risolvere un problema tecnologico. I framework risolvono problemi tecnologici
* Risolvere in maniera ottimale un problema tecnologico è spesso un progetto a se stante (tipo il mapping Object-Relational) e necessita di competenze diverse rispetto a quelle necessarie per risolvere un problema dell’utente
* “The best code is no code at all”: i framework permettono di limitare la quantità di codice da manutenere.
* Spesso i framework implementano una filosofia: utilizzare un framework puo quindi aiutare la consistenza in progetti dove lavorano molte mani
Nel codice riportato nei tuoi esempi a mio avviso quello che stai facendo è semplicemente creare un framework ad-hoc. Se non crei un framework l’unica alternativa è il copy&paste.
Quindi in definitiva il tuo consiglio mi pare sia quello di non usare framework fatti da altri ma di farsi il proprio.
Mi dispiace ma non condivido affatto
November 14th, 2010 at 23:35
Ciao Gian Marco,
non mi aspetto che questo punto di vista diventi popolare :-) Anzi va proprio contro il pensare comune, ma non sono convinto che il modo di pensare comune sia il più efficace.
Per rispondere ai tuoi punti: non ti sto incitando a scrivere un tuo framework. Io penso che dovremmo scrivere codice per risolvere il problema del cliente e scrivere il codice più semplice per risolverlo. Iniziare lo sviluppo con la solita fase di selezione dei framework non è un passo in quella direzione. Proprio l’esempio che citi, del framework che fa mapping object-relational, indica che parti dal preconcetto di avere bisogno di un framework per fare mapping object-relational. Se invece tu partissi a progettare la tua applicazione in maniera incrementale, dal design più semplice, potresti scoprire che non hai bisogno di questo mapping; oppure che puoi ottenere il mapping in maniera più semplice ed efficace senza il framework.
Proprio l’esempio del mio cliente che descrivo nel mio post precedente è di questo tipo: si parte con un preconcetto “abbiamo bisogno di un MVC” e si cerca di martellare tutto per farlo rientrare in un MVC, quando in realtà poi il codice ti dice che ha bisogno di altro.
Il codice scritto con i framework non è più semplice di quello scritto senza framework. Può sembrarti di avere scritto meno codice, ma questo codice in realtà è fortemente accoppiato al codice dei framework. Per cui ti ritrovi con codice che apparentemente è più corto, ma non è più semplice da manutenere.
In pratica nella mia esperienza ho visto che i problemi tecnologici che si incontrano in una normale applicazione di tipo gestionale si risolvono bene in maniera incrementale, senza bisogno di framework. Le parti tecnologiche più complesse, come ad esempio la crittografia, si risolvono bene usando *librerie* (e non framework.) Scrivere queste parti “tecnologiche” che si interfacciano a strumenti base esistenti come il database, le API di crittografia o il web server non costa molto. Il grosso del lavoro lo ha fatto chi ha scritto il web server, il database, o la libreria di crittografia.
Non sono d’accordo che se non ti fai un tuo framework sei costretto al copy-and-paste. Il “framework personale” è un mostro famigerato perché viene di solito costruito con l’obiettivo sbagliato, cioè con l’obiettivo di fare un framework, con il risultato di infliggere un design che ha funzionato bene una volta ma potrebbe non essere appropriato la seconda. La ragione giusta per costruirsi un framework è quella di evitare il copy-and-paste, come dici tu, ma questa esigenza non nasce subito. Prima di arrivare a costruire il tuo framework devi avere cristallizzato la tua conoscenza e la tua comprensione di come si risolve una classe di problemi. E a questo non ci arrivi la prima volta; magari (cito Francesco Cirillo) ci arrivi la settima volta. Fino ad allora non ti conviene copiare e incollare la soluzione precedente; ti conviene piuttosto svilupparne una nuova per imparare a fare le cose in maniera un po’ diversa.
Lo so che ti sembrerà uno spreco… ma non lo è. Lo spreco è adattarsi ad usare un framework esistente (e rinunciare ad imparare a risolvere i problemi da solo) oppure cementare in un framework raffazzonato la prima soluzione che hai trovato.
November 15th, 2010 at 10:53
Grazie per aver dedicato tempo ad una risposta così articolata.
“…parti dal preconcetto di avere bisogno di un framework per fare mapping object-relational.”
Se come storage usi un RDBMS e vuoi programmare ad oggetti, puoi essere certo che dovrai risolvere problemi di “Impedance Mismatch”. Sono problemi noti da anni come gli approcci per risolverli. A questo punto si puo decidere di risolverseli a mano oppure di utilizzare un framework. La scelta dipende dagli skill del team e dal grado di complessità dell’object model e del db. Promuovere l’idea che un framework non sia necessario è azzardato quanto promuovere l’idea che sia necessario.
“abbiamo bisogno di un MVC”
Concordo che sia una assunzione sbagliata. Il processo magari potrebbe essere “dobbiamo garantire una certa qualità” => “il PATTERN MVC è un buon approccio”. La scelta della implementazione di MVC da usare è quindi una mera scelta di quale implementazione ci torna piu comoda e va fatta in base agli skill del team e alle peculiarità della applicazione. Promuovere l’idea che un framework non sia necessario è azzardato quanto promuovere l’idea che sia necessario.
“i problemi tecnologici che si incontrano in una normale applicazione di tipo gestionale si risolvono bene in maniera incrementale, senza bisogno di framework”.
Se hai a disposizione un team MOLTO bravo, quello che succede è che, all’aumentare della complessità del progetto, in maniera incremtale emerga un framework. Ruby on Rails insegna. Se invece il team è SOLO normale, probabilmente all’aumentare della complessità ti troverai con un mix tra codice applicativo e codice di framework. Dipende dalla qualità del team.
“Il codice scritto con i framework non è più semplice di quello scritto senza framework”
Per uno che conosce il DSL di Spring, è molto piu facile capire lo scope di un servizio di quanto non lo sia cercando tutti i “new” sparsi nel codice. Dipende dagli skill del team.
Le scelte tecnologice vengono operate in genere all’inizio di un progetto, fase in cui si hanno a disposizione ben pochi elementi per “indovinare”. Proprio per questo, promuovere l’idea che un framework non sia necessario è azzardato quanto promuovere l’idea che sia necessario. La cosa migliore in questa incertezza è scegliere la strada in cui il team si sente piu sicuro. E potrebbe essere quella di adottare un Framework oppure no, il punto non è quello.