Web Frameworks

Alberto Valverde alberto en toscat.net
Jue Ago 7 22:01:59 CEST 2008


Hernan Olivera wrote:
> Hola, gente.
>
> El ultimo mensaje de Alberto me reflotó uno anterior de Chema, y cito:
>
> Chema:
>   
>> Mis modelajes de datos son bastante complejos, con
>> modelos físicos y lógicos, claves subrogadas y tablas dimensionales
>> que no se pueden modelar con un ORM.
>>     

¿Con ninguno o con un active record? Me interesaría ver un ejemplo por
curiosidad...
>
> Alberto:
>   
>>  Gran parte de la culpa se la echo a su ORM pues *por
>> diseño* (googlea Active Record vs. Data Mapper) no es posible mapear
>> ciertos esquemas de base de datos.
>>     
>
> Las preguntas que me surgen son:
> ¿que cosas NO se pueden hacer con un orm y si en relacional?
>   
La diferencia a la que me refiero no es entre relacional y orm sino
entre los dos tipos de orm principales. Supongo que por relacional te
refieres a SQL "a pelo", no? La diferencia entre usar un orm para
abstraer la base de datos (para "aislar" el código de cambios en la
estructura de la misma, por ejemplo) es enorme. Con sql puedes hacer
todo lo que pueda hacer tu base de datos, con un orm casi siempre no. La
ventaja del ORM es que en los casos en los que lo puedes usar te
simplifica *mucho* el codigo que tienes que escribir e incluso influye
en la arquitectura de la aplicación, normalmente más orientada a objetos
con un ORM (a menos que reimplementes una variaciñon casera de un orm,
claro). ¿Cuál es mejor? Depende. Si la aplicación consiste en una página
con un formulario que hace consultas a una vista compleja de una base de
datos en la que no podemos influir sobre su diseño entonces no hace
falta un ORM. En cuanto el modelo de de dominio empiece a complicarse, a
dispararse las relaciones entre tablas... y queremos hacer un diseño
orientado a objetos entonces un ORM empieza tener ventaja a la hora de
simplificar el diseño de la aplicación

Pero no es a ésta diferencia a la que me refería sino a la diferencia
entre el diseño de distintos ORM. Hay dos tipos principales, los  que
implementan alguna variación del patrón active record [1] (django,
sqlobject, RoR...) o los que implementan alguna variación del data
mapper [2] (sqlalchemy, hibernate (java),...). Mejor leete los enlaces,
pero brevemente:

La diferencia principal es que AR mapea cada tabla directamente a una
clase y la lógica de persistencia esta implementada en una superclase
del modeo mientras que en el DM hay una capa llamada "mapper", que se
encarga de la persistencia, entre la base de datos y el modelo de
dominio. En el DM en vez de mapear tablas mapeas relaciones, es decir,
una clase no tiene porqué corresponderse a una sola tabla sino que puede
ser el resultado de cualquier SELECT por complejo que sea.

Pongamos que es una vista implementada en la aplicación, lo cual tiene
sus ventajas: por ejemplo, tienes más flexibilidad a la hora de diseñar
el modelo mientras mantienes una estructura eficiente en la base de
datos, cierta independencia entre bases de datos (al no tener que usar
vistas)... Un ejemplo (con SA, que es el que conozo) de como puede
ahorrar bastante codigo en forma de codigo en tú aplicación está aquí
[3], implementar algo tan elegante en con un orm AR sencillamente no se
puede, eso es menos código en tu aplicación que escribir pero sobre todo
que mantener.

El AR es conceptualmente más sencillo y sirve bien para la mayoría de
casos hasta mediana complejidad, el DM es más complejo pero, hasta dónde
he llegado, permite mapear cualquier esquema de base de datos. El resto
son diferencias entre las implementaciones pero lo que te he descrito es
la diferencia esencial, según la entiendo.

(....)
> Por ahora para mí además del marketing favorable, lo único que puedo
> decir es que
> viendo la documentacion disponible me parece el mas sencillo de abordar.
>   
Su documentación es la mejor, sin duda (aunque Mark está esforzándose y
promete que eso cambiará pronto ;)

