這幾日因為頻繁的在網(wǎng)上看 ＭＶＣ (PHP) 和親自實作了一些腳本，還有看Laravel發(fā)現(xiàn)ＭＶＣ都是一個文件中會去找許多的ＦＵＮＣＴＩＯＮ然后甚至ＦＵＮＣＴＩＯＮ再去找ＦＵＮＣＴＩＯＮ這跟寫在同一個頁面有哪些差別？難道這樣速度不會變慢嗎？因為這樣當它讀取了這個ＦＵＮＣＴＩＯＮ腳本時（一開始的ＲＯＵＴＥＲ）然后透過這個ＲＯＵＴＥＲ再去找第二個甚至后面好幾個ＦＵＮＣＴＩＯＮ這樣它不就是會一直去找其他腳本然后最后再ＲＥＴＵＲＮ回來還是說其實這樣速度才會快？所以寧愿是幾十幾百個文件，但是每個文件里面的腳本只有十幾行、幾十行但若要完成某一個購物車功能他可能會 autoload 十幾個文件里面的ＦＵＮＣＴＩＯＮ，最后每個ＦＵＮＣＴＩＯＮ 它們ＲＥＴＵＲＮ回來才會變成一個完整購物車（包含ＶＩＥＷ）用這樣來細分，這樣執(zhí)行速度反而比較快嗎？
1 回答
拉風的咖菲貓
TA貢獻1995條經(jīng)驗 獲得超2個贊
簡單來說，引入MVC相當于一種最佳實踐，它的目的并不是快，而是要給業(yè)務做梳理建模和角色分解，約定不同的關注點，也有利于面向?qū)ο蟮脑O計。就像低級語言和高級語言的關系，理論上前者（直接寫匯編或機器碼）有可能更快，后者通過編譯會浪費一部分性能，但是高級語言大大拓寬了開發(fā)的想象力，以前可能大佬坐個飛機才寫出來的程序，現(xiàn)在找十個光頭碼農(nóng)也寫的出來，原因就在于高級語言將聚焦點更多的放在了程序邏輯而不是硬件限制上（這就解放了生產(chǎn)力）。同樣的MVC模型做的也是這個事，它是將控制器、模型和視圖相互分離，代表了最基礎的分層思想，是解決復雜問題的一個經(jīng)典策略（IT領域里有很多分層策略的體現(xiàn)，比如OSI的7層模型和TCP/IP協(xié)議棧的4層模型就是典型個例）；另外它其實也是一種約定，即任何遵從MVC模型（可能用了框架也可能沒用）搭起來的程序，你只要按照“從 控制器 獲得用戶輸入，控制 模型 變更，并引發(fā) 視圖 更新”這個流程找下去，就能大致理解程序的主要工作邏輯，所以相比大段大段的Function，MVC在組織大型程序上會更有優(yōu)勢，這就是為什么要用它的理由。
- 1 回答
- 0 關注
- 459 瀏覽
添加回答
舉報
0/150
提交
取消