Re: Evaluando Web2py

[Martín Mulone]

Creo que en esto podría opinar mariano, que el estuvo haciendo una aplicación con bastantes tablas. Si no es fácil el dal para esto, sobretodo en las relaciones. También se puede no usar DAL haciendo las queries vos mismo, pero claro perdés todas las ventajas del uso del DAL.

El 12 de julio de 2012 08:33, Sebastian <fxga...@gmail.com> escribió:

Gente:

Estoy evaluando web2py para aplicaciones de negocios.

Mi background es de lenguajes orientados a objectos.

La verdad que web2py me parece fantástico pero me encontré con algo que para mi puede ser un inconveniente:

La capa DAL no me permite trabajar con instancias de clases, solo datos, por lo tanto tengo que poner parte del comportamiento que tradicionalmente pondría en las mismas clases que mapeaba a la BD en otro lado. Puede ser en una capa de servicios.

El problema es que estoy evaluando el framework para un sistema que parte de base en unas 400 tablas, bastante relacionadas.

Este es un problema ya planteado en la comunidad pero no se si hay algún tipo de solución a esto.

Desde ya les agradezco sus comentarios.

Sebastian

--

 http://www.tecnodoc.com.ar

[Mariano Reingart]

El tema de objetos, lo podés llegar a implementar con una especie de
interfaz para simular ORM de django/sqlalchemy:

http://code.google.com/p/django-and-sqlalchemy-on-web2py/

Igualmente yo no recomendaría un ORM, más si son tantas tablas, con
web2py podés crear virtualfields y embeber cierto comportamiento allí:

http://www.web2py.com/books/default/chapter/29/6?search=virtual+field#Virtual-fields

Los temas que menciona Martin sobre definir las interrelaciones,
deberían estar resueltos, pero posiblemente debas dividir en módulos
para que no impacte en el rendimiento.

Cualquier duda avisanos,

Sds

Mariano Reingart
http://www.sistemasagiles.com.ar
http://reingart.blogspot.com


2012/7/12 Martín Mulone <mulone...@gmail.com>:

[Sebastian]

Mariano:

Gracias, vi lo de los virtual fields, esta bueno pero sirve solo para la parte más simple.

El tema es que como está acomodada mi cabeza en este momento no me cierra como haría para no terminar en una montaña de código en el mismo lugar.

¿Ustedes tienen experiencia en sistemas de ese volumen de tablas mas o menos?

Saludos

[Alvaro Lizama]

Si, web2py no se me hizo la opción para eso, preferí usar otro framework. Aplicaciones muy grandes se me hacen difíciles de mantener en web2py, muy complicado cuando las cosas pueden ser mas simples.


--
Alvaro Lizama
http://alvarolizama.net

[Mariano Reingart]

Un ORM no es mas simple que la DAL, de hecho varios autores ven a los
ORM como un problema, por ej en este artículo sobre el "vietnam" de
las ciencias de la computación:

http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

Te podría dar muchos ejemplos de aplicaciones inmantenibles con otros frameworks

Dependiendo del caso hasta preferiría incluso poner parte de la lógica
en una base de datos, por ej. usando el lenguaje procedural PL/Python
de PostgreSQL.

Martín ha dado incluso una charla de como encapsular datos y
comportamiento en clases tradicionales de Python, que me parece la
mejor opción para trabajar con ambos paradigmas (relacional y
orientado a objetos), sin perder los beneficios que ofrece web2py:

http://www.slideshare.net/martinpm/web2py-pensando-en-grande-9448110

Sobre gustos no hay nada escrito, en mi caso preferiría que no hacer
aseveraciones genéricas (del tipo "para aplicaciones grandes...") que
no sirven de mucho y tienden más a confundir que a ayudar.

Sds

Mariano Reingart
http://www.sistemasagiles.com.ar
http://reingart.blogspot.com

2012/7/12 Alvaro Lizama <nek...@gmail.com>:

[Alan Etkin]

> Martín ha dado incluso una charla de como encapsular datos y
> comportamiento en clases tradicionales de Python, que me parece la
> mejor opción para trabajar con ambos paradigmas (relacional y
> orientado a objetos), sin perder los beneficios que ofrece web2py:

El proyecto movu.ca de Bruno Rocha también implementa un esquema de
clases de datos combinado con la interfaz estándar de DAL:

https://github.com/rochacbruno/Movuca

[Jose]

Hola Sebastián

Viste esto [1]?

No usé y no sé en que estado se encuentra.

Saludos

[1] http://code.google.com/p/web2pyorm/

[Francisco Antonio Tapias Bravo]

El 12/07/12 13:33, Sebastian escribió:

> La capa DAL no me permite trabajar con instancias de clases, solo
> datos, por lo tanto tengo que poner parte del comportamiento que
> tradicionalmente pondría en las mismas clases que mapeaba a la BD en
> otro lado.

Yo tenía también este problema. Primero comencé con DAL puro pero me
penalizaba pensar que estaba supeditado a trabajar con datos, luego
quise trabajar con objetos al más clásico estilo usando SQL
directamente, pero perdí toda la agilidad que me da el API de web2py,
sobre todo SQLForm, Forms, smartgrid. Pero mira por donde me topé con
esta presentación de Martín Mulone:

http://www.slideshare.net/martinpm/web2py-pensando-en-grande-9448110

Léetelo todo, pero la diapositiva/página 15 de la presentación te da la
clave para trabajar con objetos, sin recargar el sistema, optimizando
web2py y con DAL puro. Creo que esto es la solución que buscas. Con las
ideas que te da Martín Mulone (que me acabo de dar cuenta que es el
mismo que ha compartido las apps con bootstrap y que hoy mismo he
agradecido su trabajo) te puedo asegurar que vas a tener una gran
aplicación en web2py. Sólo te puedo decir que me alegro mucho de haber
dejado Ruby on Rails y ActiveRecord a un lado para pasarme a web2py.

Mulone Martin, eres un crack!

[samuel bonilla]

esta es una desventaja que tiene web2py frente a django...... ya que django impleta los modelos(tablas) de la base de datos con clases y instansias de clases...

pero creo que en la version de web2py 2.0 mejorara en esa parte, hay un proyecto llamado movu.ca que creo que sera una buene guia para loque quieres hacer

saludos

[FreeMEM]

movuca utiliza precisamente la forma de trabajar que se explica en la presentación de la que hablado antes. Lo que no me gusta de django es que según que tipo de consultas, se vuelven muy pesadas y al final tienes que recurrir a escribir SQL. Es el mismo problema que tiene ActiveRecord de Ruby on Rails, que a veces se complica todo sobrecargado de herencias de múltiples objetos y que tienes que usar el SQL con frecuencia para optimizar consultas pesadas, por lo que terminas atándote a un backend. DAL lo resuelve de forma magistral ya que prácticamente lo que hace es traducir su forma de escribir las consultas a SQL, pudiendos ahcer prácticamente cualquier tipo de consulta específica, mientras que con los ORMs hacer ciertos tipos de consultas pueden encadenar varias consultas internas, por ello lo de optimizar escribiendo SQL directamente el ORM. En cuanto a si mejora web2py 2.0 respecto a esto, se sigue usando DAL del mismo modo que la 1.x y espero que cambien de DAL a ORM, porque en ese momento, cambiaré de framework. Lo ideal es trabajar con modules para cargar sólo las tablas que te hagan falta en todo momento y trabajar con DAL para hacer las consultas que en calquier caso también son objetos. De este modo yo trabajo con aplicaciones que tienen más de 60 tablas y con cantidades enormes de datos (Teras).