现在的位置: 首页 > 综合 > 正文

微软MVC——一些看法

2012年06月15日 ⁄ 综合 ⁄ 共 1164字 ⁄ 字号 评论关闭

 

一直以来都是从事微软的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)

 

 

抱歉!评论已关闭.