在MVC（例如Django）中，放置沉重邏輯的最佳位置是什麼？

Question

在MVC架構讓我們考慮Django：

我有一種方法來計算年度最佳員工（1000行代碼與複雜的邏輯），我應該在哪裏定義它，誰會調用它？

感謝

Answer 1

從Django docs

增加額外的manager方法是添加「表級」 功能添加到您模型 首選方式。

1. 創建與邏輯模塊（year_employee.py）

2. 比方說你有一個模型Employee，所以，你應該爲員工管理打造一​​流：

   class EmployeeManager(models.Manager) 
       def of_the_year(self): 
        from year_employee import my_calc_func 
        return my_calc_func() 
   

然後將此管理員添加到您的模型中

class Employee(models.Model): 
    [...] 
    objects = EmployeeManager() 

之後，你可以簡單地這樣做：

chosen_employee = Employee.objects.of_the_year() 

Answer 2

1. 把邏輯視圖不會允許 您可以輕鬆地編寫單元測試和 不能重用effectively.This說 ，你不應該把 複雜的邏輯視圖中的你應該 將其與視圖分開。
2. 如果邏輯與 （類的類/對象）緊密相關，那麼將 模型中的邏輯有意義。
3. 萬一邏輯密切相關 多個對象/類，您可以使用該模型的 一個把邏輯或你 可以創建一個服務對象（或者代碼過於龐大），這 將處理這一邏輯。

Answer 3

至於django，把商業邏輯放在模型的最佳位置。該視圖應該從業務邏輯中清除乾淨，並且只應該用於獲取要在模板上顯示/呈現的數據，或者換句話說，僅將視圖用於視圖邏輯。

從django FAQ：

在我們的MVC的解釋， 「視圖」描述得呈現給用戶 數據。這不是 必然如何數據看起來，但 哪些數據是呈現。視圖 描述您看到哪些數據，而不是您看到的數據如何 。這是一個微妙的區別。

通過將您的業務邏輯置於模型下，它將引導您更輕鬆地進行單元測試，因爲模型不與HTTP方法或處理耦合。

Answer 4

關於您的具體示例「一種計算年度最佳員工（1000行代碼和複雜邏輯）的方法......我應該在哪裏定義它，誰將調用它？」

對於那麼多的代碼，我可能會創建一個新的模塊（可能是ranking.py）並放在那裏。誰來調用它取決於你如何使用它，但我猜想它會從你的一個觀點調用。

Answer 5

我同意那些認爲這樣的邏輯應該放在models.py文件中的人。然而，與你擁有的一樣大的東西，超過1k行代碼，會開始混亂models.py文件[對我]。我傾向於將這些代碼放在給定應用程序中的單獨文件中。這樣做沒有害處。

Answer 6

這是一個自定義應用程序？如果是從視圖中提取業務邏輯並不是完全可能的。有時你必須將其放在那裏，原因很多，其中之一就是可維護性。

除此之外，在99.9％的情況下，計算應該在UI之外。

Answer 7

從您輸入：

限定了用於保持方法/類具有複雜算法和邏輯單獨的模塊「services.py」。我們可以做的最好的方法是調用模型中的一個方法，這個方法在內部調用服務模塊中的邏輯，使用模型數據來完成處理並返回結果寫入響應。

感謝您的回覆。

Answer 8

我試圖遵循"skinny controller, fat model"的概念（鏈接特定於Rails，但這個概念仍然適用）。你的控制器根本不應該有太多的代碼，除了處理會話，cookies，表單等。你的應用程序的所有實際邏輯都應該駐留在你的模型中，這樣以後可以更容易地進行測試和重構。