業務邏輯應該與模型分開嗎？

Question

我們正在開發一個代碼量很大的PHP5項目，並且在上週我開發了一個RESTful API的PoC。我們正在將模型類與業務類分離。

試圖實現CRUD功能，我發現，直接對模型實施CRUD將是非常直接的，而針對業務邏輯實施它卻不是，因爲它的功能特定於當前存在的視圖及其界面沒有提供我實施API所需的通用數據訪問模型。

想到這裏，下面的問題來到我的腦海：

• 什麼是與數據進行交互的最佳方式，保持模型和保持模型沒有按」功能的靈活性現在不在乎（比如在更改電子郵件地址時發送帶有激活鏈接的郵件）？

• 以前用django工作過很多，其中大多數業務邏輯都是在模型中實現的，爲什麼要保持業務邏輯分離？你有沒有現實生活中的例子？這有什麼問題解決，如果有的話？

一些可能的解決方案來我的腦海裏，太：

• 把整個業務邏輯到模型中。在調用save方法之後/之前檢查哪些字段已更改。
• 使用觀察者模式通知業務對象模型中的變化並直接與模型進行交互。

你認爲什麼是正反兩面，你會怎麼做？

Answer 1

如果分離出來的數據存儲你的模型，你想要的分離和功能的數據訪問層：

DAL (doing queries etc) 
    | 
Model (doing business) 
    | 
Controller 
    | 
View 

所以在視圖中，您有一個動作：標記爲付費。因此，您的控制器獲取請求（POST）/ invoice/1/markaspaid（或您使用的任何其他url結構）。然後控制器調用模型：

$Invoice=new Invoice(); 
$Invoice->markAsPaid(1); 

然後您的模型調用DAL實際存儲此更改。沒有必要將這與模型分開。如果它非常複雜或非常事務性，您可能會考慮針對複雜任務的單獨服務。這樣，你的模型變得更薄，複雜的部分分離。

什麼是與數據進行交互的最佳方式，保持 彈性模型和保持功能 不會在此刻關心的（如發送郵件與 激活鏈接時模型改變電子郵件地址）？

我完全不明白這一點。據我所見，你應該將發送的電子郵件過程與普通的代碼運行分開。所以把它放在隊列中並在那裏找到它。它不是你正常代碼路徑的一部分。你可以從你的模型啓動它，但就是這樣。

看到這個問題，其中有關於該主題的相關信息： Cakephp cron job to call a controller's action