grok vs. porównanie django

Question

Jakie są granie, które jest lepsze od django? Skąd mam wiedzieć, kiedy mój projekt potrzebuje grok + zope, lub może być rozwijany z django?

Answer 1

Zope był pierwszym obiektem przeznaczonym do publikowania obiektów, a społeczność Zope ma długie doświadczenie z Doing Things The Right Way. Zope 2 było pierwszą próbą, Zope 3 była kolejną próbą, a teraz jesteśmy trzecią generacją frameworków internetowych, w tym Grok, BFG i Bobo.

Grok jest masywny i ma jeszcze więcej modułów, które nie są dostępne podczas instalacji bazy (a także zmniejsza liczbę wymaganych modułów, dzięki czemu zajmuje mniej miejsca). BFG i Bobo działają odwrotnie i są minimalistycznymi strukturami, ale mają łatwy dostęp do Zope Toolkit i wszystkich funkcji Zope.

I chociaż Django popełnia wiele błędów, które popełnił Zope2, to one także naprawiają je znacznie szybciej, więc całkowicie spodziewam się, że wiele z tych dyskusji będzie dyskusyjnych w ciągu pięciu lat, ponieważ oczekuję, że każda platforma internetowa Pythona będzie używać WSGI + WebOb + Repoze + Deliverance + Buildout jako baza do tego czasu. Ale nawet wtedy wybieram ramy, w których mogę korzystać z Zope Component Architecture i ZODB, ale obejmuje to nie tylko te wykonane przez społeczność Zope, ale także na przykład Turbogears. I może będzie to również Django, kto wie ... :-)

Zależnie od wymagań projektu, chciałbym dzisiaj przejść z Plone (jeśli potrzebują CMS), Grok lub BFG (w zależności od zaangażowani programiści oraz złożoność zadania i budżetu).Jest to oczywiście częściowo zależne od mojego dużego doświadczenia z technologiami Zope i mojego małego doświadczenia z Django, ale głównie dlatego, że mogę używać ZTK i ZODB w Grok i BFG.

YMMV, itp., Blahblah.

• Zope Toolkit
• Brandons rozmawiać na Zope Component Architecture (Video from PyCOn, Slides from PloneConf)
• BFG
• Bobo

Answer 2

Nie sądzę, że jakiekolwiek ramy mają mieć "cechy", które czynią "lepszym" od drugiego, lub "potrzebne" w pewnych okolicznościach. Różnica między Django i Grokiem - lub Pylons, lub Turbogears - jest naprawdę jednym z podejść. Możesz znaleźć podejście Grok do swoich potrzeb, lub możesz preferować jednego z innych. Wątpię, by w jednym z nich można było wiele osiągnąć, czego nie można osiągnąć w żadnym innym.

Answer 3

Grok to w zasadzie cała moc zope w łatwiejszy w użyciu pakiet. Dostajesz więc cały luksus prawdziwej bazy danych obiektów Pythona (możesz jednak użyć zaplecza sql). Zakładam, że wiesz o adapterach/narzędziach/widokach tak zwanej "architektury komponentów zope". Dzięki nim możesz stworzyć solidną aplikację. Jest to szczególnie przydatne, jeśli później trzeba go selektywnie dostosować. Bezpieczeństwo jest tradycyjnie zope (a więc grok) mocną stroną. Rozwój i wdrożenie są w pełni obsługiwane za pomocą jajek (i buildout): z mojego doświadczenia wynika, że ​​jest to solidny, niezawodny, powtarzalny i wygodny sposób.

Jeśli masz aplikację, która może pracować z prostymi tabelami sql bez konieczności późniejszego selektywnego dostosowywania: nic złego w django. Będziesz musiał zrobić dużo bezpieczeństwa samemu, tak że potrzebuje dobrego oka. Jest o wiele mniej frameworków (ORM i mapowanie URL), więc twój pyton będzie czuł się bardziej "czysty i prosty". Oznacza to również, że musisz zrobić więcej samodzielnie.

Nic nie powstrzymuje cię przed selektywnym używaniem części grok: na przykład jest bardzo rdzeniem. Całkiem dobrze odizolowane, dzięki czemu można go używać bez kupowania w całym stosie zope. Jestem prawie pewien, że możesz użyć tego w django. grokcore/zope to po prostu kod Pythona. W ten sposób otrzymasz adaptery/interfejsy/narzędzia. Nie wiem, co budujesz, więc będziesz musiał eksperymentować.

Jedna rzecz ogromnie na rzecz Grok, którą proponuję wypróbować: bazę danych obiektów ZODB zope. Dobry ORM (i django jest całkiem w porządku) bardzo pomaga w wyładowaniu bólu z baz danych SQL, ale prawdziwa baza danych obiektów to po prostu luksus :-)