proyecto combinado escritorio - web.

[Oswall Verny Arguedas C.]

--- El jue 10-dic-09, Chema Cortes <pych3m4 en gmail.com> escribió:

> De: Chema Cortes <pych3m4 en gmail.com>
> Asunto: Re: [Python-es] proyecto combinado escritorio - web.
> A: "Lista de discusión sobre python en castellano" <python-es en aditel.org>
> Fecha: jueves, 10 diciembre, 2009, 1:03 pm
> El día 10 de diciembre de 2009
> 16:25, Oswall Verny Arguedas C.
> <oswallcr en yahoo.com>
> escribió:
> 
> > --> Sí va a tener concurrencia, varios puntos de
> ventas por almacén, varios almacenes...  Si lo hiciera al
> revés sería mejor opción?, realizar la lógica no con
> turbogears sino con otro framework que no necesariamente sea
> web pero que pueda incluir los clientes web.
> 
> Con ésto que dices, tienes que pensar en otra cosa; lo que
> necesitas
> no es una aplicación web. Olvídate, en un primer momento,
> de
> frameworks web y céntrate en el modelado de datos. Por
> poner un
> ejemplo, el stock debe actualizarse instantáneamente con
> cada venta
> con el fin de evitar que dos vendedores puedan vender el
> mismo
> producto simultáneamente. La forma de asegurar estos
> extremos es
> contando con un buen diseño de base de datos que impida
> estos casos.
> Para ello te aconsejo que tires por postgresql en lugar de
> mysql.

Muy buen consejo, pienso en Postgresql, con plpython y sus características de base de datos para objetos, de esta forma inclusive me podría eventualmente saltar el ORM sin que la complejidad aumente demasiado.

> En cuanto a usar ORMs, no lo veas como una necesidad. Estos
> mapeadores
> facilitan el mantenimiento de la aplicación, pero a costa
> de
> simplificar el uso y diseño de la base de datos. 

En este caso como te decía utilizo las características de Postgresql de objetos y le evito al sistema el retardo normal debido al ORM.

>Tal como
> yo lo veo
> (que no tiene porqué ser la única forma) modelaría la
> base de datos
> sin centrarme demasiado en cómo se van a consumir esos
> datos. Luego
> crearía una colección de "vistas activas" unida a una
> programación de
> una capa de negocio propia, 

Exacto, entonces la capa de negocio se desacopla y crece individualmente para donde se necesita.

> y emplearía esta capa de
> negocio en la
> presentación desde una aplicación web o una GUI. (Piensa
> que muchos
> frameworks son modulares, en los que puedes sustituir el
> ORM que
> llevan por otro e, incluso, no usar ningún ORM en
> absoluto).

Eso podría hacerlo en turbogears?.   No utilizar el SqlAlchemy.

> 
> De cara a la concurrencia, twisted ayuda bastante gracias
> con su
> orientación a eventos, integrándose muy bien en el bucle
> de eventos de
> una GUI.

Ya estoy con el.

> Para la parte web (o servicio web) podrías usar
> zope3, aunque
> lo tengo tan olvidado que desconozco si todavía vive.
> 

A mí me pareció un poco pesado, también estaba viendo webware.

> Seguramente, mi visión particular de cómo enfocar el
> problema sea
> demasiado compleja. Pienso más en que se pueda escalar
> según los
> requisitos, que en ajustarse a un presupuesto o uno plazos
> determinados.

Es un poco más compleja, pero a mediano y largo plazo es la mejor forma.

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


      ____________________________________________________________________________________
¡Obtén la mejor experiencia en la web!
Descarga gratis el nuevo Internet Explorer 8. 
http://downloads.yahoo.com/ieak8/?l=e1
_______________________________________________
Lista de correo Python-es 
http://listas.aditel.org/listinfo/python-es
FAQ: http://listas.aditel.org/faqpyes