MVC模型應該如何抽象？

Question

我正在擴展和改進一個有很多結構問題的網站。它看起來非常像之前我聽說過MVC的開發人員，但不瞭解抽象或模塊化的想法。所以MVC的「框架」是a）定製的b）被破壞的c）補丁和d）一次使用多個。我打算解決這個問題。

這不是我第一次重建網站的框架，順便說一句，但這是我第一次修復MVC框架。不過，我正在對付SO上MVC知識中的一些漏洞。

首先是程序員看起來與他們的模型綁定了他們的SQL數據庫。這對我來說沒有意義：程序員通常有模型來看待數據抽象嗎？ （對我來說，這比將SQL放在原始PHP代碼中好一點。）或者是否有一個通常使用的「SQL」的數據訪問層？我從經驗中知道，後者意味着調用代碼不必擔心數據的位置，或者如何獲取它或如何編寫它：API處理它。

但是模型呢？他們是否打算在不同的頁面之間重複使用？他們是否應該關心數據的存儲位置？他們不應該更關心處理數據獲取和數據顯示之間的邏輯（例如，將聯繫人的組ID變爲可顯示的名稱）嗎？數據保存和數據寫入（例如弄清楚如何將$ _POST值轉換爲可保存的數據）？

也許MVC模型真的是DMVC - 數據模型 - 視圖 - 控制器。

最後，雖然這是來自PHP的觀點，但這些概念如何轉換爲JSP網站？

Answer 1

但是模型呢？他們是否打算在不同的頁面之間重複使用？

是的。

他們是否應該關心數據的存儲位置？

不，他們不需要知道。所有這些有用信息對於持久層或數據層都是必需的。

他們不應該更關心處理數據獲取和數據顯示之間的邏輯（例如將聯繫人的組ID轉換爲可顯示的名稱）嗎？

不，他們只關心業務邏輯。一些常見的應用程序，我發現人們使模型愚蠢，只有屬性/屬性，沒有別的。Java中的典型例子是POJO，帶有getter/setter。我們稱之爲TOs（傳輸對象），並將它們作爲數據持有者在任何地方使用。我不是真的有這樣的協議，國際海事組織，應該有一些方法，業務相關，這是適當的，有資格在那裏。不要讓它變得如此愚蠢。新的Entity Beans（EJB3）就是這方面的一個很好的例子。

順便說一句，數據顯示是一個表示層的工作。在Java中，JSP是視圖技術的一部分。

數據保存和數據寫入（例如找出如何將$ _POST值轉換爲可保存的數據）？

不。這通常在我們的控制器中完成，大部分時間使用一些實用程序類。

Answer 2

您會在此處找到多個線程，以瞭解是否從數據庫模式或用戶界面開始工作。有一個地方可以看。

我能想到的遠不止一種工具，它需要一個模式併爲您構建您的CRUD UI（「腳手架」），反之亦然。還有另一個地方可以看。 （海報 - 孩子：Ruby on Rails及其認知後代）。

在討論ORM工具時，當首選首字母縮略詞是「ROM」時，有太多次（但不是全部）。

我們有很多工具鼓勵我們對「準備，火，目的」的邪惡傾向。對於管理而言，這是「概念驗證」和「RC1」之間的最短線路。