Arrel del darrer post s'ha establert un nou fil relacionat amb la conveniència o no de fer servir un ORM en les nostres aplicacions quan l'sql directe pot ser més eficient. En Jan Carreres, el "responsable" d'aquest article fa una sèrie d'apreciacions que crec que donen per un nou post, més que res per poder mantenir la discusió en baix el seu propi concepte.

Així doncs acomodeu-vos al seient, que començam ...

Però què dimonis és un ORM

ORM són les sigles de Object Relational Mapping, és a dir, s'anomena ORM a aquella llibreria o procés que fa la conversió d'estructures de dades relacionals cap a estructures de dades orientades a objectes. És a dir, passam de fer feina amb taules i files a fer feina amb classes i instàncies d'aquestes classes. Passam de fer feina de camps a fer feina amb propietats dels objectes.

No hi ha una única aproximació als ORM. Christian Bauer i Gavin King al llibre Hibernate in Action, anomenen quatre característiques comuns a tot ORM:

• Una API per executar operacions CRUD (Create, Retrieve, Update, Delete) en els objectes.
• Un llenguatge o una API per especificar les consultes que fan referència a les classes i a les propietats de les classes.
• Utilitats per especificar les metadades del mapeig entre el model relacional i el model d'objectes.
• Una tècnica dins l'ORM per crear transaccions, fer assosicacions lazy i altres tipus d'optimitzacions.

A partir d'aqui la implementació de cada ORM potser completament diferent. Els autors, citant a Mark Fussel proposen la classificació dels ORMs en quatre tipus.

1. Purament Relacionals. L'ORM es construeix al voltant de la base de dades i es específic per a la nostra aplicació. Té l'avantatge que es pot optimitzar molt, però és difícilment portable entre bases de dades i presenta dificultats de manteniment. És típic d'aplicacions que tenen molta lògica dins la BD en forma de procediments amagatzemats.

2. Mapeig fi. Les entitats són representades com a classes i es mapegen manualment cap a les taules del model relacional. Un exemple d'aquest cas serien les aplicacions Java que fan ús del SQL/JDBC o bé en el cas de Python les que fan servir directament la DB-API de Python.

3. Mapeig mig. L'aplicació es dissenya al voltant del model d'objetes. És a dir, la base de dades és ara un suport per a la persistència dels objectes quan abans era gairebé la peça fonamental de l'aplicació. Aquest tipus d'ORM són especialment interessants quan l'aplicació té un tamany mitjà, amb transaccions complexes i sobretot quan la portabilitat entre bases de dades és un requeriment de l'aplicació.

4. Mapeig complet. S'hi arriba quan l'ORM suporta les característiques més importants i pròpies del model orientat a objectes: composició, herència, polimorfisme, ... i les implementa de manera transparent cap a la base de dades.

Si estam dins el món Java podríem dir que Hibernate està gairebé en el 4 d'aquesta classificació, Ibatis entre el 2 i el 3. En el cas de Python l'ORM de Django estaria començant a entrar en el 4 i SQLAlchemy estaria fregant el nivell d'Hibernate.

Per què fer servir un ORM

Per començar dir que un ORM no és una excusa per no saber SQL. Quan un fa feina amb aplicacions de bases de dades relacionals s'ha de conèixer al manco l'SQL estàndard, tenir molt clars els conceptes de taula, registre, selects, unions, claus primàries, etc. Es dóna per suposat que el tema de la normalització ja ho tenim ben clar.

El que fa un ORM és facilitar-nos la vida. Quan la nostra aplicació ja no es trivial, sinó que fa un ús intensiu de consultes, manipulacions de resultats, insercions, ens trobarem repetint una i una altra vegada el procés de conversió dels nostres objectes cap a sentències SQL. L'ORM fa tota aquesta feina per nosaltres, així que una de les raons més importants per a fer servir un ORM enlloc de sentències SQL a pèl per la nostra aplicació és la productivitat i evitar el DRY al llarg de la nostra aplicació.

