Создание повторно используемых приложений Django? - PullRequest
Новая
       13

Создание повторно используемых приложений Django?

12 голосов
/ 11 мая 2011

Я в некотором роде новичок в Django и стараюсь максимально разделить мои приложения и собрать как можно меньше повторяющихся фрагментов. Пытаясь следовать стратегии Джеймса Беннетта по созданию повторно используемых приложений . Имея это в виду, я столкнулся с этой проблемой.

Допустим, у меня было приложение, которое хранит информацию о фильмах:

Код будет выглядеть примерно так: 

class Movie(models.Model):
    name = models.CharField(max_length=255)
    ...

Теперь, если бы я хотел добавить оценки, я мог бы использовать django-rating и просто добавить поле в свою модель: 

class Movie(models.Model):
    name = models.CharField(max_length=255)
    rating = RatingField(range=5)
    ...

Это по сути означает, что мое приложение Movie теперь зависит от django-рейтингов, и если бы я хотел использовать его повторно, но больше не нуждалось в рейтингах, мне все равно пришлось бы устанавливать django-рейтинги или модифицировать и отключать мое приложение.

Теперь я мог бы обойти это, используя try / кроме с import и определив поле в случае успеха, но теперь мое приложение для фильмов явно привязано к рейтингу в определении таблицы базы данных.

Кажется, гораздо разумнее разделить две модели и определить отношения в модели рейтингов, а не в фильме. Таким образом, зависимость определяется при использовании рейтинга, но не требуется при использовании приложения «Фильм».

Как вы справляетесь с этой проблемой? Есть ли лучший подход для разделения моделей?

Мне также интересно, есть ли какие-либо серьезные потери производительности при этом.

edit: Я хочу уточнить, что это скорее пример проблемы и несколько надуманный, чтобы проиллюстрировать точку зрения. Я хочу иметь возможность добавлять дополнительную информацию без изменения модели «Кино» каждый раз, когда мне нужно добавить связанные данные. Я ценю ответы до сих пор.

Ответы [ 3 ]

4 голосов
/ 11 мая 2011

В этом случае лично я бы все упростил и просто оставил rating на модели. Вы должны сбалансировать повторное использование с простотой реализации. Здорово делать вещи многоразовыми, но действительно ли ваша модель Movie достаточно полезна для дополнительной работы? И так ли плохо иметь зависимость? Я думаю, что многие из этих дизайнерских решений субъективны. В этом году на PyCon была хорошая беседа на эту тему: http://blip.tv/file/4882961

1 голос
/ 11 мая 2011

Во-первых, я согласен с Zeekay выше, вы должны проанализировать, стоит ли это количество повторного использования для вашей модели.

Если это действительно так, вы можете создать новое movierating приложение, котороеимеет RatingModel с FK на movies.models.Movie и поле rating.

Тем не менее, rating каким-либо образом будет передано в шаблоны.Для этого вы можете создать представления на основе классов , а в movierating.views вы можете расширить и переопределить метод get_context.

Не забывайте достижение возможности повторного использования - это фундаментальное оценочное суждение , которое должен сделать разработчик, и чрезмерное его выполнение может быть таким же плохим, как и отсутствие его вначале.

0 голосов
/ 11 мая 2011

Наличие зависимостей не обязательно плохо. Для чего-то вроде поля (рейтинг, таймделта, объект JSON), где нет встроенного поля, которое делает то, что вам нужно, необходимо включить отдельное приложение, которое обрабатывает это (и, возможно, некоторые связанные функции, такие как теги шаблона), является функцией, не ошибка.

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

...