2009-09-30 16 views
7

¿Cuáles son las características de smashing (juego de palabras) de grok que lo hacen mejor que django? ¿cómo puedo saber cuándo mi proyecto necesita grok + zope, o simplemente puede desarrollarse con django?comparación grok vs. django

Respuesta

7

Zope fue el primer marco de publicación de objetos evah, y la comunidad Zope tiene una larga experiencia con Doing Things The Right Way. Zope 2 fue el primer intento, Zope 3 fue el siguiente intento, y ahora estamos en la tercera generación de frameworks web, que incluye Grok, BFG y Bobo.

Grok es enorme, y tiene aún más módulos disponibles que no vienen cuando instala la base (y está en el proceso de reducir también el número de módulos necesarios, por lo que la huella se hace más pequeña). BFG y Bobo van al revés, y son marcos minimalistas pero con fácil acceso a Zope Toolkit y todas las funcionalidades de Zope.

Y aunque Django está cometiendo muchos de los mismos errores que Zope2, también los están reparando mucho más rápido, así que espero que gran parte de esta discusión sea discutible en cinco años, porque espero que todos los frameworks de Python WSGI + WebOb + Repoze + Deliverance + Buildout como base para entonces. Pero incluso entonces iría por marcos en los que pueda usar Zope Component Architecture y ZODB, pero eso incluye no solo los realizados por la comunidad Zope, sino también, por ejemplo, Turbogears. Y tal vez también incluya a Django para entonces, quién sabe ... :-)

Dependiendo de cuáles sean los requisitos del proyecto, hoy elegiría Plone (si necesitan CMS), Grok o BFG (según el desarrolladores involucrados, y la complejidad de la tarea y el presupuesto).Esto, por supuesto, depende en parte de mi gran experiencia con las tecnologías Zope y mi pequeña experiencia con Django, pero principalmente porque puedo usar ZTK y ZODB en Grok y BFG.

YMMV, etc., blahblah.

2

No creo que ninguno de los frameworks tenga alguna 'característica' que lo haga a uno 'mejor' que el otro, o 'necesario' en ciertas circunstancias. Por el contrario, la diferencia entre Django y Grok - o Pylons, o Turbogears - es realmente una de enfoque. Puede encontrar el enfoque de Grok a su gusto, o puede preferir uno de los otros. Dudo que haya mucho que puedas lograr en uno de ellos que no puedas en ninguno de los otros.

+1

Lo que me impresiona es el tamaño de grok + zope con respecto a Django. Entonces me pregunto. ¿Qué pasa si necesito algo que está allí, pero por el momento no sé? –

+0

Luego, escríbela para Django, es de código abierto. –

5

Grok es básicamente todo el poder de zope en un paquete mucho más fácil de usar. Así que obtienes todo el lujo de una base de datos de objetos python real (aunque puedes usar un back-end sql). Y supongo que conoce los adaptadores/utilidades/vistas de la llamada "arquitectura de componentes zope". Esos permiten hacer una aplicación robusta. Especialmente útil si luego necesita personalizarlo selectivamente. Y la seguridad es tradicionalmente un punto fuerte zope (y grok). El desarrollo y la implementación se manejan completamente con eggs (y buildout): en mi experiencia, esta es una manera robusta, confiable, repetible y cómoda.

Si tiene una aplicación que puede trabajar con tablas SQL directas sin necesidad de mucha personalización selectiva después: nada malo con django. Tendrás que hacer mucha seguridad tú mismo, así que eso requiere un buen ojo. Hay mucho menos marco detrás de esto (un ORM y un mapeador de url), por lo que su pitón se sentirá más "puro y simple". Esto también significa que necesitas hacer más tú mismo.

No hay nada que le impida utilizar selectivamente partes de grok: http://pypi.python.org/pypi/grokcore.component, por ejemplo, es el núcleo. Muy bien aislado, así que puedes usarlo sin comprar todo el zope stack. Estoy bastante seguro de que puedes usar eso en django. El componente grokcore/zope es solo código python. Esto le proporciona los adaptadores/interfaces/utilidades. No sé lo que estás construyendo, así que tendrás que experimentar.

Una cosa muy a favor de grok que sugeriría probar: base de datos de objetos ZODB de zope. Un buen ORM (y el de django está bastante bien) ayuda mucho a sacar el dolor de las bases de datos SQL, pero una base de datos de objetos real es sencillamente de lujo :-)

Cuestiones relacionadas