Определение атрибутов для объектов / сущностей в python / google app engine - PullRequest
Новая
       14

Определение атрибутов для объектов / сущностей в python / google app engine

2 голосов
/ 04 марта 2011

Я видел многократные примеры, подобные этому: 

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))

Может ли кто-нибудь предложить уверенность в характере авторской практики? Где и когда такой метод будет приемлем?

Было упомянуто, что модель Google для хранения данных допускает необычайную гибкость. Я подумал, что этот пример может быть плохим и слишком тонким введением в эту концепцию. Автор фактически указал на недостатки этого стиля, но продолжает повторять его. Так что в этом может быть какое-то преимущество.

Ответы [ 2 ]

3 голосов
/ 04 марта 2011

Это задокументировано здесь .Предоставленный фрагмент действителен, хотя не ясно, почему класс полностью пустой (может быть для иллюстративных целей).Я предполагаю, что главный вопрос когда использовать Expando Model ?

Представьте себе сайт, собирающий заказы на все возможные виды товаров.Один клиент может захотеть заказать котенка, другой - заказать книгу и т. Д. Книги и котенок имеют очень мало общего, может быть, только цена и вес.Но мы хотим, чтобы наши клиенты предоставили подробную информацию о своих пользователях, например, один клиент мог бы заказать котенка 3 месяца, сиамского, голубоглазого, а другой мог бы заказать «Властелин колец», 2-е издание, твердый переплет, подпись автора и т. Д. Хотя этиНа момент получения заказа свойства не имеют значения, они важны для вашей бизнес-логики.Также вы можете обработать эти свойства позже.

Единственным решением здесь является использование модели Expando, поскольку вы не можете создать универсальный класс (или иерархию классов), охватывающий все существующие свойства.Модель Expando будет содержать все общие свойства (цена, вес, идентификатор отслеживания, стоимость доставки, таможенные сборы и т. Д.) И методы (расчет итога, скидки и т. Д.), Остальные свойства будут создаваться клиентом динамически.во время выполнения.Экземпляр модели будет сохранен в хранилище данных со всеми его свойствами, и любой конкретный экземпляр вернет все свойства, определенные для него с помощью метода Model.properties ().

2 голосов
/ 04 марта 2011

Забавно. Я читал ту же книгу и думал то же самое. Я использую App Engine Python с момента его запуска и НИКОГДА не использую модели Expando.

Я думаю, что цель автора состояла в том, чтобы облегчить читателям, которые могут быть не знакомы с классами Python, концепцию определения моделей, но я не нашел это полезным.

Однажды гибкость хранилища данных мне пригодилась, когда я переключил поле в одной из моих моделей с использования DateTime на использование пользовательского свойства String. Объекты с полями обоих типов могут жить бок о бок, и я мог переносить их при каждом доступе.

...