微软ASP.NET技术“乱谈”

微软ASP.NET技术“乱谈”

2014新年了，顺手写的一点文字，主要谈谈我对当前微软ASP.NET技术的见解，比较随意，大伙儿随便看看吧。

1 当前微软Web平台技术全貌

从2002年发布.NET 1.0和Visual Studio.NET，到2013年.NET 4.5.1和Visual Studio 2013发布时，微软.NET平台己有11年的历史，其Web技术几经变迁，当前演化为如下的主要技术子领域：

 

 一张图了解微软Web平台技术全貌

 

时至今日， ASP.NET底层的基础架构基本没太大变化，诸如使用HTTP处理管线处理HTTP请求，使用HTTP Module对原始HTTP请求进行“加工“，使用HTTP Handler生成发给浏览器的HTML代码等核心运做机理也没有变化，全部变化的都是上层技术。

下面就简要地聊聊当前ASP.NET技术家族的各项成员：

• 从1.0就有的Web Forms是当之无愧的“创业元老“，有关它的话题后面要重点说，此处先不提。

• ASP.NET MVC是后来的但迅速成长为当前最核心的微软Web开发技术，全部学习或使用微软Web技术开发的人，如今还不学习MVC，那实在是件很让人奇怪的事。有趣的是，如今Web Forms开始愈来愈多地引入MVC的特性，这在ASP.NET 4.5中看得很是明显：好比强类型的数据库绑定，用户友好的URL等等。打个可能不太恰当的比方：MVC可当作是“米国”，Web Forms可比成“天朝”，“两国”往来密切。

• Web Api是针对移动互联时代的需求而设计，相比那复杂无比的“WCF怪兽”，WebApi设计得至关轻巧，它主要负责与手机等智能移动设备交换信息，底层直接使用HTTP，API具备REST风格，数据交换格式使用Json和Xml，这种格式的数据具备良好的跨平台能力，能方便地被Android和iOS设备所解析。Web Api能方便地与Web Forms和MVC相互集成，使之成为微软平台开发移动互联应用服务端Service层的理想选择。

• 基于MVC/Web API，开发如今比较流行的“单页面应用（SPA：Single Page Apps）”很方便。基于微软平台开发这种类型的应用，可以使用MVC提供页面模板，Web Api提供各类数据服务，前端页面使用各类Web框架（好比Angular、knockout等以AJAX方式访问服务端的Web Api服务，动态地更新页面的相应区域，响应用户操做）。

• 另外一项技术Web Pages采用相似于PHP的开发方式，直接在页面使用Razor集成C#代码，与MVC相比，它属于“轻量级”技术，比较简单易用，固然，付出的代价是没有MVC所提供的诸多内置功能，对于功能简单的小网站，Web Pages很合适。

        这里谈到PHP，说些题外话：诸如PHP、JSP之类微软以外的其余Web开发技术，与ASP.NET其实有诸多重合之处，每种编程技术都有多种框架可选。你能够先学PHP/JSP，再学ASP.NET，或者反之。不过我我的感受，若是先学ASP.NET再学其余技术，开始会略感不适，由于原来不少你己经习惯的“自动化”的东西，在许多其余技术中必须由程序员手动实现，是谓“由奢入简难”。但毕竟都是Web应用，仍是有不少都是同样或相似的东西，转型并不困难。

•  SignalR是ASP.NET家族中一个全新的成员，它实际上是一个Web开发框架，能开发“实时”的Web应用。所谓“实时”，其实就是在服务端与客户端之间创建“双向”信息通道，容许服务端主动向客户端发送信息，回调客户端代码。SignalR底层依据各类状况会自动选择诸如HTML5 WebSocket这样的技术实现客户端与服务端的双向数据通信。这项技术挺有意思的，之后有机会再详细聊聊它。

在现有的ASP.NET技术家族成员中，Web Forms是“元老”，MVC是“新贵”，二者都是微软Web技术中最引人注目的焦点，下面就专门地聊聊它们。

2 MVC vs Web Forms

Web Forms是老家伙了，在MVC出现以前，它是微软Web技术领域内当之无愧的“一把手”（实际上是由于没得选，它是惟一候选人），有大量的Web项目使用它开发，其中许多项目一直跑到今天，并且看起来还会继续跑下去，到底要跑多久，谁也不知道。由于在实践中，你们都有意无心地遵循这样一个原则：

