CodeIgniter /胖模型/瘦控制器

Question

今天，我了解到擁有胖模型和瘦控制器被認為是一種好習慣。 到現在為止，我已經有了相反的看法，所以我相信我對MVC的所有理解都被證明是錯誤的。

大多數文章指出胖模型/瘦控制器方法更好，而我看到的主要原因是他們聲稱控制器不可重用。 對於CodeIgniter的標准安裝而言，這是正確的，但是當使用Wiredesignz的HMVC插件之類的插件時，這將成為非問題。 簡而言之，問題是：

具體來說，對Code Igniter使用哪種最佳方法是什么？

1. 胖模型/瘦控制器
2. 帶有HMVC插件的Fat控制器/ Skinny模型
3. 不帶HMVC插件的胖控制器/瘦模型

我不再考慮不帶HMVC插件的胖控制器/瘦模型作為選項，而是將其包括在內以確保完整性。

請問您的想法？ HMVC插件是否是一件邪惡的事情？

Answer 1

您很正確，因為分成模塊確實可以消除使用SC / FM的某些原因。 但是，出於以下幾個原因，它仍然是一種好的做法：

1） 代碼的可重用性正如您所說的那樣，模型應該是可重用的，可以使可重用的代碼越多越好。 是的，我知道模塊也可以做到這一點，但是模塊的重點更多是代碼的隔離和可移植性，您仍然可能希望在以后的階段擴展這些控制器，以SC / FM的方式工作將在那時幫助您。

2） 代碼的可讀性閱讀代碼時，大多數人將從路由配置開始，然后轉到相應的控制器。 骨瘦如柴的控制器擔當導演的角色，應該簡潔明了。 只是調用更復雜和冗長的代碼。 更少的代碼更易於遵循。

3） 在羅馬時 ，不容忽視的是，每個使用MVC框架的人都以這種方式工作，這意味着您也應該以這種方式工作，很高興能有所不同，但是如果您在同一團隊中有5個人一起工作誰都想與眾不同這只是一個痛苦。

您應該重寫代碼嗎？

可能不是馬上，我確定您還有更好的事情要做。 如果您從現在開始嘗試以這種思維方式思考，在某個時候，您將回顧您的舊代碼並進行更改（可能是在您在那里進行任何更改時），但是現在看來，如果這還沒有結束。 。

此外，以模塊化的方式進行工作並不像看起來那樣簡單，制作真正可重用的模塊化代碼並不容易，並且與為單個站點進行快速而骯臟的代碼相比，實際上需要大量的開銷。 在重新編寫代碼之前開始練習可能會更好，直到您對將現有代碼轉換為真正的模塊化所需的知識有了充分的了解-這是時候整理一下胖控制器了。

在為特定站點編寫新代碼時，我始終牢記我以后可能想在另一個站點上重用它，但是如果我試圖使所有選項在陽光下都可重用，那么我將一事無成。 最好在時間到時去調整它。

關於HMVC的觀點我會說實話，我真的不知道HMVC的含義是什么，但是模塊是切成薄片以來最好的東西，因為我偶然發現HMVC wiredesignz，所以我現在要做的工作少得多了，而用於很多網站的工作卻很多更重要的是，我花更少的時間做同一件事...您想要在您的站點上提供畫廊。 這是圖庫管理器模塊，Cms，您說，是的，有cms模塊，產品，是的有product模塊。 我現在在一個框架而不是數百個不同的站點上有很多變體。

摘要

您現在可能正在處理簡單的模塊，這意味着代碼可重用性和清晰度不是這些模塊內的主要問題。 但是，今天就從良好的實踐開始編碼。 而且，當您處理一些龐大的CMS或產品模塊時，您會感到很高興。

請查看此內容，以獲取有關應該去哪里的指南，該如何在MVC中構建模型？

Answer 2

好吧，我對HMVC不滿意，但是我已經與Codeigniter一起工作了很長時間，我可以為您提供關於胖模型的建議，並且瘦控制器在涉及以下方面是一個好習慣：

1. 后端和前端訪問相同的模型
2. 創建自己的API與其他應用程序接口，以便您重復使用相同的胖模型

但是，我查看了HMVC文檔，看來這實際上取決於您如何分配邏輯以及此模塊化組件如何共享相同的數據資源。

這取決於您正在從事的項目