-
蝴蝶刀刀
我个人理解是mvc是一种大家约定俗成的规范，假如做这个项目的人中途离职，接手的人可以快速的熟悉代码上手开发。或者项目完成，后期维护是其他人的话，也可以快速的掌握逻辑，当然你们项目完全就是那么几个人做，特别是带项目人不会轻易变动，那么按照你自己的想法架构当然也没问题。字段的话，肯定传参不要直接传字段名，可以做一个字段字典来映射
-
慕妹3146593
分层，代码结构更加清晰，更好的解耦
-
呼如林
楼主的问题简单分为两个问题，并先给出简要结论，再做分析。1 mvc 的意义，以及你们老大的方法的合理性mvc 非常重要，除非你的代码是用来“挖坑”的。但你老大的方法并非全错，下面再做分析。2 让前端把表名发给后端。是否可行。绝对不可行。暴露表名，无异于裸奔！
分析：
1） mvc 作用：解耦，解耦，解耦！可以讲编程的核心之一就是模块化也就是解耦，更简单点说就是：可维护性。如果你的代码写用了1星期，后续修改调试用了1个月。那不是给别人挖坑吗？
但是在mvc 出来之前以及现在，还是有很多程序员喜欢用直接拼接SQL 的方式来开发的。这个也并不完全错误。要看需求，以及只要你原则是：解耦，可维护，就是可行的。对于TP 来讲，如果你的系统确实很简单，你打算放弃 model 也可以把逻辑写在 controler 也就是 action里面。总之除非必要，还是按照mvc 的方式写比较好。
2）关于数据库，你说的猜数据库信息其实就是 SQL 注入，利用程序漏洞，让你的系统非法执行某些 SQL 语句，从而暴力破解你的数据库账号密码，然后逐步再获得io权限，写入非法脚本，提权获得最高权限。 别人用SQL注入穷举的方法暴力破解你的数据库，并不一定能掌握你数据库的信息，而你直接把数据库信息暴露出来，那不是相当于裸奔吗？ 正确的方法应该是用 REST api
-
芜湖不芜
意义就是少做重复的事，后期好维护。至于数据查询，没听说过要前端传表名的和字段的。你说的应该是后端的模板引擎，那已经不全属于前端了。
-
倚天杖
简单发表个人看法：
mvc存在的意义非常大，可能在小项目中并不明显。在大的项目中可以让项目结构更清晰，更方便后期的维护和扩展，定位问题也很方便很多，各模块之间分工明确。
你现在的麻烦是为后期的轻松做准备。
就好比传统项目和分布式项目一样。分布式项目无疑增加了代码工作量。但同时也提高了系统的性能。在高并发场景，不会因为某个模块挂了而宕机。在电商平台，服务器挂了是多么可怕的事情
很多技术和架构思想，并不是凭空产生的，都是为了方便程序员高效，高质，高兴，完成项目而存在的。
其他同行来补充吧.......
-
慕田峪7331174
并不是把model做成DB类就不是MVC了，你这样只是把以前要每个model都手写，改成了“通用操作”无需另外实现而已（简单来说，就是“规则化”）
mvc也好其它模式也好，其实都是“分层”的思想，但怎么分才是最好，也不是一成不变的，分久必合，合久必分，理解了找到最适合的就好。
安全问题是一个系统性的，不能仅从暴露了表名字段名来判断。当然，你觉得不放心，实现这个“DB类”时，完全可以作一层转换简单的做法就是加前后缀，比如传的表名是tb1,那你最终要查询的表是"my_tb1",复杂点就是影射表，比如tb1->my_tb1, tb2->you_tb2,
-
慕侠2389804
MVP 出现的时间非常早，1979年，那个时候的电脑和其使用方式和今天有巨大差别，简单的寻找 MVC 的意义没有意义
软件工程学和编程是不同的两种技术。前者更关注通过团队协作建构大型项目，MVC是典型的软件工程学的技术结晶。所以在工程不大的情况下，看不到 MVC 架构的好处是正常的，因为它并不影响写代码。
MVC 和其它一些模式通过抽象把代码进行分层，不同层次的代码处理不同的需求，这样给团队协作带来很大的好处，大家可以各司其职，并行不悖。
使用什么样的技术什么样的架构需要和具体业务具体团队结合，你的老大做出这样的选择应该有他的考虑。
不过让前端传表明和字段就显得很蠢了……
-
一只萌萌小番薯
MVC成功的分离开了数据，逻辑以及界面。想象一下，如果这三者不分离，项目组里美工得学编程，程序员得学数据库，DBA得学编程，是不是时间消耗增加，效率下降？但如果分离开来，DBA专心设计数据库结构，写完丢进model美工专心设计界面，设计好了丢进view程序员专心写程序，写完丢进controller三拨人可以几乎不互相依赖地异步开发，而不会像传统模式，需要数据库更新结构，于是逻辑得改，但逻辑一改还得通知美工把表单更新了，这样就会卡在等待其中一个人上。还有就是再次修改的时候不容易被混在一起的模型视图控制器搞晕