python Turbogears 2 vs Django - 关于选择 Turbogears 1 的替代品有什么建议吗？

Turbogears 2 vs Django - any advice on choosing replacement for Turbogears 1?

提问by michela

I have been using Turbogears 1 for prototyping small sites for the last couple of years and it is getting a little long in the tooth. Any suggestions on making the call between upgrading to Turbogears 2 or switching to something like Django? I'm torn between the familiarity of the TG community who are pretty responsive and do pretty good documentation vs the far larger community using Django. I am quite tempted by the built-in CMS features and the Google AppEngine support.

在过去的几年里，我一直在使用 Turbogears 1 来制作小型站点的原型，但它的使用时间有点长。关于在升级到 Turbogears 2 或切换到 Django 之类的东西之间进行调用有什么建议吗？我在 TG 社区的熟悉程度之间左右为难，他们反应灵敏，文档做得很好，而更大的社区使用 Django。我非常喜欢内置的 CMS 功能和 Google AppEngine 支持。

Any advice?

有什么建议吗？

Thanks

谢谢

.M.

.M.

采纳答案by codeape

I have experience with both Django and TG1.1.

我有 Django 和 TG1.1 的经验。

IMO, TurboGears strong point is it's ORM: SQLAlchemy. I prefer TurboGears when the database side of things is non-trivial.

IMO，TurboGears 的强项是它的 ORM：SQLAlchemy。当数据库方面的事情很重要时，我更喜欢 TurboGears。

Django's ORM is just not that flexible and powerful.

Django 的 ORM 只是没有那么灵活和强大。

That being said, I prefer Django. If the database schema is a good fit with Django's ORM I would go with Django.

话虽如此，我更喜欢Django。如果数据库模式非常适合 Django 的 ORM，我会选择 Django。

In my experience, it is simply less hassle to use Django compared with TurboGears.

根据我的经验，与 TurboGears 相比，使用 Django 更简单。

回答by Federico

TG2 is built on top of Pylons which has a fairly large community as well. TG got faster compared to TG1 and it includes a per-method (not just web pages) caching engine. I think it's more AJAX-friendly than Django by the way pages can be easly published in HTML or JSON .

TG2 建立在 Pylons 之上，Pylons 也拥有相当大的社区。与 TG1 相比，TG 变得更快，并且它包含一个按方法（不仅仅是网页）缓存引擎。我认为它比 Django 对 AJAX 更友好，因为页面可以很容易地以 HTML 或 JSON 格式发布。

2011 update: after 3 years of bloated frameworks I'm an happy user of http://bottlepy.org/

2011 年更新：经过 3 年臃肿的框架，我是http://bottlepy.org/的快乐用户

回答by AutomatedTester

I have been using Django for a year now and when I started I had no experience of Python or Django and found it very intuitive to use.

我已经使用 Django 一年了，当我开始使用 Python 或 Django 时，我发现它使用起来非常直观。

I have created a number of hobbyist Google App Engine apps using Django with the latest one being a CMS for my site. Using Django has meant that I have been able to code a lot quicker and with a lot less bugs.

我已经使用 Django 创建了许多业余爱好者的 Google App Engine 应用程序，最新的一个是我网站的 CMS。使用 Django 意味着我能够更快地编写代码并减少错误。

回答by simplyharsh

Am sure you would have read from plenty of comparison between TurboGears and DJango on web.

相信您会在网上阅读大量 TurboGears 和 DJango 之间的比较。

But as for your temptation on CMS and GAE, i can really think you got to go DJango way. Check these out, and decide youself.

但至于您对 CMS 和 GAE 的诱惑，我真的认为您必须采用 DJango 方式。看看这些，然后自己决定。

Django with GAE

带有 GAE 的 Django

Django for CMS

用于 CMS 的 Django

回答by Belxjander Serechai

Ive only got one question...is the app you are developing directed towards social networking or customized business logic?

我只有一个问题……您正在开发的应用程序是针对社交网络还是自定义业务逻辑？

I personally find Django is good for social networking and pylons/turbogears if you really want the flexibility and no boundaries...

我个人认为 Django 非常适合社交网络和 pylons/turbogears，如果你真的想要灵活性和无边界的话......

just my 2c

只是我的 2c

回答by saeedgnu

TG2 seem much complicated and confusing, even for doing somewhat simple like a login page with multimple error messages How to extend the Turbogears 2.1 login functionalityI think thats because of intemperance in modularity...

TG2 看起来非常复杂和令人困惑，即使是像带有多个错误消息的登录页面一样简单 如何扩展 Turbogears 2.1 登录功能我认为那是因为模块化的不节制......

回答by Omid Zarin

Django ORM uses the active record implementation – you'll see this implementation in most ORMs. Basically what it means is that each row in the database is directly mapped to an object in the code and vice versa. ORM frameworks such as Django won't require predefining the schema to use the properties in the code. You just use them, as the framework can ‘understand' the structure by looking at the database schema. Also, you can just save the record to the database, as it's mapped to a specific row in the table.

Django ORM 使用活动记录实现——您将在大多数 ORM 中看到这种实现。基本上它的意思是数据库中的每一行都直接映射到代码中的一个对象，反之亦然。ORM 框架（例如 Django）不需要预定义架构来使用代码中的属性。您只需使用它们，因为框架可以通过查看数据库架构来“理解”结构。此外，您可以将记录保存到数据库中，因为它映射到表中的特定行。

SQLAlchemy uses the Data Mapper implementation – When using this kind of implementation, there is a separation between the database structure and the objects structure (they are not 1:1 as in the Active Record implementation). In most cases, you'll have to use another persistence layer to keep interact with the database (for example, to save the object). So you can't just call the save() method as you can when using the Active Record implementation (which is a con) but on the other hand, you code doesn't have to know the entire relational structure in the database to function, as there is no direct relationship between the code and the database.

SQLAlchemy 使用 Data Mapper 实现——当使用这种实现时，数据库结构和对象结构之间存在分离（它们不是 Active Record 实现中的 1:1）。在大多数情况下，您必须使用另一个持久层来保持与数据库的交互（例如，保存对象）。因此，您不能像使用 Active Record 实现时一样调用 save() 方法（这是一个缺点），但另一方面，您的代码不必知道数据库中的整个关系结构即可运行，因为代码和数据库之间没有直接关系。

So which of them wins this battle? None. It depends on what you're trying to accomplish. It's my believe that if your application is a mostly a CRUD (Create, Read, Update, Delete) application which no hard and complex rules to apply on the relationships between the different data entities, you should use the Active Record implementation (Django). It will allow you to easily and quickly set up an MVP for your product, without any hassle. If you have a lot of “business rules” and restrictions in your applications, you might be better with the Data Mapper model, as it won't tie you up and force you to think strictly as Active Record does.

那么他们中谁赢得了这场战斗？没有任何。这取决于您要实现的目标。我相信，如果您的应用程序主要是一个 CRUD（创建、读取、更新、删除）应用程序，没有硬性和复杂的规则应用于不同数据实体之间的关系，那么您应该使用 Active Record 实现（Django）。它将允许您轻松快速地为您的产品设置 MVP，没有任何麻烦。如果您的应用程序中有很多“业务规则”和限制，那么使用 Data Mapper 模型可能会更好，因为它不会束缚您并强迫您像 Active Record 那样严格思考。