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

#python #django #reusability

#python #django #возможность повторного использования

Вопрос:

Я в некотором роде новичок в 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)
    ...
  

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

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

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

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

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

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

Ответ №1:

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

Ответ №2:

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

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

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

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

Ответ №3:

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

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