Turbogears 2 与 Django - 对于选择 Turbogears 1 的替代品有什么建议吗？
过去几年我一直在使用 Turbogears 1 来制作小型网站的原型，但它的使用时间已经有点长了。 对于升级到 Turbogears 2 还是切换到 Django 之类的东西有什么建议吗？ 我在 TG 社区的熟悉度和使用 Django 的更大社区之间左右为难，TG 社区响应速度非常快，文档也非常好。 我对内置的 CMS 功能和 Google AppEngine 支持很感兴趣。
有什么建议吗？
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.
Any advice?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
TG2 建立在 Pylons 之上，Pylons 也拥有相当大的社区。 与 TG1 相比，TG 速度更快，并且它包含每个方法（不仅仅是网页）缓存引擎。
我认为它比 Django 对 AJAX 更友好，因为页面可以轻松地以 HTML 或 JSON 形式发布。
2011 年更新：在使用了 3 年臃肿的框架之后，我很高兴成为 http://bottlepy.org/ 的用户
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 .
2011 update: after 3 years of bloated frameworks I'm an happy user of http://bottlepy.org/
我有 Django 和 TG1.1 的经验。
IMO，TurboGears 的强项是它的 ORM：SQLAlchemy。 当数据库方面的事情很重要时，我更喜欢 TurboGears。
Django 的 ORM 并不是那么灵活和强大。
话虽这么说，我更喜欢 Django。 如果数据库模式非常适合 Django 的 ORM，我会选择 Django。
根据我的经验，与 TurboGears 相比，使用 Django 更省事。
I have experience with both Django and TG1.1.
IMO, TurboGears strong point is it's ORM: SQLAlchemy. I prefer TurboGears when the database side of things is non-trivial.
Django's ORM is just not that flexible and powerful.
That being said, I prefer Django. If the database schema is a good fit with Django's ORM I would go with Django.
In my experience, it is simply less hassle to use Django compared with TurboGears.
我已经使用 Django 一年了，当我开始使用时，我没有 Python 或 Django 的经验，但发现它使用起来非常直观。
我使用 Django 创建了许多业余爱好者 Google App Engine 应用程序，最新的一个是我网站的 CMS。 使用 Django 意味着我能够更快地编写代码并且错误更少。
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.
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.
我确信您已经阅读过网络上 TurboGears 和 DJango 之间的大量比较。
但至于你对 CMS 和 GAE 的诱惑，我真的认为你必须走 DJango 的路。
看看这些，然后自己决定。
使用 GAE 的 Django
< a href="http://blueflavor.com/blog/2007/dec/03/django-a-flexible-choice-for-y/" rel="nofollow noreferrer">CMS 的 Django
Am sure you would have read from plenty of comparison between TurboGears and DJango on web.
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.
Django with GAE
Django for CMS
我只有一个问题......您正在开发的应用程序是针对社交网络的吗
或者定制的业务逻辑？
我个人发现 Django 非常适合社交网络和塔架/涡轮齿轮，如果你真的
想要灵活性和无界限...
只是我的 2c
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...
just my 2c
TG2 看起来非常复杂和令人困惑，即使是做一些简单的事情，比如带有多个错误消息的登录页面
如何扩展 Turbogears 2.1 登录功能
我认为那是因为模块化的不节制......
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 functionality
I think thats because of intemperance in modularity...
Django ORM 使用活动记录实现 - 您将在大多数 ORM 中看到此实现。 基本上，这意味着数据库中的每一行都直接映射到代码中的一个对象，反之亦然。 ORM 框架（例如 Django）不需要预定义架构即可使用代码中的属性。 您只需使用它们，因为框架可以通过查看数据库模式来“理解”结构。 此外，您可以将记录保存到数据库，因为它映射到表中的特定行。
SQLAlchemy 使用 Data Mapper 实现 - 当使用这种实现时，数据库结构和对象结构之间存在分离（它们不像 Active Record 实现中那样是 1:1）。 在大多数情况下，您必须使用另一个持久层来保持与数据库的交互（例如，保存对象）。 因此，您不能像使用 Active Record 实现时那样只调用 save() 方法（这是一个缺点），但另一方面，您的代码不必知道数据库中的整个关系结构即可运行，因为代码和数据库之间没有直接关系。
那么他们谁会赢得这场战斗呢？ 没有任何。 这取决于您想要实现的目标。 我相信，如果您的应用程序主要是一个 CRUD（创建、读取、更新、删除）应用程序，没有硬性和复杂的规则可应用于不同数据实体之间的关系，那么您应该使用 Active Record 实现 (Django)。 它将让您轻松快速地为您的产品设置 MVP，没有任何麻烦。 如果您的应用程序中有很多“业务规则”和限制，那么您可能更适合使用数据映射器模型，因为它不会束缚您并迫使您像 Active Record 那样严格思考。
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.
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.
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.