這幾天寫了 MVC 後產生的邏輯問題？

php mvc oop 框架 laravel

火爆浪子 2018-12-02 13:33:51 ‧ 3125 瀏覽

分享至

這幾日因為頻繁的在網上看ＭＶＣ (PHP) 和親自實作了一些腳本，還有看Laravel
發現ＭＶＣ都是一個文件中會去找許多的ＦＵＮＣＴＩＯＮ
然後甚至ＦＵＮＣＴＩＯＮ再去找ＦＵＮＣＴＩＯＮ
這跟寫在同一個頁面有哪些差別？
難道這樣速度不會變慢嗎？

因為這樣當它讀取了這個ＦＵＮＣＴＩＯＮ腳本時（一開始的ＲＯＵＴＥＲ）
然後透過這個ＲＯＵＴＥＲ再去找第二個甚至後面好幾個ＦＵＮＣＴＩＯＮ
這樣它不就是會一直去找其他腳本然後最後再ＲＥＴＵＲＮ回來
還是說其實這樣速度才會快？

所以寧願是幾十幾百個文件，但是每個文件裡面的腳本只有十幾行、幾十行
但若要完成某一個購物車功能他可能會 autoload 十幾個文件裡面的ＦＵＮＣＴＩＯＮ，最後每個ＦＵＮＣＴＩＯＮ它們ＲＥＴＵＲＮ回來才會變成一個完整購物車（包含ＶＩＥＷ）
用這樣來細分，這樣執行速度反而比較快嗎？

看更多先前的討論...收起先前的討論...

工程良田的小球場 iT邦新手 5 級 ‧ 2018-12-02 15:32:03 檢舉

如果以絕對效能來講的確會比較慢(畢竟多call了很多層)，
但以現在電腦的配備而言時間差異應該幾近於無感(毫秒間)，
至於為什麼要分那麼多層這個問題，
如果以大型專案而言，
如果全部的程式碼都擠在一起不分類的話，
會讓後續的Code較不易維護。

火爆浪子 iT邦研究生 1 級 ‧ 2018-12-02 18:01:37 檢舉

也就是說分越細越好，但是代價就是會變慢

Sam-物理拳頭系工程師(五段) iT邦高手 9 級 ‧ 2018-12-02 18:44:44 檢舉

代價也許是這樣的：
你本來可以容納1萬人在線，變成可能只能容納5000人。因為效能大家一起拖。

但是如果變成5000人的代價是你要改功能只要1個小時不到。
跟如果維持原本的10000人你改個功能要花2個星期才找得到bug。
你怎麼選擇？
正常公司的選擇會是：再開一台主機就可以拉回10000人啦。
雖然多花了一點主機費卻省下了極大量的維護成本。

Sam-物理拳頭系工程師(五段) iT邦高手 9 級 ‧ 2018-12-02 18:49:03 檢舉

你要思考的事情我覺得都不是在這樣的事情上。
一個點：假如你所提出的疑慮真的是個疑慮……那為什麼絕大多數的人還是會做出讓你產生疑慮的選擇？
會發生這種事往往就一個結果：所學仍然不足，所知仍然有限。
那要怎麼解決？我教你個簡單的………

辭去你現在的工作，直接面試企業。想辦法進去被操到不是人。
那麼你就會學到很好的東西。

自幹的意義不太大………自己摸再多沒去實戰過你很難了解外面的世界如何運作。

weiclin iT邦高手 4 級 ‧ 2018-12-03 01:56:54 檢舉

別誤會了, MVC 從來就不是為了快而產生的...

tommychi iT邦新手 5 級 ‧ 2018-12-03 09:54:41 檢舉

MVC模式的目的是實現一種動態的程式設計，使後續對程式的修改和擴充簡化，並且使程式某一部分的重複利用成為可能。除此之外，此模式通過對複雜度的簡化，使程式結構更加直覺。軟體系統通過對自身基本部分分離的同時也賦予了各個基本部分應有的功能。專業人員可以通過自身的專長分組 ... ----- 節錄於維基百科。

㊣浩瀚星空㊣ iT邦大神 1 級 ‧ 2018-12-03 11:42:08 檢舉

mvc本來就不是依快為目的了。是依開發的整合方便性為目的

登入發表討論

直播研討會

{{ item.channelVendor }} {{ item.webinarstarted }} |

直播中

1 個回答

echochio

iT邦高手 1 級 ‧ 2018-12-03 07:55:38

最佳解答

    MVC  架構是給多人協作時好用，當程式有上千人同時寫時每個人只寫幾個功能

  但是只要一個人或許不必那麼麻煩，但是debug 時是要很清楚是哪個功能，那段程式在哪裡

   將程式拆解成一小段一小段，越小越好，有好也有壞，易於除錯，多人協作，這是優點，效能變差是確定，但是能差多少，幾毫秒？ 權衡開發時間短，除錯快，別人接手快，這些優點，所以流行