mvc的存在到底有什么意義？一個(gè)初級(jí)程序員的疑問

1. MVP 出現(xiàn)的時(shí)間非常早，1979年，那個(gè)時(shí)候的電腦和其使用方式和今天有巨大差別，簡(jiǎn)單的尋找 MVC 的意義沒有意義
2. 軟件工程學(xué)和編程是不同的兩種技術(shù)。前者更關(guān)注通過團(tuán)隊(duì)協(xié)作建構(gòu)大型項(xiàng)目，MVC是典型的軟件工程學(xué)的技術(shù)結(jié)晶。所以在工程不大的情況下，看不到 MVC 架構(gòu)的好處是正常的，因?yàn)樗⒉挥绊憣懘a。
3. MVC 和其它一些模式通過抽象把代碼進(jìn)行分層，不同層次的代碼處理不同的需求，這樣給團(tuán)隊(duì)協(xié)作帶來很大的好處，大家可以各司其職，并行不悖。
4. 使用什么樣的技術(shù)什么樣的架構(gòu)需要和具體業(yè)務(wù)具體團(tuán)隊(duì)結(jié)合，你的老大做出這樣的選擇應(yīng)該有他的考慮。
5. 不過讓前端傳表明和字段就顯得很蠢了……

1. 并不是把model做成DB類就不是MVC了，你這樣只是把以前要每個(gè)model都手寫，改成了“通用操作”無需另外實(shí)現(xiàn)而已（簡(jiǎn)單來說，就是“規(guī)則化”）
2. mvc也好其它模式也好，其實(shí)都是“分層”的思想，但怎么分才是最好，也不是一成不變的，分久必合，合久必分，理解了找到最適合的就好。
3. 安全問題是一個(gè)系統(tǒng)性的，不能僅從暴露了表名字段名來判斷。當(dāng)然，你覺得不放心，實(shí)現(xiàn)這個(gè)“DB類”時(shí)，完全可以作一層轉(zhuǎn)換
   簡(jiǎn)單的做法就是加前后綴，比如傳的表名是tb1,那你最終要查詢的表是"my_tb1",復(fù)雜點(diǎn)就是影射表，比如tb1->my_tb1, tb2->you_tb2,

MVC成功的分離開了數(shù)據(jù)，邏輯以及界面。
想象一下，如果這三者不分離，項(xiàng)目組里美工得學(xué)編程，程序員得學(xué)數(shù)據(jù)庫，DBA得學(xué)編程，是不是時(shí)間消耗增加，效率下降？
但如果分離開來，
DBA專心設(shè)計(jì)數(shù)據(jù)庫結(jié)構(gòu)，寫完丟進(jìn)model
美工專心設(shè)計(jì)界面，設(shè)計(jì)好了丟進(jìn)view
程序員專心寫程序，寫完丟進(jìn)controller
三撥人可以幾乎不互相依賴地異步開發(fā)，而不會(huì)像傳統(tǒng)模式，需要數(shù)據(jù)庫更新結(jié)構(gòu)，于是邏輯得改，但邏輯一改還得通知美工把表單更新了，這樣就會(huì)卡在等待其中一個(gè)人上。
還有就是再次修改的時(shí)候不容易被混在一起的模型視圖控制器搞暈

分層，代碼結(jié)構(gòu)更加清晰，更好的解耦

可能開發(fā)人員少的時(shí)候感覺不到MVC的用處，但是多人維護(hù)的時(shí)候就會(huì)體現(xiàn)出他的用處，而且日后你不在了給你填坑的那些老哥能方便看懂代碼。還有種說法是tp的MVC之上再加service和logic，每種東西應(yīng)該都有他的作用，存在即是合理。

意義就是少做重復(fù)的事，后期好維護(hù)。至于數(shù)據(jù)查詢，沒聽說過要前端傳表名的和字段的。你說的應(yīng)該是后端的模板引擎，那已經(jīng)不全屬于前端了。

