dev*_*arb 17 django transactions business-logic django-models django-admin
例如,帐户1 - >*用户 - > 1身份验证 1帐户有多个用户,每个用户将拥有1个身份验证
我来自java背景,所以我通常做的是
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方法,可以将业务逻辑作为静态函数放在此新类中.
上面用 accountManager.createAccount(account, userList) 举例说明的示例似乎可以通过向帐户模型添加 createAccount 方法轻松完成。如果您觉得需要将业务逻辑置于模型之外,那么您始终可以创建一个托管业务逻辑的新模块,然后在视图中导入并使用。
| 归档时间: |
|
| 查看次数: |
6643 次 |
| 最近记录: |