mvc的存在到底有什么意义？一个初级程序员的疑问

Question

本人刚刚毕业，目前在一个外包公司做最基础的代码开发，用的是thinkphp5.
昨天老大说是要更新我们以前自己开发的用来加快进度的后台，而他的思想就是把thinkphp的model全部去掉，用DB类做代替，而且要用一个通用的方法取代90%库的增删改查，有一些确实需要写的逻辑类的代码，就建立一个*model的文件写进去，但是不继承thinkphp的Model类，也就是只是一个叫做model的普通类。
后来我想了一下，确实，以前我们写Model有时候仅仅是简单的建立一个文件，把一些必要的代码写进去就算完事，而这样的话完全可以用Db去代替所以，mvc的存在对于我们这些开发一些说大不大，说小还挺费时间的人员来说，mvc到底存在什么意义？
还有一个问题就是，按照老大的想法，前端需要数据的时候，需要将他们想查的表的表名以及条件还有字段什么的全部传过来，我对安全这方面不是很懂，但是以前好像看过一些安全方面的资料说是在安全审计方面有专业的工具就是猜表名，猜字段。我们这样直接把表名字段暴露出去是否会有安全隐患？还是我想多了？

Answer 1

我个人理解是mvc是一种大家约定俗成的规范，假如做这个项目的人中途离职，接手的人可以快速的熟悉代码上手开发。或者项目完成，后期维护是其他人的话，也可以快速的掌握逻辑，当然你们项目完全就是那么几个人做，特别是带项目人不会轻易变动，那么按照你自己的想法架构当然也没问题。字段的话，肯定传参不要直接传字段名，可以做一个字段字典来映射

Answer 2

分层，代码结构更加清晰，更好的解耦

Answer 3

楼主的问题简单分为两个问题，并先给出简要结论，再做分析。1 mvc 的意义，以及你们老大的方法的合理性mvc 非常重要，除非你的代码是用来“挖坑”的。但你老大的方法并非全错，下面再做分析。2 让前端把表名发给后端。是否可行。绝对不可行。暴露表名，无异于裸奔！ 分析： 1） mvc 作用：解耦，解耦，解耦！可以讲编程的核心之一就是模块化也就是解耦，更简单点说就是：可维护性。如果你的代码写用了1星期，后续修改调试用了1个月。那不是给别人挖坑吗？ 但是在mvc 出来之前以及现在，还是有很多程序员喜欢用直接拼接SQL 的方式来开发的。这个也并不完全错误。要看需求，以及只要你原则是：解耦，可维护，就是可行的。对于TP 来讲，如果你的系统确实很简单，你打算放弃 model 也可以把逻辑写在 controler 也就是 action里面。总之除非必要，还是按照mvc 的方式写比较好。 2）关于数据库，你说的猜数据库信息其实就是 SQL 注入，利用程序漏洞，让你的系统非法执行某些 SQL 语句，从而暴力破解你的数据库账号密码，然后逐步再获得io权限，写入非法脚本，提权获得最高权限。 别人用SQL注入穷举的方法暴力破解你的数据库，并不一定能掌握你数据库的信息，而你直接把数据库信息暴露出来，那不是相当于裸奔吗？ 正确的方法应该是用 REST api

Answer 4

意义就是少做重复的事，后期好维护。至于数据查询，没听说过要前端传表名的和字段的。你说的应该是后端的模板引擎，那已经不全属于前端了。

Answer 5

简单发表个人看法： mvc存在的意义非常大，可能在小项目中并不明显。在大的项目中可以让项目结构更清晰，更方便后期的维护和扩展，定位问题也很方便很多，各模块之间分工明确。 你现在的麻烦是为后期的轻松做准备。 就好比传统项目和分布式项目一样。分布式项目无疑增加了代码工作量。但同时也提高了系统的性能。在高并发场景，不会因为某个模块挂了而宕机。在电商平台，服务器挂了是多么可怕的事情 很多技术和架构思想，并不是凭空产生的，都是为了方便程序员高效，高质，高兴，完成项目而存在的。 其他同行来补充吧.......

Answer 6

并不是把model做成DB类就不是MVC了，你这样只是把以前要每个model都手写，改成了“通用操作”无需另外实现而已（简单来说，就是“规则化”） mvc也好其它模式也好，其实都是“分层”的思想，但怎么分才是最好，也不是一成不变的，分久必合，合久必分，理解了找到最适合的就好。 安全问题是一个系统性的，不能仅从暴露了表名字段名来判断。当然，你觉得不放心，实现这个“DB类”时，完全可以作一层转换简单的做法就是加前后缀，比如传的表名是tb1,那你最终要查询的表是"my_tb1",复杂点就是影射表，比如tb1->my_tb1, tb2->you_tb2,

Answer 7

MVP 出现的时间非常早，1979年，那个时候的电脑和其使用方式和今天有巨大差别，简单的寻找 MVC 的意义没有意义 软件工程学和编程是不同的两种技术。前者更关注通过团队协作建构大型项目，MVC是典型的软件工程学的技术结晶。所以在工程不大的情况下，看不到 MVC 架构的好处是正常的，因为它并不影响写代码。 MVC 和其它一些模式通过抽象把代码进行分层，不同层次的代码处理不同的需求，这样给团队协作带来很大的好处，大家可以各司其职，并行不悖。 使用什么样的技术什么样的架构需要和具体业务具体团队结合，你的老大做出这样的选择应该有他的考虑。 不过让前端传表明和字段就显得很蠢了……

Answer 8

MVC成功的分离开了数据，逻辑以及界面。想象一下，如果这三者不分离，项目组里美工得学编程，程序员得学数据库，DBA得学编程，是不是时间消耗增加，效率下降？但如果分离开来，DBA专心设计数据库结构，写完丢进model美工专心设计界面，设计好了丢进view程序员专心写程序，写完丢进controller三拨人可以几乎不互相依赖地异步开发，而不会像传统模式，需要数据库更新结构，于是逻辑得改，但逻辑一改还得通知美工把表单更新了，这样就会卡在等待其中一个人上。还有就是再次修改的时候不容易被混在一起的模型视图控制器搞晕