如果把業務邏輯在Django

例如，帳戶1 - > *用戶 - > 1個認證 1帳戶有多個用戶和每個用戶都將有1個認證如果把業務邏輯在Django

我來自Java的背景，因此我通常做的是

定義這些類如Java豆（即只getter和setter，沒有邏輯連接）
創建的AccountManager EJB類，定義CREATE_ACCOUNT方法（有需要1個帳戶，用戶列表）
在網絡層準備數據，然後將數據傳遞到的AccountManager EJB，例如： accountManager.createAccount(account, userList)

但在Django中，框架的倡導者，你把域邏輯分爲模型類（行級）或相關管理類（表級），這使事情有點尷尬。是的，如果你的邏輯只涉及一張表，但在實際應用中，通常每一步都會涉及多個不同的表甚至數據庫，那麼在這種情況下我應該怎麼做？

將邏輯放入視圖？我認爲這根本不是好習慣。甚至覆蓋模型類中的save方法，通過使用** kwargs傳遞額外的數據？那麼後端將會中斷。

我希望這說明我的業務邏輯應放在django應用程序中的位置。

2011-04-11 devharb

那麼上面用accountManager.createAccount（account，userList）舉例說明的例子看起來像是我可以輕鬆完成的一項工作，即向帳戶模型添加createAccount方法。如果您覺得需要將業務邏輯放在模型外部，儘管您總是可以創建一個託管業務邏輯的新模塊，然後導入並用於視圖中。

來源

2011-04-11 04:36:59 solartic

不確定您是否已閱讀Django中的Managers部分，它似乎解決了您當前的情況。假設您定義了以下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)

業務邏輯仍在模型中。

編輯

這裏的關鍵詞是覆蓋，不覆蓋。如果您重寫模型的保存方法，則必須記住，您的Web應用程序和管理員中的任何創建，更新操作都將使用此新功能。如果您只希望在特定視圖中發生這些業務邏輯，最好將其保留在save之外。

我想你可以把你的業務邏輯放在自己的普通班上。每次需要運行業務邏輯時，都必須實例化該類。或者，你可以把你的業務邏輯爲靜態函數在這個新的類，如果你想跳過OOP方法。

來源

2011-04-11 05:01:24

嗨亨利，你認爲覆蓋保存方法是好主意嗎？另外。不是經理對象應該更關注表級邏輯嗎？（只是好奇，因爲現在我非常相信你的方法） – devharb 2011-04-11 06:53:54

查看編輯答案。 – 2011-04-11 14:29:15

我在做什麼是我的大部分應用都service.py文件與業務邏輯。這是因爲，如果我需要的是高配車型的作品從多個應用程序的功能我根本無法做到這一點：

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

該代碼會被卡在循環引用循環。

但我要招最有可能從service.py與結構像這樣應用程序：

service/ 
    auth.py 
    customers.py 
    another_set_of_functions.py 
    ...

來源

2013-06-06 08:22:21 SummerBreeze

如果把業務邏輯在Django

回答

相關問題