在django中放置业务逻辑的位置

dev*_*arb 17 django transactions business-logic django-models django-admin

例如,帐户1 - >*用户 - > 1身份验证 1帐户有多个用户,每个用户将拥有1个身份验证

我来自java背景,所以我通常做的是

  1. 将这些类定义为java bean(即,只是getter和setter,没有附加逻辑)
  2. 创建AccountManager ejb类,定义create_account方法(带1个帐号,用户列表)
  3. 准备Web层中的数据,然后将数据传递到AccountManager ejb,例如: accountManager.createAccount(account, userList)

但是在django中,框架主张将域逻辑放入模型类(行级)或关联的管理器类(表级),这使得事情有点尴尬.是的,这是好的,如果你的逻辑是只涉及一个表,但在实际应用中,通常每一步都会涉及多个不同的表,甚至数据库,所以我应该在这种情况下怎么办?

将逻辑放入View中?我认为这根本不是好的做法.甚至覆盖模型类中的save方法,使用**kwargs传入额外的数据?然后后端会破裂.

我希望这说明我对业务逻辑放在django应用程序中的位置感到困惑.

Thi*_*Lam 13

不确定你是否已阅读Django中关于Managers的部分,它似乎解决了你目前的情况.假设您Account定义了以下模型,User则内置.

# accounts/models.py

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

class Account(models.Model):
    objects = AccountManager()
Run Code Online (Sandbox Code Playgroud)

如果管理器代码太大,请随意将其分隔在单独的文件中.在您的观点中:

# views.py

from accounts.models import Account

Account.objects.create_account(account, user_list)
Run Code Online (Sandbox Code Playgroud)

业务逻辑仍在模型中.

编辑

这里的关键字是覆盖,而不是覆盖.如果您覆盖模型的保存方法,则必须记住,Web应用程序和管理员中的任何创建,更新操作都将使用此新功能.如果您只希望这些业务逻辑在特定视图中发生一次,那么最好将其排除在外save.

我想你可以将你的业务逻辑放在自己的常规类中.每次需要运行业务逻辑时,都必须实例化该类.或者,如果要跳过OOP方法,可以将业务逻辑作为静态函数放在此新类中.


sol*_*tic 0

上面用 accountManager.createAccount(account, userList) 举例说明的示例似乎可以通过向帐户模型添加 createAccount 方法轻松完成。如果您觉得需要将业务逻辑置于模型之外,那么您始终可以创建一个托管业务逻辑的新模块,然后在视图中导入并使用。