PHP項目感悟 -- 從CI架構來看iOS的MVC

標籤：

      其實這幾天一直都想找時間把這個感悟整理出來，也是這一段一直思考的問題，因為這一段參加一個PHP後台項目的開發，架構使用的是CI，隨著項目的進展，對於CI接觸的也越多，但是由於理解的可能並不深刻，我也只是看到了我所看到的，所以如果有不對的地方，歡迎給出意見和指正。

      這幾天接觸CI架構，發現它的MVC模式運用的如此清晰簡潔，完全按照MVC的分別組織模組，而且Model、View與Controller的互動只要調用方法就可以，如果有大量互動，Controller裡的方法數量或許會增多，但也可以分模組的剝離來簡化Controller，不過，這種方法數量的增多並不會造成Controller的臃腫，因為使用者和介面相關的互動都在view中用JS動態完成，而Model的修改，controller也就是調用Model傳參，View在向controller的主動互動中好像並沒有受到限制，而目前我知道Model可以返回資料給Controller，但還不知道怎麼主動調用Controller。不過這種單一流程的簡潔性起初就已經讓我驚訝了一把。雖然MVC模式的含義在哪裡都是一樣的，但運用的不同和語言架構的不同卻會導致不同的結果和影響，比如iOS中MVC的互動裡就限制了View和Model主動向controller的互動，並不是不能，只是做了一層限制，controller可以自由調用View和Model，傳參最簡單的方式就是屬性傳值，而如果一個View有了使用者操作後想要調用controller就不會那麼容易了，不過代理可以解除這個問題，只是代理委託模式再清晰，最後互動的主體操作都是在controller裡；而Model如果又發生改變又想要congtroller做出回應，就更不容易了，KVO模式和通知的使用也可以解決，但這一層限制是避免不掉的。

      從CI來看，View層並不只是顯示，使用者互動操作留在View裡或許可以讓controller不至於那麼臃腫，而MVC下Controller的臃腫卻是iOS架構模式中一直在討論的問題，但是如果把一部分使用者操作的響應直接放在View層也會有問題，很多時候View層可以接收使用者操作，但如果不和Model溝通是無法響應的，還是避免不掉通過controller，那麼到底應該從哪裡入手呢，我最後的想法是，應該是Model，也許Model並不是只能作為一個資料內容的展示，如果給它必要的方法，也許可以協助Controller分擔一部分的工作，但這畢竟是有限的。

       其實我以前也一直認為iOS裡如果將controller的內容進行模組劃分，是可以降低controller的冗餘的，如果現在再給Model分擔一部分內容，冗餘程度會更低一些，但是終究是無法達到CI的這樣簡潔，而因為對controller冗餘問題的討論也誕生了MVVM，只是我對這種模式的運用並不能很熟練，只是知道大概是怎麼個情況，而且目前的MVVM模式也不像MVC那麼的成熟，精簡controller估計會是要一直進行的一個討論了。

PHP項目感悟 -- 從CI架構來看iOS的MVC