Fer servir un ORM implica escriure menys codi nosaltres mateixos i sovint que el codi que hem escrit sigui més bo de llegir. Això es tradueix en una millor mantenibilitat de l'aplicació. Jan diu que si un es dedica a fer apliccions de BD ha de conèixer l'SQL i és veritat, però no té per què tenir a la ment tots els camps que hi ha a la taula. Imaginem-nos un entorn amb molts programadors fent feina a la mateixa aplicació. Aplicació amb moltes taules i amb taules amb molts de registres. Picant SQL a pel és tenim molts números de deixar-nos un camp a l'hora de fer una consulta. L'ORM manté la llista de camps per nosaltres, quan accedim a un objecte el ja se n'encarrega de fer les selects oportunes a la base de dades i obtenir-ne tots els camps.

Encara que hi ha casos en que escriure el codi SQL directament pot significar un guany considerable en el rendiment d'una consulta concreta, el més habitual és que l'ORM que facen servir ja tengui considerat dins la seva estructura les optimitzacions més habituals, de manera que l'sql que es genera pot ser fins i tot més eficient que el que generaríem a mà. Pensar que nosaltres sempre generarem millors sentències SQL és si més no agoserat, i per mi representa una optimització prematura. L'avantatge de productivitat i mantenibilitat que ens dóna l'ORM és el que s'ha de considerar primer. Després sempre hi som a temps d'optimitzar, però els nostres esforços s'han de concentrar en aquelles consultes o accions que torben més temps o que s'executen més sovint. És a dir, l'ORM i l'augment de productivitat que implica ens permet guanyar temps i poder optimitzar allà on interessar realment.

Molt relacionat amb tot això ens trobam la navegabilitat. La navegabilitat que ens permet el model orientat a objectes és d'aquelles coses que xoquen més amb el que ens proporciona el model relacional. Els ORM permeten navegar entre les associacions d'objetes de manera transparent, generant les sentències necessàries i sovint permetent-nos optimitzar aquesta navegabilitat, els select_related de Django n'és un exemple, o les cachés d'Hibernate. Pensem amb el senzill que és posar un objecte dins una plantilla i anar accedint a les seves propietat, anar fins a la propietat que representa una clau forana de la base de dades, fer-ne referència i obtenir-ne les propietats de l'objecte associat. Ara pensem en la quantiatat de codi SQL que ens hem estalviat.

I finalment l'altra gran motiu per fer servir un ORM és el d'independitzar-nos de la base de dades. Podria parèixer que quan un coneix SQL ja pot fer anar qualsevol base de dades, però realment això no és així, cada BD té petites diferències en la implementació de l'SQL que fan que sovint el codi SQL no sigui directament portable entre bases de dades. Un ORM crea una capa d'abstracció entre la nostra aplicació i la base de dades, generant i utilitzant les sentències SQL més adients a cada una.

L'argument que "un tria una BD i l'utilitzes sempre" per la meva experiència passa poc. Una empresa gran pot triar Oracle, però segurament per motius de cost algunes aplicacions les voldrà amb un altra BD. Si comercialitzam una aplicació limintar-nos a una base de dades concreta limita les possibilitats de comercialització. Fent servir un ORM podem desplegar la nostra aplicació contra diferents clients i fins i tot contra diferents versions d'una base de dades.

Resistir la temptació

Quan un comença a programar aplicacions de gestió és difícil resistir la temptació d'optimitzar-ho tot, d'escriure sql a pel optimitzant-ho per la nostra base de dades, és cert, però resistiu!

Si feim sql a pel a poc que l'aplicació creix el procés serà el seguent:

1. Ens adonarem que tenim sql repartits per tot. Així que farem una refactorització i posarem tot l'sql dins un sols arxiu que contindrà totes les funcions.

2. Després ens adonarem que aquest arxiu té molt de codi repetit, feim sempre la conversió de taules a objectes i ho refactoritzarem per a no repetir codi.

3. Després ens adonarem que feim sovint les mateixes consultes i que també es pot refactoritzar.

4. Seguirem i seguirem refactoritzant....

Al final acabarem amb un ORM del tipus 2 que ens haurà duit una feinada en refactoritzacions i que no té encara els avantatges d'un ORM del tipus 3 ó 4.

Costa resistir la temptació, fa peresa estudiar una llibreria d'ORM, però pensem que probablement el camí que seguirem serà aquest i s'ho paga l'esforç inicial.