If it’s not broken, don’t fix it.

这就是说，对于老的使用Web Forms开发的项目，若是它还运转正常，就不要去动它。可是，若是要开发新项目，就须要仔细考虑是否仍然采用这种拥有十多年历史的“老”技术了。

John Ciliberti在其《ASP.NETMVC 4 Recipes》一书中对Web Forms的优缺点做了比较全面的总结，原文内容很多，我粗略地转述以下（同时加上了一些我的观点）：

• Web Form的好处：开发起来确实方便！

1. 招人容易。当前玩得转ASP.NET MVC的人并不算多。
2. 使用上手很是容易的相似于VB的开发方式。
3. 仅须要开发者懂一点HTML和JavaScript，就能够开发出“像模像样”的网站，相关的技术细节被Web Forms框架“细心”而且“紧密”地封装了起来，并且很明显设计者并不但愿使用者去“解开它”。
4. 拥有“一堆”功能强大易用的服务端控件，而且能在大多数浏览器中正确运行，浏览器兼容性（特别是对老的浏览器）不错。
5. 其用户控件很好用，易于开发，同时又能大幅度地减小重复代码。
6. 数据验证功能由相应控件进行封装，至关方便，开发者几乎不须要手写JavaScript验证代码。
7. 拥有一套本身的JavaScript框架，实现了AJAX功能，而且能与其余Web服务端控件无缝地整合。

• Web Forms缺点——让人只知其然，不知其因此然

1、引诱程序员写出“把全部东西混杂在一块儿”的Web应用。

Web Form采用Code-behind方式，虽然分离了页面模板代码和后台的C#代码，但实际上有不少程序员在后台C#代码中书写大量的业务逻辑代码，而且把这些代码与页面上的控件直接绑定（由于在高度智能化的Visual Studio中，这么干太容易了），这会给网站的长期维护带来麻烦。另外，若是不是在一开始就在架构上有所考虑，几乎没有办法对一个Web Forms项目进行单元测试。

2、成也控件，败也控件。

Web Forms开发中，控件是页面开发的核心。Web Forms服务端控件是重量级的控件，它拥有本身的一套运做机理，好比控件有本身的生存周期，在不一样的周期触发不一样的事件；Web Forms提供了很多数据验证控件，虽然能完成大多数常见的数据验证任务，但其可扩展性和性能比不上如今使用的诸多JavaScript库（好比jQuery Valiation，不依赖于服务端生成的ViewState，运行速度更快，使用方便灵活）。

1. 许多Web Forms服务端控件，虽然随着ASP.NET新版本的发布而不断更新，但仍然有很多使用“老”的页面生成技术，好比有些控件仍然使用table元素完成布局，当须要使用手机等访问这些网页时，其使用体验惨不忍睹。
2. ASP.NET 4.0之前版本的Web Forms控件在生成HTML代码时，其ID值至关地“变幻莫测”，这会给JavaScript代码编写带来麻烦，固然，4.0之后版本对此有所改进，如今能够指定ID了。
3. Web Forms的许多服务端控件必需要使用ViewState和Control State，一些特殊的控件，好比GridView，生成的ViewState数据量可能会很大（高达数M），若是不显式关闭，那这些数据会在Web Server和Client间来回传输，占用过多的网络带宽，下降了响应速度。
4. Web Forms控件关联着一个DLL，而且可能在内部使用了多个JavaScript脚本文件，这会致使浏览器收到的最终页面中会出现一些诸如

<script src="/ScriptResource.axd?d=JzFjHNVTNSRvxnyOuI_HmzgpeGgm-le_2DeNc7ub5pZUcy9A8M9scHh3p580Af72CFevs-15tBuSlQYGR8Y6jhCLDnQaQ1K84GPCFXjTaKWxU1eVzt8qVZ8mueqHNb4FDLOkRw2&t=ffffffff8a8533f5"
type="text/javascript">
</script>

 

之类的“神奇代码”，并且只要你往页面上加了一个控件，它们就会不请自来。对于这些代码，你只能祈祷它工做正常，一旦出了问题，跟踪至关困难。

       总而言之，Web Forms控件高度封装的特性使用开发者调整它所生成代码的手段不多颇有限，这限制了开发者的自由和发挥余地，也给页面优化带来困难。

