Методы в моделях - PullRequest
Новая
       7

Методы в моделях

0 голосов
/ 03 ноября 2011

Это моя первая попытка построить веб-сервис json с использованием фреймворка Tornado , и у меня возник вопрос по поводу дизайна моделей.

В настоящее время у меня есть файл модели (models.py)со всеми моими моделями, которые представляют мои объекты, как это (это логическое представление) 

class person():
  name = StringField()
  age  = IntField()

class phone():
  number = IntField()
  person = ReferenceField(Person)

Потому что у меня есть много методов для реализации, как person.is_granted (), person.is_admin () (например,Мне было интересно, как лучше всего (в дизайне приложения) объявлять методы в объекте theses, следует ли мне их расширять?или можно объявить методы в определении файла модели?

Спасибо за ваши ответы.

1 Ответ

0 голосов
/ 06 ноября 2011

Как правило, вы хотели бы иметь общего предка (с точки зрения наследования) для всех ваших моделей, где вы применяете общие методы для всех них.Обычно это будет обработка сериализации / десериализации, абстракция API базы данных, поиск, контроль доступа и так далее.ORM почти всегда предоставляют такого предка, но иногда его необходимо расширять с помощью логики, специфичной для приложения.

Хорошей практикой является помещение метода, связанного с моделями, в их объекты, особенно если эту логику следует использовать в разныхобработчики (такие как проверка, изменение и генерация пароля для пользовательской модели - их можно использовать из множества связанных с аутентификацией обработчиков, и модель является хорошим местом для размещения этой логики).Между тем такие вещи, как is_admin () , где вы проверяете, содержит ли какой-либо другой атрибут (например, роли) определенное значение, могут быть помещены в декоратор @ property , чтобы они выглядели как обычный логический атрибут.

Используя этот подход, вы отделяете логику, специфичную для данных, от логики, специфичной для приложения, в своем коде, чтобы вы могли разумно распределить ее между этими двумя модулями.По мере развития проекта вы захотите перейти от handlers.py и models.py к пакетам обработчиков и моделей с кучей подмодулей, чтобы разделить различные части приложения и сделать код более читабельным.

PS: кстати, это действительно не имеет никакого отношения к Tornado или даже к ORM, например, я использую компоновку кода, подобную этой, с простым API базы данных

...