Как я могу реализовать DRY в моих представлениях Django, которые делают очень похожие вещи, но для разных целей?

Я реализую проект социальной сети на Django. 2 мои модели имеют следующие поля.

class Profile(models.Model):
  user = models.OneToOneField(User...
  followers = models.ManyToManyField(Profile...

class Post(models.Model):
  owner = models.ForeignKey(Profile...
  content = models.CharField(...
  likes = models.ManyToManyField(Profile...

Теперь я создал представления add_likes, add_followers и edit_post, и они очень похожи друг на друга. Вот краткое описание того, что они делают:

add_likes

  1. Получаем JSON-объект с "target_post_id" и булевым значением "like_status" (для Like или Unlike)
  2. Проверяем валидность JSON-объекта и конвертируем его в объекты python
  3. Проверяем, выходит ли target_post
  4. Проверьте, является ли профиль пользователя не владельцем поста
  5. Добавить или удалить профиль пользователя в Post.likes на основе like_status
  6. Возврат JsonResponses на основе результата (успех или причина неудачи)

add_followers

  1. Получаем JSON-объект с "target_profile_id" и булевым значением "follow_status" (для Follow или Unfollow)
  2. Проверьте валидность JSON-объекта и преобразуйте его в объекты python
    3. .
  3. Проверьте, выходит ли целевой_профиль
  4. Проверьте, не является ли целевой профиль не собственным профилем пользователя
  5. Добавить или удалить профиль пользователя в Profile.followers на основе follow_status
  6. Возврат JsonResponses по результату (успех или причина неудачи)

edit_post

  1. Получаем JSON-объект с "target_post_id" и "new_content"
  2. Проверьте валидность JSON-объекта и преобразуйте его в объекты python
    3. .
  3. Проверьте, выходит ли целевой_пост
  4. Проверьте, является ли профиль пользователя владельцем поста
  5. Измените Post.content на основе new_content
  6. Возврат JsonResponses по результату (успех или причина неудачи)

Есть ли способ избежать создания 3 представлений, которые очень похожи друг на друга?

У меня есть несколько решений, о которых я подумал:

  1. Используем базовую модель последователей, которая имеет поля владелец (один к одному с пользователем) и последователь (много ко многим с пользователем). Профиль и пост будут наследоваться от этой модели (в случае с постом, лайки являются последователями). Модель также будет иметь свой собственный метод для обновления содержимого (шаги 3-5). Однако проблема заключается в том, что если в будущем я захочу изменить работу лайков (например, добавить неприязнь). Я также скептически отношусь к тому, не вызовет ли это проблем в моих запросах (запрос того, за чем следит мой пользователь в данный момент, даст и сообщения, и профили)

    .

  2. Использовать функцию, которая будет выполнять шаги со 2 по 5. Моя проблема в том, что в ней будет много операторов if-then или switch-cases в зависимости от содержимого JSON-объекта.

Вернуться на верх