微软MVC——一些看法

 

一直以来都是从事微软的ASP.NET的网站开发，说老实话微软的事件模型，比起J2EE的JSF那是强太多了，但讲到性能事件模型估计十有八九不如MVC框架（没研究过，只是人云亦云），但从WEB开发而言前端性能及网络问题是WEB开发人员最需要考虑的，特别是网站开发，你是无法左右这二者性能高低及运行通畅的，你总不能像搞网络游戏那样，告诉用户：“兄弟啊，你想玩吗？那你必须符合XX配置”，人家才不叼你那，反正同类网站多的是，网络问题也一样，好像10M以上的带宽就贵的要死，那花的代价就大了，局域网么还好。至于后端吗，是可以控制的，性能差那搞个高性能的服务器，在不行搞什么负载平衡，IIS缓存不够用，那搞分布式开发，解决方案一大堆，都在控制之内。从这个角度看，那MVC是要比事件模型好的太多了，简化了N多流量，生成的HTML代码也干净了不少，但企业级开发的兄弟们你们要考虑流量吗（只要不要太夸张）？至于性能方面的问题，只要性能不算太差，你们也无需考虑吧？拖拖拉拉，开发更快(.NET开发的优势还是在高效快速上吧？而且企业级开发占大多数吧？排除一些有特殊要求的企业，就这些企业人家好像更青睐J2EE吧，或者其他的开发吧！)

排除这大多数，剩余的就是网站程序员了，MVC横空出世，真是太大的好消息了，但问题是微软还是没能避免他们的老问题，什么Html.BeginForm，Html.TextBox这个你让UI去做，人家肯定不愿意搞的，弄到后来还是要我们程序员对页面做二次加工，你怎么就改不过来那？工作量依旧很大，以前很多东东，干脆不要视图，不用重量级的服务器控件，数据绑定么用Repeater，那你说搞个MVC还有什么意义，当然你能够自动组装参数，估计也就这个优点了，但以前就不行吗？到现在为止我没看出MVC对我这样的网站程序员带来什么好处，至少我依然要二次开发UI给的HTML页面。但似乎MVC好像摈弃了事件模型，本来我用Button能解决一些多按钮页面的提交问题，现在好了要写什么Html.BeginForm，当然我们可以在Controllers类中写多个方法吗？但问题是不是要写多个Html.BeginForm啊？是不是要想办法告诉Controllers我点了那个按钮啊？靠～好不容易达成的和谐，有给微软搞乱了。

微软的老大们啊， 你们为什么不想个办法，让我们不需要对UI给的HTML页面做二次加工啊？至少，少点加工也行啊。我们是不是应该更关注后台的代码，及如何提高性能啊。逼近我们拿老板的工资，总部能一味的说：“这个么，我也没办法的，要不在加台服务器？” 网站搞大了，还要怕你们来告我们公司，讹诈我们买N多你们的产品。微软啊，你们服务质量太差！难怪我们要铤而走险，要用盗版，就是不用正版哈哈：）

（等待高人为我传道授业解惑——关于MVC）