Capa de negoci a Django

Escrit per Aaloy a 28 de May , 2008 a les 11:55 p.m.

Del post anterior em quedava el tema de tractar el tema de la capa de negoci en els llenguatges dinàmics. Com en el cas anterior faré servir Django com a exemple i deix al lector la feina d'extrapolar cap el seu llenguatge dinàmic+bastiment preferit.

En Domingo diu que els llenguatges dinàmics mostren molta de la seva potència a la capa de presentació, que és allà on en treuen més profit. Això és veritat però es queda curt. És a dir, quan un usuari demana un canvi, el més habitual és que aquest s'acabi reflexant en la capa de presentació,però això no vol dir que no se canvii la capa de negoci. El fet però és que anar des de la capa de persistència, passant per negoci i mostrar el resultat al navegador, té un cicle de temps més curt en el llenguatge dinàmic, interpretat, que en el compilat, ja que sol ser molt més curt fer els canvis (gearing factor i totes aquestes herbes) i necessitea un temps més curt de desplegament, però no ens enganem, és tot el procés que és curt, si no afecta a capa de presentació el que passarà és que el desenvolupament serà encara més ràpid.

Sovint amb les aplicacions del tipus crea el teu blog en 10 minuts en Django, Rail o qualsevol altra, es dóna una idea equivocada del que se pot fer, donant la imatge de que aquestes aplicacions van molt bé per fer webs que depenen d'un conjunt de taules senzilles i que tenen una lògica de negoci poc complexa.

Bé, supòs que podríem demanar-li a Ricardo, que és un exemple que tenim ben aprop,de com s'ho fa per calcular el karma de Meneame o per saber si una notícia ha de sortir en portada o quan ha de deixar de ser-hi. Tot això es lògica de negoci, està feta en un llenguatge interpretat, el PHP.

En el cas de Django no oblidem que el que tenim per davall és Python i que l'ORM que ens proporciona Django ho podem fer servir o no, substituir-ho per un altre, fer les cridades directament a BD o senzillament, utilitzar-ho com a part del nostre model de negoci i posar-i les regles que ens convenguin.

Segons la nostra aplicació podem anar afegint custom managers que ens permetran definir regles damunt les dades que volem obtenir, mètodes de classe per definir les funcionalitats que vagin damunt tots els elements de la taula, i missatges que ens ajudin a manipular la informació i les seves relacions.

Això ho podem fer directament des de la classe de l'ORM, el model, o bé, recordem que tenim Python a la nostra disposició, crear un nou paquet, crear una classes o un conjunt de classes i utilitzar el model per aplicar les regles de negoci que vulguem quan aquestes s'hagin de convertir en registres de la base de dades o la seva informació hagi de venir de la base de dades. Per cert, i abans que algún ho demani, sí hi ha transaccions!

Això vol dir que podem fer servir els llenguatges dinàmics per a modelar la nostra capa de negoci, doncs sí, ho podem fer. Això vol dir que la nostra aplicació ha d'estar escrita en un llenguatge dinàmic sempre? No, depèn de l'aplicació. Potser per una aplicació concreta amb un requeriments concrets tenir un contenidor EJB amb transaccions distribuïdes serà el que necessitam, el que vull dir és que no podem descartar fer l'aplicació en un llenguatge dinàmic sols perquè ens hem quedat amb la idea de que sols va bé perquè el seu ORM te crea molt fàcilment les taules i els CRUDs.

De fet la part d'administració de Django va molt bé com a eina administrativa, però no és una eina d'usuari final. Com a desenvolupador te va molt bé perquè pots fer cerques ràpidament, començar a omplir les dades del manteniments mestres i anar directament a les butzes de les dades, però no hem de confondre això ni amb l'aplicació final i amb que és tot el que se pot fer amb els llenguatges dinàmics.

I encara hi ha un punt que no hem tractat, el tema de la integració dels llenguatges dinàmics amb els llenguatges compilats (jpython, jruby, groovy, etc). Segons la nostra aplicació i els nostres usuaris, tenir un llenguatge interpretat, fins i tot creat per al domini de la nostra aplicació pot ser una opció molt interessant. Permeteu-me una batalleta: fa un grapat d'anys vaig desenvolupar el programa de gestió d'excursions de l'empresa on feia feina (Delphi + IBObjects + Firebird), una aplicació client servidor clàssica amb un grapat de procediments amagatzemats quan feia falta. La cosa és que hi havia excursions que tenien ofertes que el proveïdor donava i que s'havien de cotitzar, ofertes del tipus: "si es reserva una excursió per dos adults i un nin, el nin tendrà un 25% de descompte damunt la tarifa" o "el tercer adult es gratis i els nins no paguen" etc. Això ho podria haver desenvolupat amb un bon conjunt de camps de la base de dades i tenir previstes les condicions, però la solució hagués estat visualment atractiva però mala de programar i molt propensa a errors. Per contra vaig optar per a modelar-ho con si fos una fórmula de una fulla de càlcul, a la que els meus usuaris estaven acostumant on es podia jugar amb el preu per data, amb sumes, restes, if i tant per cents i parèntesi, un mini intèrpret pensat per a tractar amb fórmules matemàtiques. Les condicions així posades eren flexibles i amb unes possibilitats pràcticament il·limitades respecte al que haurien estat si ho hagués fet amb una "interfície amigable". En aquest cas, integrar un intèrpret a l'aplicació va ser la millor solució.

