Un breve análisis de varios marcos PythonWeb comúnmente utilizados

Entre las diversas plataformas de lenguaje, Python probablemente tiene la mayor cantidad de marcos web emergentes. Es un mundo donde florecen cien flores, con innumerables micro-marcos y marcos. Supongo que la razón es que el marco está construido en; Python Tan simple que la rueda se sigue inventando. Entonces

Siempre hay temas en la comunidad de Python sobre qué marco de Python es mejor o peor. Permítanme presentarles varios frameworks de Python importantes:

Django

Django debería ser el framework de py más famoso de Google App Engine e incluso Erlang tiene frameworks afectados por él.

Django está tomando una dirección amplia y completa. Es más famoso por su backend de administración totalmente automatizado: solo necesita usar el ORM y hacer definiciones de objetos simples, y puede generar automáticamente la estructura de la base de datos y la base de datos. Base de datos completa. Backend de gestión funcional.

La conveniencia proporcionada por Django también significa que el ORM integrado de Django está altamente acoplado con otros módulos en el marco.

La aplicación debe utilizar el ORM integrado de Django; de lo contrario, no podrá disfrutar de las diversas ventajas basadas en ORM proporcionadas en el marco. En teoría, puede cambiar su módulo ORM, pero así es; equivalente a completar la decoración. Si la casa va a ser demolida y renovada, es mejor ir a la casa en bruto para hacer una nueva decoración desde el principio.

El punto de venta de Django es su eficiencia de desarrollo ultra alta, pero su expansión de rendimiento es limitada; los proyectos que utilizan Django deben reconstruirse después de que el tráfico alcanza una cierta escala para cumplir con los requisitos de rendimiento.

Las deficiencias de Django se deben principalmente a la insistencia de Django en fabricar todas sus propias ruedas. Todo el sistema es relativamente cerrado. Los aspectos más criticados de Django son:

· El sistema es estricto. acoplado Si cree que cierta función integrada en Django no es muy buena y es difícil reemplazarla con su biblioteca de terceros favorita, como el ORM y la plantilla que se mencionan a continuación. Es casi imposible usar SQLAlchemy o Mako en Django, e incluso si aplicas algunos parches, te hará sentir muy, muy incómodo.

· El ORM que viene con Django es mucho menos potente que SQLAlchemy. Excepto por Django, SQLAlchemy es el estándar ORM de facto en el mundo de Python. Otros marcos soportan SQLAlchemy, pero Django todavía tiene el suyo propio. ideas. Los desarrolladores de Django también discutieron e intentaron admitir SQLAlchemy, pero finalmente se dieron por vencidos. Se estima que el costo es demasiado alto y es difícil de integrar con otros módulos de Django.

· La función de plantilla es relativamente débil y no se puede insertar en el código Python. Para escribir una lógica más compleja, necesita usar Python para implementar Tag o Filter. El diseño del sistema de plantillas de Django es muy interesante y debería ser la parte más influyente y controvertida de su marco.

La filosofía de diseño de las plantillas de Django es separar completamente el código y los estilos; asp.net aboga por la separación de código/plantillas, pero técnicamente aún se pueden mezclar y Django elimina fundamentalmente la necesidad de hacerlo; Plantillas. Posibilidad de codificar y procesar datos.

Por ejemplo, en la plantilla asp.net puedes escribir:

int i;

for(i==0;i

....

}

%>

Django no admite la incrustación de código como el anterior y solo puede usar las funciones integradas en su plantilla; esto es en realidad Arriba, se construye un "nuevo lenguaje" para sus plantillas porque este "nuevo lenguaje" es muy simple, sus plantillas también se pueden portar a diferentes plataformas. Las plantillas de Django son muy simples. La función es suficiente, pero para situaciones especiales (a veces "especiales" no es muy especial), aún necesita incrustar código en la plantilla, luego debe expandir la plantilla de acuerdo con las reglas de su plantilla. sistema.

A veces, un problema que se puede resolver escribiendo

una línea de código directamente en la plantilla se convertirá en más de una docena de líneas de código después de implementarse con la extensión de la plantilla.

Si se tolera la programación en plantillas es el aspecto más controvertido de las plantillas de Django.

Pylons & TurboGears & repoze.bfg

Además de Django, el otro grande es Pylons, porque TurboGears2.x se basa en Pylons y repoze.bfg también se ha fusionado con Pylons. En este gran proyecto, TurboGears y repoze.bfg no se analizarán por separado más adelante.

Los conceptos de diseño de Pylons y Django son completamente diferentes. Pylons en sí solo tiene alrededor de dos mil líneas de código Python, pero también viene con algunos módulos de terceros que casi utilizan Pylons. Pylons solo proporciona un estante y soluciones opcionales. Puede seleccionar libremente componentes como plantilla, ORM, formulario, autenticación, etc. según sus propias preferencias. A menudo decimos que Python es un lenguaje adhesivo, por lo que definitivamente podemos decir que Pylons es un marco adhesivo diseñado con lenguaje adhesivo.

Elegir Pylons probablemente sea elegir su libertad. Elegir la libertad también indica que has elegido Nightmare:

