2009-09-30 14 views
7

Quali sono le caratteristiche di smashing (gioco di parole) di grok che lo rendono migliore di django? come faccio a sapere quando il mio progetto ha bisogno di grok + zope, o può essere semplicemente sviluppato con django?grok vs confronto django

risposta

7

Zope è stato il primo oggetto di pubblicazione di oggetti evah e la comunità Zope ha una lunga esperienza con Doing Things The Right Way. Zope 2 è stato il primo tentativo, Zope 3 è stato il prossimo tentativo, e ora siamo nella terza generazione di framework web, che include Grok, BFG e Bobo.

Grok è enorme e ha ancora più moduli disponibili che non arrivano quando si installa la base (ed è in procinto di ridurre il numero di moduli richiesti, quindi l'ingombro si riduce). BFG e Bobo fanno il contrario, e sono quadri minimalisti ma con facile accesso a Zope Toolkit ea tutte le funzionalità di Zope.

E sebbene Django stia facendo molti degli stessi errori di Zope2, li sta anche aggiustando molto più velocemente, quindi mi aspetto che gran parte di questa discussione sia discutibile in cinque anni, perché mi aspetto che ogni singolo framework web Python usi Fino a quel momento WSGI + WebOb + Repoze + Deliverance + Buildout come base. Ma anche allora andrei a cercare framework in cui poter utilizzare Zope Component Architecture e ZODB, ma questo include non solo quelli creati dalla comunità Zope, ma anche da Turbogears. E forse includerà anche Django, chissà ... :-)

A seconda di quali sono i requisiti del progetto, oggi utilizzerei Plone (se hanno bisogno di CMS), Grok o BFG (a seconda della sviluppatori coinvolti e la complessità del compito e del budget).Ciò dipende, in parte, dalla mia grande esperienza con le tecnologie Zope e dalla mia piccola esperienza con Django, ma soprattutto perché posso usare ZTK e ZODB in Grok e BFG.

YMMV, ecc., Blahblah.

2

Non penso che nessuno dei framework sia destinato ad avere "caratteristiche" che rendono uno "migliore" dell'altro o "necessario" in determinate circostanze. Piuttosto, la differenza tra Django e Grok - o Pylons, o Turbogears - è davvero un approccio. Potresti trovare l'approccio di Grok a tuo piacimento, oppure potresti preferire uno degli altri. Dubito che ci sia molto che puoi ottenere in uno di loro che non puoi in nessuno degli altri.

+1

Ciò che mi impressiona è la dimensione di Grok + Zope rispetto a Django. Quindi mi chiedo. Cosa succede se ho bisogno di qualcosa che è lì dentro, ma al momento non lo so? –

+0

Quindi scrivilo per Django - è open source. –

5

Grok è praticamente tutta la potenza di zope in un modo più facile da usare pacchetto. In questo modo ottieni tutto il lusso di un vero e proprio database di oggetti python (anche se puoi usare un back-end SQL). E presumo che tu sappia degli adattatori/utilità/viste della cosiddetta "architettura dei componenti di zope". Quelli ti permettono di fare un'applicazione robusta. Particolarmente utile se in seguito è necessario personalizzarlo in modo selettivo. E la sicurezza è tradizionalmente un punto forte di zope (e quindi grok). Lo sviluppo e la distribuzione sono gestiti completamente con uova (e buildout): nella mia esperienza questo è un modo robusto, affidabile, ripetibile e confortevole.

Se si dispone di un'applicazione che può funzionare con tabelle sql diritte senza bisogno di molta personalizzazione selettiva in seguito: niente di sbagliato in django. Dovrai fare molta sicurezza da solo, quindi è necessario un occhio attento. C'è molto meno di un framework dietro (un ORM e un mapper url), quindi il tuo pitone si sentirà più "puro e semplice". Questo significa anche che devi fare di più da solo.

Non c'è nulla che ti impedisca di utilizzare in modo selettivo parti di grok: http://pypi.python.org/pypi/grokcore.component, ad esempio, è il nucleo. Abbastanza bene isolato, quindi puoi usarlo senza acquistare l'intero stack di zope. Sono abbastanza sicuro che puoi usarlo in django. Il componente grokcore/zope è solo un codice Python. Questo ti porta gli adattatori/interfacce/utilità. Non so cosa stai costruendo, quindi dovrai sperimentare.

Una cosa a favore di Grok che suggerirei di provare: il database degli oggetti ZODB di Zope. Un buon ORM (e django's è ok) aiuta molto a risolvere il problema dei database SQL, ma un vero database di oggetti è semplicemente di lusso :-)