2012-10-20 33 views
1

我有一個關於我的應用程序碰到的衝突/難題的問題。基本類的問題被模型和控制器擴展

我想給我的所有模型和控制器提供一些常用的「東西」,比如來自緩存的數據或會話信息,以及我的PDO包裝器的方法。

當前,每個單獨的特徵控制器和特徵模型都擴展了一個基礎控制器和基礎模型,該基礎控制器和基礎模型又擴展了一個可以完成所有常見工作的單個對象。

控制器將被路由器/調度程序調用,然後控制器將調用模型來獲取一些數據。與此相關的問題是這意味着主對象被構造兩次:一次調用功能控制器時,一次當功能控制器調用特徵模型時。

見下圖:

How my MVC app is currently structured

很顯然,我做錯了什麼,所以我想知道是否有某種最佳實踐的解決了這個問題。

什麼我想要的是必須通過控制器將對象加載到模型的東西。這意味着任何時候我必須爲Object添加一個新的通用元素,我必須將其傳遞給Model。

$ this-> cache或$ this-> db或$ this-> session在控制器和模型(以及未來的助手和misc類)中總是可用,這是非常簡單和容易的。

我該如何解決這個問題?

謝謝:)

回答

0

,我認爲你是在解決這個問題上錯誤的道路會。 如果你正在構建一個MVC應用程序,你應該分開關注,這就是爲什麼我們使用MVC。分離模型,控制器和視圖。

您應該定義您需要做什麼的模型,Controller將執行的操作,並將View僅用於表示邏輯。

在正確的MVC中,Model是一個處理業務邏輯,數據庫訪問,驗證等的層。因此Model不是一個類。你可以在一個控制器中使用很多模型。而控制器就是......模型和視圖之間的連接。模型應該很胖,控制器應該很輕。

你這樣做的方式在我看來是錯誤的,因爲你可以在模型和控制器中做同樣的事情,這不是MVC的目的。控制器不應該做任何邏輯,這就是爲什麼我們使用模型,控制器只告訴模型要做什麼,根據他們的反應,我們告訴其他模型做其他事情,或者使用成功或錯誤消息或數據庫中的帖子渲染View。

您可以這樣做的方式是一旦您調用適當的控制器,就可以使用它來獲取所需的模型。再次,模型由許多類組成,因此您的模型文件夾可能很胖。從Controller中,您應該只有訪問模型的方法,以便模型可以執行一些操作,並向Controller回報他們做了什麼。根據返回的值,您可以執行更多操作或調用View來渲染。

所以你不應該有一個對象可以被模型和控制器擴展。

你的模型文件夾可以是這樣的:

Models 
    - Entities 
    - Forms 
    - Validators 
    - Services 
    ... 

然後調用其中的任何在你的控制器做一些動作,並彙報。 如果你真的需要在控制器和模型中都具有相同的功能,那麼這並不能回答你的問題,但我認爲它是錯誤的,就像你開始做的那樣。

希望這可以幫助你,有趣的問題如果我可以嘗試幫助更多。

0

我有一種感覺,你的問題的根源是糟糕的建築。

您必須瞭解的關於MVC和MVC設計模式的主要內容是該模式由兩個層構成:後面的介紹和模型層。這些圖層不應共享通用功能。控制器(以及視圖和模板)是表示層的一部分。

當控制器中有像$this->cache$this->db$this->session這樣的變量時,這意味着您有嚴重的抽象泄漏。這些是存儲結構,應該在模型層中隱藏得相當深。如果您的控制器直接與它們進行交互,則您沒有控制器。

接下來的問題是您的基類(由於某種原因您稱爲Object ..而對象類別是類的實例)。它似乎負責很多,特別是與存儲交互的不同抽象的實例化。如果你的控制器需要一個PDO實例(對於一些異常奇怪的原因),那麼它應該被注入到構造函數中。緩存和會話管理也一樣。

然後就是那個小東西,模型不是一個對象或類。它是一個圖層。就像表示層一樣,它由不同類型的結構組成。通常的建議是有:

  • 結構與邏輯實體處理,這就是通常domain objects
  • 一種或多種類型的存儲抽象:​​,repositoryunit of workdao和/或一些類似結構。
  • 的東西,控制上述結構之間的相互作用,使它們不會在表示層泄漏,通常稱爲services

是的,你是正確的假設,使用控制器沿結構傳遞是一個不好的做法。它違反了LoD。相反,你應該爲你的控制器提供一個工廠,它實例化你的模型層結構併爲它們提供必要的依賴關係。this post可能會有所幫助。

我的兩分錢就這個問題..對於更精確的建議,您將不得不顯示一些代碼