我個(gè)人理解是mvc是一種大家約定俗成的規(guī)范，假如做這個(gè)項(xiàng)目的人中途離職，接手的人可以快速的熟悉代碼上手開發(fā)?；蛘唔?xiàng)目完成，后期維護(hù)是其他人的話，也可以快速的掌握邏輯，當(dāng)然你們項(xiàng)目完全就是那么幾個(gè)人做，特別是帶項(xiàng)目人不會(huì)輕易變動(dòng)，那么按照你自己的想法架構(gòu)當(dāng)然也沒問題。字段的話，肯定傳參不要直接傳字段名，可以做一個(gè)字段字典來映射

樓主的問題簡(jiǎn)單分為兩個(gè)問題，并先給出簡(jiǎn)要結(jié)論，再做分析。
1 mvc 的意義，以及你們老大的方法的合理性
mvc 非常重要，除非你的代碼是用來“挖坑”的。但你老大的方法并非全錯(cuò)，下面再做分析。
2 讓前端把表名發(fā)給后端。是否可行。
絕對(duì)不可行。暴露表名，無異于裸奔！

分析：

1） mvc 作用：解耦，解耦，解耦！
可以講編程的核心之一就是模塊化也就是解耦，更簡(jiǎn)單點(diǎn)說就是：可維護(hù)性。如果你的代碼寫用了1星期，后續(xù)修改調(diào)試用了1個(gè)月。那不是給別人挖坑嗎？

但是在mvc 出來之前以及現(xiàn)在，還是有很多程序員喜歡用直接拼接SQL 的方式來開發(fā)的。這個(gè)也并不完全錯(cuò)誤。要看需求，以及只要你原則是：解耦，可維護(hù)，就是可行的。對(duì)于TP 來講，如果你的系統(tǒng)確實(shí)很簡(jiǎn)單，你打算放棄 model 也可以把邏輯寫在 controler 也就是 action里面?？傊潜匾?，還是按照mvc 的方式寫比較好。

2）關(guān)于數(shù)據(jù)庫，你說的猜數(shù)據(jù)庫信息其實(shí)就是 SQL 注入，利用程序漏洞，讓你的系統(tǒng)非法執(zhí)行某些 SQL 語句，從而暴力破解你的數(shù)據(jù)庫賬號(hào)密碼，然后逐步再獲得io權(quán)限，寫入非法腳本，提權(quán)獲得最高權(quán)限。 別人用SQL注入窮舉的方法暴力破解你的數(shù)據(jù)庫，并不一定能掌握你數(shù)據(jù)庫的信息，而你直接把數(shù)據(jù)庫信息暴露出來，那不是相當(dāng)于裸奔嗎？ 正確的方法應(yīng)該是用 REST api

簡(jiǎn)單發(fā)表個(gè)人看法：

1. mvc存在的意義非常大，可能在小項(xiàng)目中并不明顯。在大的項(xiàng)目中可以讓項(xiàng)目結(jié)構(gòu)更清晰，更方便后期的維護(hù)和擴(kuò)展，定位問題也很方便很多，各模塊之間分工明確。
2. 你現(xiàn)在的麻煩是為后期的輕松做準(zhǔn)備。
3. 就好比傳統(tǒng)項(xiàng)目和分布式項(xiàng)目一樣。分布式項(xiàng)目無疑增加了代碼工作量。但同時(shí)也提高了系統(tǒng)的性能。在高并發(fā)場(chǎng)景，不會(huì)因?yàn)槟硞€(gè)模塊掛了而宕機(jī)。在電商平臺(tái)，服務(wù)器掛了是多么可怕的事情
4. 很多技術(shù)和架構(gòu)思想，并不是憑空產(chǎn)生的，都是為了方便程序員高效，高質(zhì)，高興，完成項(xiàng)目而存在的。
5. 其他同行來補(bǔ)充吧.......