· Learning Nightmare, Pylons se basa en muchas bibliotecas de terceros. Pylons. Cuando aprendes Pylons, también tienes que aprender a usar estas bibliotecas. La clave es que a veces no sabes lo que quieres aprender. La curva de aprendizaje de Pylons es mucho más alta que la de Django, y la documentación oficial anterior de Pylons siempre ha sido objeto de críticas. Afortunadamente, el libro The Definitive Guide to Pylons se publicó más tarde. Por esta razón, Pylons alguna vez fue conocido como un marco de Python solo apto para expertos.

· Pesadilla de depuración, porque hay muchos módulos involucrados y una vez que ocurre un error, es difícil localizar el problema. Puede ser culpa del programa que escribiste, o puede ser que Pylons esté mal, o SQLAlchemy esté mal, o tal vez haya un error en el código formen, que de todos modos es muy complicado.

Este problema sólo se puede solucionar si estás familiarizado con él.

· Pesadilla de actualización, instalar Pylons de todos los tamaños*** requiere instalar casi 20 módulos de Python, cada uno con su propio número de versión. Para actualizar la versión de Pylons, cualquier módulo puede tener problemas de incompatibilidad. Es básicamente muy difícil. Hasta ahora, Pylons de reddit todavía está atascado en la versión antigua 0.9.6, y SQLAlchemy todavía está en la versión 0.5.3, lo que debería estar relacionado con esto.

La integración de Pylons y repoze.bfg puede dar origen al próximo marco que pueda desafiar el estatus de Django.

Tornado y web.py

Tornado( En comparación con Tornado(, Tornado es un poco similar y solo implementa AsyncHttpHandler; aparte de eso, debes implementar todo tú mismo.

Bueno, en realidad tiene plantillas, soporte de internacionalización e incluso un módulo OAuth/OpenID integrado para facilitar el inicio de sesión de terceros. En realidad, implementa directamente el servidor HTTP. tiene un ORM (solo hay un paquete súper simple de mysql) y ni siquiera hay soporte para sesiones, y mucho menos un backend automatizado como Django

Suponiendo que es un sitio web grande, bajo el requisito de alto. rendimiento, todas las partes del marco a menudo se agotan. Es necesario personalizarlo y hay muy pocos módulos que se pueden reutilizar para un sitio web desarrollado con Django, cada parte se ha personalizado continuamente y lo que queda del marco de Django es; Probablemente sea lo que el tornado puede proporcionar desde el principio.

Esta parte

Diferentes caminos conducen al mismo objetivo.

Servidor HTTP

Para implementar eficientemente la llamada asincrónica de Comet/backend a la interfaz HTTP, Tornado integra directamente el servidor HTTP.

El navegador puede acceder al front-end sin agregar apache/lighttpd/nginx, etc., sin embargo, no implementa completamente el protocolo HTTP 1.1, por lo que el documento oficial recomienda a los usuarios usar nginx en el front-end en el entorno de producción. Proxy inverso lateral para múltiples instancias de Tornado.

Tornado en sí es un programa de red asíncrono de un solo subproceso cuando se inicia de forma predeterminada, ejecutará múltiples instancias de acuerdo con la cantidad de CPU aprovechando al máximo la CPU de múltiples núcleos.

Asíncrono de un solo subproceso

Los sitios web básicamente tienen operaciones de base de datos y Tornado es de un solo subproceso, lo que significa que si la consulta de la base de datos regresa demasiado lentamente, se bloqueará toda la respuesta del servidor.

Las consultas a bases de datos son esencialmente llamadas de red remotas; idealmente, estas operaciones se encapsularían como asíncronas, pero Tornado no proporciona ningún soporte para esto;

Para que un sistema pueda soportar un tráfico elevado, debe resolver el problema de la velocidad de consulta de la base de datos.

Si hay un problema de rendimiento de consultas en la base de datos, no importa cuán optimizado esté todo el sistema, ¡la base de datos será el cuello de botella y ralentizará todo el sistema!

La asincronía no **esencialmente** mejora el rendimiento del sistema; simplemente evita esperas innecesarias de respuestas de la red y el consumo de CPU de los subprocesos de conmutación.

Si la respuesta a la consulta de la base de datos es demasiado lenta, lo que hay que resolver es el problema de rendimiento de la base de datos, no la aplicación web front-end que llama a la base de datos.

Para consultas de datos devueltos en tiempo real, idealmente es necesario asegurarse de que todos los datos estén en la memoria y que la E/S del disco duro de la base de datos sea 0; dicha consulta puede ser lo suficientemente rápida; la consulta es lo suficientemente rápida, entonces la web front-end no necesita que las aplicaciones encapsulen las consultas de datos como asincrónicas

Incluso si se utilizan corrutinas, los programas asincrónicos siempre aumentarán la complejidad de los programas sincrónicos; Lo que hay que medir es si vale la pena abordar la complejidad adicional.

Si hay consultas en el backend que son demasiado lentas para omitirlas, la sugerencia de Tornaod es encapsular estas consultas de forma independiente en el backend en interfaces HTTP y luego usar el cliente HTTP asincrónico integrado de Tornado para llamarlas.