3、 下面重点说说WebForm的另外一个问题——过分封装

        最初WebForm的设计思想是模仿VB的开发方式，用拖放控件的方式设计Web页面。但Web应用与桌面应用毕竟有重大差别，强求统一，必然须要对Web应用的底层机理进行深度地封装，方才可能创造出与桌面应用开发一致的开发体验。Web Forms的封装甚至到了这种程度：你不须要了解HTTP协议，也能经过拖拖拽拽的方式构建Web应用。

        这样一来，基于WebForms开发简单是简单了，但远离了Web应用的本质，Web Forms框架完成了太多的事，你必须照着它规定的套路来，留给你自由发挥的余地很少了。同时，因为WebForms把HTTP协议给包得几乎”看不到了”，制造了一个“Web网站开发并不复杂，就是这样“的第一印象，这实际上是一个”假像“，若是不能意识到它点，仅会用Web Forms的Web开发者，离开了Visaul  Studio，几乎没法在其余Web领域找到工做，由于你己“认假成真”被“洗脑“，必须”清空内存“，从新学习与了解Web应用的”真像“。

        相比WebForms，ASP.NET MVC要好得多了，它并未向使用者隐藏Web应用的本质，虽然学习曲线比较陡，涉及到技术和Web开发相关背景知识比较多，但能玩转它的人，其学习能力和平均开发水平每每都还不错。

3 微软技术影响下的程序员

        最后说说微软技术特色对程序员生涯和技术发展所带来的一些影响：

        微软技术的最大特色之一就是”易用“和”开发高效“，这是优势，但对于程序员而言，若是对此没有清晰的认识，则会受到不利的影响。

        微软技术为了易用，包了不少层，而且许多并不开源。当你尝试去探索其底层技术实现时，会困难重重。

        另外一方面，因为程序员自身开发经验与能力的限制，过分的封装也阻止了程序员对深度探索技术内幕的热情。

        与Windows相比，Linux不易用；与C#相比，Java不易用，C++尤为不易用；与Web Forms相比，JSP和PHP都不易用，……，但这些不易用，却迫使程序员去学习不少东西，调动了其积极性，程序员们收获到了自身能力与素质的提升。

        人的天性是懒的，易用、开发高效且高度封装的许多微软技术，严重削弱了不少程序员的技术探索欲望。因此我看到，在微软技术领域，只有那些意志坚决而且对技术自己有着浓厚兴趣的人，才能坚持这条深刻探索技术之路，并在这一技术探索过程当中收益良多。而这样的人，在微软领域以外，也会是一把好手。

        固然，针对微软技术“催生懒汉“这种现象，板子不能打在微软技术身上，而应该打在人身上，这是人自己的问题，技术自己是中性的，是“无辜”的。

        须要指出的是，微软技术走向开放的趋势日益明显，当前重量级的一些技术，好比ASP.NET MVC、Entity Framework等，都是开放源代码的，有时间读读这些项目的源码，定有所得。

        最后谈一点，因为学习掌握某个技术会耗费程序员大量的时间、精力甚至金钱，没有人但愿本身下大功夫掌握的技术没有用武之地，所以，门户之见至关突出。常常会看到许多程序员会为各类技术的所谓“优劣”争得面红耳赤，恼羞成怒者甚至开始对对方进行人身攻击，在网上，“黑“微软技术者尤为常见。

        其实，应该“把技术当成工具，但不要成为宗教信仰”。

        我赞同“实用主义”原则，别浪费时间去争论哪一个技术好、哪一个技术坏，而应该关注的是哪一个技术最适合于解决哪类问题。在不一样的场景选择合适的技术，别试图用一种技术去包打天下，“多学几手，脚踏两只船”。

        固然，想“脚踏两只船”，这要求程序员要有足够的学习能力和扎实的计算机专业基础知识和基本技能，并且“船不少”，人却只有两只脚，加上人的时间精力也是有限的，因此要针对众多的“引人”的技术勇敢地说“不”。有所不为才能有所为，追求“一专多能”，努力精通一项技术，对其余的技术作到须要时能快速上手并对付工做任务便可。学习能力再强，也不要期望能“快速”地成为另外一领域内的”高手“，这既不可能也无必要。在实际开发中，也许你不精通某项须要用到的技术，但必定有人精通这个技术，你们相互合做，取长补短就行了，共赢！