Question

我见过这样的重复例子：

from google.appengine.ext import db
import datetime

class Book(db.Expando):
    pass

obj = Book()
obj.title = 'The Grapes of Wrath'
obj.author = 'John Steinbeck'
obj.copyright_year = 1939
obj.author_birthdate = datetime.date(1902, 2, 27)

obj.put()

这是我第一次遇到这种代码，其中属性设置在类定义的之外。这让我觉得非常糟糕。我更喜欢：

class Book(db.Model):
    title = db.StringProperty()
    author = db.StringProperty()
    copyright_year = db.IntegerProperty()
    author_birthdate = db.DateProperty()

...
    obj = Book(title='The Grapes of Wrath', author='John Steinbeck', copyright_year=1939, author_birthdate=datetime.date(1902, 2, 27))

有人可以对作者的实践性质提供保证吗？何时何地可以接受这种方法？

有人提到谷歌的数据存储模型允许不同寻常的灵活性。我认为这个例子对于这个概念可能是一个糟糕且过于微妙的介绍。作者实际上已经指出了这种风格的缺点，然后继续重复它。所以，它可能会有一些优势。

Answer 1

记录在案here。提供的代码段是有效的，但不清楚为什么该类完全为空（可能是出于说明目的）。我想主要的问题是何时使用Expando模型？

想象一下，网站收集各种商品的订单。一个顾客可能想要订购一只小猫，另一个可能想要订购一本书等。一本书和一只小猫几乎没有共同之处，可能只是价格和重量。但我们希望我们的客户提供有关其虹膜的详细信息，例如一个顾客可能会订购3个月大的小猫，暹罗，蓝眼睛，另一个可能订购“指环王”第2版，精装本，作者签名等。虽然这些属性在收集订单时无关紧要，它们对您的业务逻辑至关重要。您也可以稍后处理这些属性。

这里唯一的解决方案是使用Expando模型，因为您无法创建覆盖所有现有属性的通用类（或类的层次结构）。 Expando模型将包含所有一般属性（价格，重量，跟踪ID，运输成本，定制费用等）和方法（计算总数，折扣等），其余属性将由客户动态创建在运行时。模型实例将以其所有属性保存到数据存储区中，任何特定实例都将通过Model.properties（）方法返回在其上定义的所有属性。

Answer 2

这很有趣。我读了同一本书并想到了同样的事情。我一直在使用App Engine Python，因为它推出并且从不使用Expando模型。

我认为作者的意图是将可能不熟悉Python类的读者简化为定义模型的概念，但我觉得它没有用。

有一次，数据存储区的灵活性对我来说很方便，就是当我将一个模型中的一个字段从使用DateTime切换到使用自定义String属性时。具有两种类型字段的实体可以并排生存，并且我可以在访问每个实体时迁移它们。

在python / google app引擎中定义对象/实体的属性

2 个答案: