Где поставить бизнес-логику в Джанго - PullRequest
Новая
       7

Где поставить бизнес-логику в Джанго

17 голосов
/ 11 апреля 2011

Например, Учетная запись 1 -> * Пользователь -> 1 Аутентификация 1 учетная запись имеет несколько пользователей, и у каждого пользователя будет 1 аутентификация

Я пришел из java фоне, так что яобычно это

  1. определение этих классов как Java-бинов (т. е. просто getter и setter, без логики)
  2. create AccountManager ejb class, определение метода create_account (with принимает 1 счетсписок пользователей)
  3. подготовка данных в веб-слое, а затем передача данных в AccountManager ejb, например: accountManager.createAccount(account, userList)

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

Поместителогика в View?Я не думаю, что это хорошая практика вообще.или даже перезаписать метод save в классе модели, передавая дополнительные данные с помощью ** kwargs?тогда бэкэнд сломается.

Надеюсь, это иллюстрирует мою путаницу с тем, где следует размещать бизнес-логику в приложении django.

Ответы [ 3 ]

13 голосов
/ 11 апреля 2011

Не уверен, что если вы прочитали раздел Managers в Django, похоже, это решает вашу текущую ситуацию. При условии, что у вас определена следующая модель Account, User является встроенной. 

# accounts/models.py

class AccountManager(models.Manager):
    def create_account(self, account, user_list):
        ...

class Account(models.Model):
    objects = AccountManager()

Не стесняйтесь разделять код менеджера в отдельном файле, если он становится слишком большим. По вашему мнению: 

# views.py

from accounts.models import Account

Account.objects.create_account(account, user_list)

Бизнес-логика все еще находится в моделях.

EDIT

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

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

3 голосов
/ 06 июня 2013

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

# shop/models.py
from auth.models import User, Team

Этот код застрянет в циклическом цикле ссылки.

Но я скорее всего перейду с service.py на приложение со структурой, подобной этой: 

service/
    auth.py
    customers.py
    another_set_of_functions.py
    ...
0 голосов
/ 11 апреля 2011

Что ж, пример, который вы проиллюстрировали выше с accountManager.createAccount (account, userList), выглядит как нечто, что можно легко сделать, добавив метод createAccount в модель аккаунта. Если вы чувствуете необходимость вывести бизнес-логику за пределы модели, вы всегда можете просто создать новый модуль, содержащий вашу бизнес-логику, а затем импортировать и использовать в ваших представлениях.

...