Ho ricevuto questo interessante articolo di Paolo, che pubblico con piacere:
Easy Driver è un progetto Open Source e libero per accedere ai database, costituito da una libreria Java e da un generatore di codice.
L’esperienza fatta scrivendo le query direttamente con JDBC ha insegnato, che è facile avere molto codice ridondante. Questo è una nota fonte di difficoltà di manutenzione, oltre che un costo, sia per quanto riguarda la prima stesura del codice, che per la successiva manutenzione.
Il paradigma della programmazione ad oggetti poi si scontra con il modello relazionale dei database usati più spesso.
Un altro problema che affligge il mondo dei database è la loro frammentazione. SQL si è sviluppato in diversi dialetti, nonostante i tentativi di standardizzazione.
La mappatura tra il mondo relazionale e quello ad oggetti, unito al bisogno di ridurre i tempi di sviluppo e porting, quindi di manutenzione, ha portato allo sviluppo di alcuni ORM (Object Relational Mapper), tra i più famosi si possono citare Hibernate, iBatis e TopLink.
Ultimamente la specifica JPA con la nascita di EJB QL ha cercato di unificare sotto un’unica interfaccia le diversità dei vari ORM.
Però lavorando con questi strumenti ci si accorge di alcuni limiti, derivati proprio dai problemi che volevano risolvere.
Prima di tutto, occorre sottolineare, che di solito chi ci propone l’indipendenza da uno strumento, lo fa per legarci a sé stesso, non certamente per spirito caritatevole. Venendo nel concreto al nostro caso, supponiamo di usare Hibernate, che è un ottimo strumento e che molto spesso è la soluzione migliore. E’ stato portato su .Net e Java, quindi un ottima scelta, finché non nasce la necessità di lavorare su ambienti a risorse limitate, dove una virtual machine o un common language runtime rappresentano un overhead notevole.
Per un’applicazione è legittimo scegliere PHP, Phyton puro o magari il sempre verde C++ ! Per questi ambienti gli ORM più famosi non ci sono, invece ci sono altre soluzioni, generalmente incompatibili tra loro.
Anche se rimaniamo negli ambienti cosiddetti enterprise, più si cerca l’indipendenza dagli strumenti, anche adottando JPA, più aumentano gli impacci nella soluzione dei problemi di tutti i giorni, avendo a disposizione pochissime funzionalità, rispetto a quando si usa direttamente il dialetto del database in questione.
Con questo non si vuole criticare il lavoro fatto da questi strumenti, veramente ottimi, tuttavia la vita dello sviluppatore reale ogni tanto impone scelte diverse dalle proposte fatte dai grandi dell’informatica.
A volte la pressione per una consegna è tale che, diciamocelo francamente, è impossibile progettare bene. I puristi scrivono libri, difficilmente vivono di progetti.
Pur avendo il massimo rispetto e ammirazione per questi strumenti, che io stesso uso con soddisfazione, sono convinto che ci sia spazio per qualcosa di diverso, più umile negli obbiettivi e guidato dal basso, dalla gente reale che lo usa.
Sono partito da me, dalle mie esperienze, elencando cosa mi poteva servire, pensando che anche altri potessero condividere le mie idee.
E’ così che ho buttato giù i primi punti su come poteva essere il mio strumento. Le prime prove, le prime idee grezze non mi hanno portato a niente di migliore di ciò che non fosse già in giro, quindi sono andato avanti.
L’esperienza di consulente mi ha mostrato che altre persone in altre aziende tentavano strade simili alla mia, alcuni proteggevano gelosamente le proprie soluzioni, tenendole come framework proprietari. Questo però apriva dei problemi interni. Infatti i neo assunti mal volentieri vogliono studiare uno strumento, la cui conoscenza non si può rivendere fuori. In questa società che ha istituzionalizzato il precariato, bisogna cercare anche conoscenza rivendibile dopo, oltre che lo stipendio.
Inoltre la naturale scarsa propensione dei tecnici alla comunicazione, abituati come siamo a dedurre le cose, spesso è causa di attriti tra chi deve imparare ad usare uno strumento e chi lo ha scritto.
Tutti ci sentiamo orgogliosi di ciò che facciamo e le critiche fanno male. Questo è un grosso scoglio nei rapporti tra gli hacker.
Senza dubbio tra i vari framework proprietari sviluppati ci sono delle ottime idee, che non saranno mai valorizzate come meritano, tuttavia la scelta di sviluppare una soluzione interna non è sempre furba per l’azienda che la paga, in forma di stipendi a dipendenti che lavorano a tale soluzione, piuttosto che produrre qualcosa di direttamente vendibile. Non discuto sul fatto che si tratti di un costo spalmabile sui vari progetti, tuttavia sappiamo tutti come il software abbia un costo difficilmente stimabile e che ci si renda conto soltanto alla fine di quanto è costato svilupparsi in casa qualcosa…
Da qui l’idea di rendere open source e libero il mio lavoro. Un generatore che crei delle classi le quali rappresentano la struttura delle tabelle e che crei un object model molto banale, senza pretese, tanto i tool moderni facilitano il refactoring. Si sfruttino le proprietà del database scelto, privilegiando nella scelta le soluzioni Open Source e il più possibile aderenti agli standard, in questo PostgreSQL mi sembra una scelta furba. Una libreria che richieda di scrivere stringhe il meno possibile, meglio se mai, in modo che il compilatore ci aiuti a comporre le query.
Trovate la prima beta usabile su http://code.google.com/p/easydriver/ e le novità sul mio (ancora scarno) sito: http://www.byteliberi.org/
Cerco collaboratori, sponsor, ma soprattutto, cerco gente pragmatica e con un’enorme passione per il nostro lavoro.
Paolo Proni è un consulente informatico indipendente, purtroppo per lui usa i computer da quando era giovane, cioé da troppi anni. Fa consulenza principalmente su Java e secondariamente fa qualcosa in C++. Si occupa prevalentemente di web application su piattaforma Jboss, con JSF e EJB. Per lui Linux è la miglior invenzione dopo la ruota, ma non gli dispiace Mac OS X…
Popular Posts:
- None Found
