论MVC的悲哀--写网络数据库应用程序员之痛

本文搞编程已经十几年了，VB.NET,VB还是最爱。JS要用的，其它语言偶尔用一下，但不是IT人士。

一直在关注IT界和数据库编程的发展，现在看到MVC的潮流势不可挡，连微软也在VS中也将MVC的框架不断升级。但从自己的编程和业务经验来看MVC是一个非常多余的东西，它浪费了程序员大量的时间和精力。实际上通过数据库的设计和SQL语句已经完全清楚地阐述了绝大部分业务模型和在界面上的显示和控制要求。数据库中的META-DATA实际上已经完成了model（表、字段属性）的任务，但在MVC模式中却又通过各种编程语言为数据库的每张表建立一个对象（或者类），并对数据库的字段在对象或类中进行映射，写一大堆的GET和SET,虽然各种持久层的软件帮助程序员快速建立model，但各种框架看得程序员眼花缭乱，但实际上为编程戴上了沉重的枷锁。表和字段在数据库中已经有了，为什么又要用程序再映射一遍？然后美其名曰model。而各种各样的服务器端的语言（aspx,jsp,php....）又不能满足和控制客户在浏览器上的要求。最后不得不请出javascript走完最后一英寸的距离，这时候又要将数据库中的每个字段在web界面上用js进行控制和验证（如果想获得较好的用户体验），然后将数据送回到服务器再验证，最后进入数据库。所谓“敏捷”就是不停地重复这些工作吗？比较典型的例子是用微软的gridview控件写一个多行编辑的增删改查的业务界面，仿佛是教大象在跳舞，先要建立数据层，搞GET、SET，再为gridview每列设定验证以及是否可编辑（编辑项模板），然后调整增删改查的SQL语句，然后再用AJAX实现界面上的多行编辑，用JS对每个字段在浏览器中进行验证和无刷新返回数据到服务器。其实现在连微软也吃不消自己发明的服务器端控件，又搞了一套AJAX控件，看着一望无际的控件面板，我感觉自己是要用镰刀收割万亩良田，泪！。当然如果你只要操作数据库中的一张表，并且用户可以忍受单行编辑和保存的痛苦，程序员的工作可能会比较轻松。实际上大多业务用户正在为此事向IT部门投诉。用户在无休止地切换界面并等待服务器的反应（主要是指单行编辑和保存的非AJAX程序），如果要改善用户体验就要老老实实地将Model写三遍（数据库、数据层、富客户端界面），即使你用上Extjs也足以让你在各个层中晕头转向。JSON更是在其中推波助澜，当你打开一个JSON文件，数据库字段名在JSON中如垃圾般到处都是，大括号之复杂另人头晕，还不如xml文件清楚。而且如果业务要求有变，数据库增加了新字段，修改三个层的代码的痛苦工作足以让你产生重写整个工程的欲望。想想微软为什么要在C#中加入万能数据类型var？这说明数据层和浏览器上面对数据库表里字段的编程是多余的。为什么不建立多表查询通用的CRUD框架呢？用户痛苦的根本原因是web界面难以实现类似于excel的功能（在线编辑、应用公式和数据透视表）。编程人员的痛苦是用户不断要求去实现这些功能。企业管理系统技术方面的问题（不谈管理），其本质是excel与现实系统的对抗，“工欲善其事，必先利其器”，因为管理系统的蠢慢所以导致系统和管理问题交织在一起，IT部门和业务部门互相指责。微软之所以不倒（虽然微软的操作系统和OFFICE的界面做得江河日下）,80%是归功于excel。如果要实现真正的敏捷，程序必须要自动从数据库中识别出数据类型和数据控制的基本要求。那么出路在哪里？方法是什么？以下是我的管见：写好SQL往界面一拖，多行编辑增删改查的grid就应该搞好了。