Com no me cansaré de repetir, no es tracta de dinàmics/interpretats respecte d'estàtics/compilats. Es tracta de perdre la por i els perjudicis i poder triar en cada cas aquella tecnologia que millor s'adapti al problema a resoldre de manera que aquest es pugui resoldre amb el menor cost actual i futur per al nostre client, en alguns casos aquest llenguatge serà C, C++, C#, Java o el que sigui, però en altres, en molts altres un llenguatge dinàmic serà la millor opció per als nostres clients.

Enllaços citats

• Meneame
• Ricardo

5 comentaris, 0 trackbacks (URL) , Tags: Python Django Gestió de projectes

> Bé, supòs que podríem demanar-li a Ricardo, que és un exemple que tenim ben aprop,de com s'ho fa per calcular el karma de Meneame o per saber si una notícia ha de sortir en portada o quan ha de deixar de ser-hi.

La major part és en PHP (hi ha coses en Perl i ara noves en Python), però tanmateix fer servir el PHP, Perl o Python. Tot serveixen. El que mai faria es fer servir un llenguatge compilat i sense suport de hashes i arrays dinàmics.

A això em referia. Menéame és un exemple d'una aplicació que està suportant una munió de visites diàries, amb càlculs molt complexes (la capa de negoci) i tot fet en llenguatges dinàmics.

Això serveix per desfer el mite que aquests llenguatges no van bé per les regles de negoci, de fet diria que ben al contrari, quan més complexes són les regles millor van.

De fet a Java hi ha paquets com Drools orientats a escriure les regles de negoci. Sovint l'aparició d'una utilitat específica ens dóna una idea de les mancances del llenguatges. Per PHP, Python o Perl no hi ha necessitat de fer tal cosa, ja que es guanyaria ben poc.

hola,

Ja fa estona que segueixo el teu blog, i me pareix força interessant.

Venc de l'escola "tradicional" J2EE + Oracle, encara que també vaig fer feina amb PHP, ja fa uns quants anys.

Per motius laborals en trobo analitzant les opcions de futur d'una empresa turística de B2C. Ho tenen tot muntat amb LAMP. I ens sorgeix el dubte de si això escalarà bé o no.

A curt plaç, analitzat el seu creixement, el sistema aguantarà força bé, però a llarg plaç hi ha veus que aposten per anar a un model on Oracle sigui el sgbd. Des d'un punt de vista transaccional (col·loquialment, gravar una reserva) això ens oferiria un control i unes garanties majors que amb l'actual esquema MySQL.
En cap cas la migració a Oracle significaria passar la lògica de negoci dins la bd, via plsql. Això mai :)
La meva idea és refactoritzar el codi PHP per extreure tota la lògica de negoci separant-la completament de la presentació.

En fi ha resultat més una reflexió que un comentari...

Un saludo.

Bones Xavi,
Encantat de que t'hagis decidit a deixar un comentari. Sempre és agradable saber coses de qui et llegeix.

Mira, te contaré una història: suposem que hi ha una gran empresa d'"allende los mares" que té un B2C molt, però que molt bèstia. Han acabat amb granges de mysql perquè l'Oracle no els escala bé, no en tecnologia potser, sinó en màquines i preu.

Conec gent d'altres països que té mil·lions de peticions al mes (estimat a partir de les peticions que ens arriben) i tenen PHP + Mysql a la capa de BD.

Alerta amb els temes de mysql/postgres (sí, sóc de postgres, què passa!) vs Oracle. Postgres escala fins al 2 TB segons els darrers experiments i l'escalabilitat no implica una despesa tal que a la pràctica no puguis escalar.

Què passa si demà Oracle te demana les llicències per màquina i tu necessites posar màquines noves i les que et venen sols venen amb processador de 16 nuclis? Mysql no necessita pràcticament màquina per treballar, pots anar creixent de manera orgànica, amb molt poc cost de maquinari. Posar Oracle per temes "mysql poster no escali" no és una resposta tècnica, serà potser una resposta política. El que s'ha de fer és demostrar-ho pel negoci actual i futur i fer-ne el pla de negoci.

En un tema com el B2C on els beneficis són tan minsos i la competència és tan forta, l'escalabilitat en preu no és una cosa que es pugui deixar de banda. Potser arribareu a un punt on el cost en llicències és tan gran que sortirà millor regalar els viatges, o anar cap a la solució de posar al davant mysql, que al cap i a la fi és el que teniu ara.

Gràcies per la resposta.

Només dir-te que també avaluam la possibilitat, com alternativa a Oracle, a una arquitectura 'shard'.
Encara que els costos d'implementació podrien complicar-ho.
Sigui com sigui, li queda molt de recorregut al sistema actual.

Ens seguim llegint...