La de las alternativas deja bastante que desear, sin duda, y por lo que
respecta a mi parte del jardín (TW) soy culpable como el que más. Si
quieres saber por qué, mi teoría es que se debe a que no ha habido un
esfuerzo coordinado y motivado que durase el tiempo  suficiente por
mejorar la documentación de TG/Pylons/ y varias librerías relacionadas
por parte de los autores lo cual no ha ayudado a que los usuarios
ayudasen ("¡con lo que me ha costado aprender ahora va a escribir
documentación quién yo te diga!"). Hay excepciones, la de SA que es
impresionante, para mi *gusto* mejor que la de django. Al final terminas
aprendiendo a base de trastear, charlar en IRC o preguntando en las
listas de correo. Personalmente, yo he aprendido python (después de lo
básico) a base de leer y estudiar el código de las librerías que usababa
y no estaban del todo documentadas. En retrospectiva me alegro mucho de
que haber sido así ya que, entre muchas otras cosas, creo que da cierta
independencia a la hora de evaluar software libre.

Sinceramente, creo que Django es la mejor opción que tienes ahora mismo
si eres nuevo en programación web con python por la documentación, la
consistencia y la comunidad que tiene en habla hispana.

Lo único que algún día (tal vez ahora, no lo sé) puede que los railes
que te proporciona no sen lo mejor para el proyecto que tengas entre
manos y puede que otra herramienta/framework/como-lo-quieras llamar te
sirva mejor, que te ayude a ahorrar código y tiempo, si puedes
prepararte mientras tanto a base de ver con calma que otras cosas hay
por ahí pues mejor, creo yo. Si sirve como anécdota, por la lista de TG
han pasado, algunos se han quedado, varios desarrolladores
experimentados a los que django se les ha quedado corto; mientras que lo
que he visto (no mucho, así que seguro que me equivoco) en caso
contrario han sido a principiantes quejándose por la documentación. Ni
se te ocurra tomar en cuenta esto como argumento de peso ;)

> Lo que mas estoy interesado en saber (insisto) es con qué limitaciones
> me puedo llegar a encontrar.
>   
Ya lo he dicho en éste hilo: El ORM principalmente, luego,
subjetivamente, el lenguaje de plantillas (no me gustan las camisas de
fuerza ;), luego ciertas decisiones de la infraestructura (aplicación
como singleton, no usar setuptools...)

Bueno, aquí dejo el hilo. No me apasiona el marketing y siempre me
siento haciéndolo si hablo de ésto por haber pasado por el liderazgo de
TG durante unos meses (hasta que era insostenible que un patán como yo
estuviese ahí ;) La vertiente que está tomando, según la empiezo a ver,
más "comercial" que técnica no me resulta del todo cómoda y no me salen
argumentos en ese terre. Para hablar de código, librerías etc. lo que
quieras, pero más tg vs. django vs. pylons vs. ... no, sorry.

Mi intención principalmente al entrar en éste hilo no es dicutir o
"vender" nada, sino comentar que Django no es lo único que hay, ni lo
mejor (quien esté convencido de que algo es mejor que otra cosa, en
terminos absolutos, me asusta más que hace reir), ni los demás son de
juguete, ni están muertos... en fin, de luchar un poquito contra el FUD,
seguramente no-intencionado, que he leido por aquí.

Todos son buenos, es python ;)

Alberto

P.S. Ya para despedirme del hilo, y ya que están de moda las citas, dejo
un comentario que me parece bastante acertado de Bob Ippolito en un blog
(dónde se suele estar mas suelto que en una entrevista). Si no os suena
es el que distrubuye el MacPython, ha escrito simplejson (que os debe
sonar a los que también usaís django pues lo teneis en vuestro tronco=),
MochiKit, MochiWeb, ha contrubuido a Python...

"""
The Pylons approach works quite well if you already know what you're
doing. There's a whole lot of brain damage in some of the choices Django
and TurboGears have made and neither were tolerable for me so rather
than building our own framework we could simply use Pylons and configure
it with the pieces we needed. We've built a lot of homegrown stuff on
top of it, but we'd have done that anyway because no framework ships
with solutions that worked for some of our needs.

The people I've hired with previous Django experience much prefer
working on our Pylons based architecture than hacking around Django's
cruft. For us, the conceptual integrity is perfectly intact in how we do
projects across our business and we don't need as big of a crutch as
what you're used to.

If the Pylons project magically changed into what you suggest it should
be, then we wouldn't use it. I don't want Mako or Django's templates.
Our home-grown auth/authz, caching, and model systems (more than one db
involved, though using SQLAlchemy for plumbing) serve our needs better
than anything out of a box could.
"""

[1] http://martinfowler.com/eaaCatalog/activeRecord.html
[2] http://martinfowler.com/eaaCatalog/dataMapper.html
[3] http://spyced.blogspot.com/2007/01/why-sqlalchemy-impresses-me.html

_______________________________________________
Lista de correo Python-es 
http://listas.aditel.org/listinfo/python-es
FAQ: http://listas.aditel.org/faqpyes





Más información sobre la lista de distribución Python-es