Fa uns dies vàrem finalitzar la primera part del curs d'OpenERP. Aquesta part estava dedicada a la programació d'aplicacions i després, de fet la propera setmana, seguirà una part més dedicada al món de l'empresa i la gestió.

El curs és una iniciativa de l'Ibit d'aquestes que et tornen a reconciliar amb l'administració. Quan l'administració aposta per programes com OpenERP i la formació de programadors locals en aquestes tecnologies està apostant tant per l'empresa local de programació com per les PIMEs, que podran gaudir d'una programari avançat amb el sol cost de la seva implantació. Un ERP com OpenERP uneix omptabilitat, facturació, gestió de clients, etc amb la capacitat de programació i personalització. El que sigui slliure implica que el que pagaríem amb llicències se'n pot anar a millorar el programa i a adaptar-lo a les nostres necessitats.

Coneixia OpenERP des de fa temps, però els darrers dos anys el seu creixement en funcionalitat i mòduls ha estat espectacular. El programa està escrit en Python, una de les coses que el fan més atractiu, ja que fa que la corba d'aprenentatge sigui molt suau i a més fa que els requeriments de màquina que se necessitin per fer anar el programa siguin minims. La base de dades que utilitza OpenERP és Postgresql, una altra magnífica elecció al meu entendre ja que personalment he pogut comprovar la robustesa d'aquesta base de dades en entorns de negoci i la seva gran versatilitat.

Recordem que estam parlant d'un ERP, un sistema que integra tot el que el negoci pugui necessitar gairebé de sèrie i que permet personalitzar-ho de manera que sigui el programa el que s'adapti al negoci. Així podem verticalitzar l'aplicació creant nous mòduls i aprofitant els existents, o bé podem utilitzar-ho com a bastiment per a crear les nostres pròpies aplicacions. El sistema es prou modular per permetre ser utilitzat com un programa de comptabilitat i gestió potent, com un bastiment de programació per aplicacions de gestió o la combinació d'ambdues caracterísiques. Sols per la comptabilitat i facturació la instal·lació d'OpenERP ja es justifica sola, per una part tindrem un dels millor programes comptables que hi ha i a més a més tendrem control de les nostres dades. Supòs que més d'una ara recordarà algun amic o conegut que s'ha trobat amb problemes amb alguna de les distintes versions de contapluses pagades i amb llicència (canvi disc dur o d'ordinador són bastant habituals), i quan ha anat a consultar què passava li han dit que ha de passar per caixa i contractar un manteniment que li costa més que el que va pagar de llicència. Mentre no té accés al programa, no pot fer factures ni comptabilitzar, passa a ser hostatge de la seva compra. Amb OpenERP això no passa, no depens d'una única empresa que et pugui donar el mantenimient, si ho instal·les a casa les dades són teves i no hi ha limitacions artificials. Si el nostre negoci creix i necessitam més gent a administració o canviam de disc dur l'OpenERP seguirà funcionant.

Que OpenERP estigui escrit en Python i que hagi tingut aquest creixement per mi no és casualitat. Ho he vist en altres projectes Python, que comencen molt tímidament però que aviat gràcies al nivell d'entrada tan suau que té el llenguatge i a la seva legibilitat, va incorporant programadors i característiques fins a convertir-se en un referent dins el sector. Ho hem vist recentment a projectes com Django o Satchmo, i també a llibreries com pyQt, wxPython, sistemes de còpia de seguretat, ... OpenERP és potser un dels millors exemples del que es pot fer amb Python.

La part de programció pura, amb OpenObject i no lligada a la comptabilitat o facturació també es mereix la màxima atenció. És molt bo de fer crear formularis i aplicacions noves. La gent que sovint diu que necessita un Access per Linux li hauria de fer una ullada a com funciona el programa. Pel mateix preu tens el client gtk i el client web, i la feina que duu m'atreviria a dir que és menor que una aplicació Acces ben acabada.

Personalment ho tenc força clar, OpenObject passarà a formar part del meu caixò d'eines informàtique i l'opció preferent quan es tracti de crear una aplicació de gestió d'escriptori o web. A més és molt bo de fer connectar-ho amb Django o altres aplicacions gràcies a la seva filosofia oberta.

Esper que la propera setmana el curs sigui tan interessant como ho va ser el de programació. Crec que ens divertirem molt amb OpenERP i OpenObject.