這些MVC圖層是否正確？

Question

我正在編寫一個使用Zend Framework的完整MVC功能幷包含服務層，域模型和映射器的Web應用程序。我認爲我對這些圖層的理解是正確的，但想確認一下。

上層依賴於下面的層中，因此從頂部開始：

1. 控制器 - 最頂層。高度依賴於實例化的View，填充和渲染。依賴服務訪問模型。

2. 查看 - 不瞭解控制器。有時候取決於服務或模型，例如填充選擇控件的查找列表。

3. 服務 - 爲客戶端（如Controller）提供API。高度依賴於模型。事實上，服務通常會在模型的映射器和域部分之間進行調解，以便爲客戶完成工作。

4. 映射器（型號，A部分） - 有域成竹在胸，操縱域對象以適應關係數據存儲和操縱關係數據來創建新的域對象。

5. 域模型（模型，部分B） - 包含域邏輯。然而，域對象並不知道其他圖層，因爲它們需要訪問其他域對象，所以它們可以作爲「對象查找器」訪問映射器。

這聽起來是對的嗎？我錯過了什麼？

Answer 1

好吧。這是有點錯誤 - ish在一些細節。

有兩個主要層在MVC：

• 模型層：與所有的域的業務邏輯，規則和信息涉及
• 表示層：涉及接口和交互

控制器是不是「最頂層」。它們是表示層的一部分，它們的職責是處理用戶的請求並傳遞提取的信息以改變模型層的狀態（通過服務）和（更罕見的）當前視圖。

我會說，那服務是模型的「C部分」。另外，我傾向於將「域對象」命名爲「域模型」或「模型對象」，因爲它會導致更多的混淆。

和域對象無法訪問數據映射器。域對象本身應該完全不知道它們是否存儲。該部分由服務處理。您可以在this answer中找到代碼/ api示例。

Answer 2

你忘了MVC的'M'，就是Model。 模型提供了您的視圖，呈現它所需的信息或您希望客戶提交的信息。控制器和視圖通過您的模型交易信息。 但重要的細節是，模型不是你的Domail模型

Answer 3

基本上，我同意你的發言，但我會更深入一點。

控制器是視圖和您的模型之間的中介。正如你所說，視圖不知道控制器，但模型也是如此。

另外，在您的模型中，正如您所提到的那樣，將服務層作爲模型的入口點也是一個好的選擇！

您必須始終保持控制器和視圖圖層可能在服務器上，而模型在另一個上。因此，您的服務充當您業務需求與業務邏輯之間的界限。它也可以處理你的交易，錯誤標準化等......實際上橫向的事情。

對於您的域名部分，我會將您的映射器部分分成2個不同的部分。因爲這是你的DAL，你可能希望創建類：

• 請求你的域對象，無論他們來自
• 檢索你的域對象，從一個特定的位置

我的意思是，你的BL向您的DAL請求一個對象，因此您要求您的存儲器將其提供給您。該存儲具有一組檢索器，如level1緩存（常規php數組），level2緩存（memcached，redis，任何內容），最後是數據庫。所以我基本上在DAL中有兩個子層：一個存儲類，它有一堆存儲和優先級，以及一個在這些存儲中獲取的實現。

不要忘記踏進你的圖層只能通過工廠，這樣它會更容易被嘲笑裏面他們你的對象，使單元測試，或每層之間添加攔截。

問候。