Python vs PHP

javier lasheras javier.lasheras en telefonica.net
Mie Feb 22 23:08:16 CET 2006


Buenas:

Creo que el amigo Chema tiene algo de razón en que si realmente te  
refieres a un modelo de tres capas y no al MVC, es posible que por  
ejemplo java sea más adecuado.

Es posible que quieras implementar la logica de negocio en clases  
accesibles desde un interfaz web (con su MVC por ejemplo) o desde un  
cliente pesado (GTK por ejemplo), pero ejecutando la lógica siempre  
en el servidor. Para hacer eso, java propone su modelo de EJB como  
opción más recomendable (c# no tengo ni idea pero supongo que será  
algo de DCOM). En python tienes varias alternativas para ejecutar de  
forma fácil llamadas remotas:
- XML-RPC Es simple y esta integrado con el core de python.  
Multilenguaje. Dentro de la sobrecarga que da usar XML, es muy ligero  
comparado con SOAP. http://docs.python.org/lib/module-xmlrpclib.html
- SOAP Versión pesada del XML-RPC con algún añadido más que no se si  
estan enteramente implementados en http://soapy.sourceforge.net/.  
Creo recordar que si quieres crear un WSDL lo tienes un poco dificil  
(cosas del tipado dinamico).
- PyRO Es una librería que se parece más a EJB's. Como suele ser en  
python, más facil de usar, pero por desgracia no tan completo. He  
oido que en un banco pusieron PyRO, porque la cola de mensajes les  
iba más rápido que Typco. Aunque la cola de mensajes no permite  
storage como las implementaciones de JMS de Java. Interesante y  
siempre puedes extenderlo a tus necesidades (tienes el codigo fuente)  
http://pyro.sourceforge.net/
- ...

Los últimos puntos suspensivos los puse para que rellenen otros  
contertulios ;-) asi de cabeza no se me ocurren más soluciones, pero  
fijo que hay algo para usar Corba y demás familia.

Para el tema de encapsular el acceso a las entidades, o a la base de  
datos (hablando en plata), también tienes algunas posibilidades  
http://wiki.python.org/moin/DatabaseInterfaces#head- 
b497c745dabc47cc09a14ceae577aded06ec8f31
Yo he usado satisfactoriamente SQLObject, aunque he visto a gente  
quejarse de el y proponer el uso de SQLAlchemy, que por cierto tiene  
pinta de dejarte hacer todo. Aunque creo que este ultimo no lo han  
acabado todavía.

Y como último ejemplo, y menos clarificador (que chema me perdone)  
voy a proponerte usar un framework MVC para hacer un servidor en 3  
capas. Turbogears va a ser el Framework:
- Cliente/Vista: En un cliente web, lo tienes todo hecho. Con un  
cliente pesado, emularía la forma de invocar procedimientos remotos  
como se hacen con SOAP-Document en JSON. El controlador de Turbogears  
esta preparado para trabajar con JSON sin hacer nada :-D Hacer las  
fachadas va a ser más coñazo que usar xml-rpc o pyro.
- Negocio: Una vez hechas las fachadas en el controlador, haría las  
clases del negocio en python puro y duro. LLamarias las clases desde  
en controlador. Si quieres escalar la aplicación, siempre puedes usar  
balanceadores web y repartir las peticiones en varios servidores.
- Persistencia: SQLObject es facil y no parece que tenga mal  
rendimiento para cosas no demasiado grandes. Para cosas grandes, me  
parece tan mala elección como elegir EJB de Entidad. Eso de hacer una  
query por registro, me da mucho miedo.

Notese que el controlador del MVC, ha sido usado en la capa cliente y  
negocio. La vista del MVC es opcional y no se usa en clientes pesados  
(GTK por ejemplo). El modelo del MVC te hace también la persistencia  
de datos, que no es requisito para el patron MVC, pero que nos viene  
de maravilla para las 3 capas y en la gran mayoria de nuestros  
desarrollos. Espero que mi ejemplo sirva para clarificar que MVC no  
es 3 capas, aunque creo que yo tb he estado muy liado mucho tiempo :-/




El 22/02/2006, a las 16:27, Luis Marucco escribió:

> Hola a todos, quiero aprovechar esta oportunidad para agradecer sus  
> opiniones. Con respecto a tu pregunta sobre las 3 capas, que es  
> algo independiente del lenguaje que prengunté, pero lo hice para  
> saber si puedo armar en la capa de negocios, componentes con python  
> para un mejor mantenimiento y actualizacion del soft, o si tengo  
> que caer en otro lenguaje; me imagino que si, pero desconozco  
> completamente python.
> Saludos
> Gracias a todos nuevamente
> Luis
>
>
> Chema Cortes escribió:
>
>> On 2/21/06, Luis Marucco <lmarucco en gmail.com> wrote:
>>
>>> Hola a todos, tengo que empezar a desarrollar un sitio web bajo
>>> plataforma linux. Por el tipo de sistema, el desarrollo tiene que  
>>> ser en
>>> 3 capas (interface, regla de negocios y acceso a datos). Que me
>>> aconsejan??? Muchisimas gracias a todos.
>>> Saludos
>>> Luis
>>> PD: Tengo pocos conocimientos de PHP y nulos en Python, pero algo  
>>> tengo
>>> que aprender !!
>>>
>>
>> Yo no voy a insistir en los mismos argumentos que ya te han dado  
>> otros
>> "colisteros". Lo que quisiera preguntar es el motivo por el cuál  
>> tiene
>> que ser un desarrollo en tres capas. Es una cuestión que veo que se
>> repite en esta lista y no entiendo bien el motivo; a no ser que sea
>> porque se confunda con el patrón MVC (Modelo-Vista-Controlador)
>> empleado por muchos "frameworks" para aplicaciones web.
>>
>> Lo digo porque el desarrollo de tres capas es mucho más complejo que
>> la simple elección del lenguaje de programación. Estaríamos hablando
>> de estructuras de cliente/servidor, de su mantenimiento y su
>> escalibilidad, de si estamos en una red homogénea o heterogénea.
>> Python, por ser de propósito general y multiplataforma podría ser uno
>> de los lenguajes apropiados, pero en la actualidad se emplea mucho  
>> más
>> java ó C#/VB.Net para estas tareas.
>> _______________________________________________
>> Python-es mailing list
>> Python-es en aditel.org
>> http://listas.aditel.org/listinfo/python-es
>>
>>
>
> _______________________________________________
> Python-es mailing list
> Python-es en aditel.org
> http://listas.aditel.org/listinfo/python-es




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