使用.NET进行高效率互联网敏捷开发的思考和探索【一、概述】

不知从什么时候开始，创业变得很廉价，谈什么都是互联网，动辄融资千万。这阵风好像也刮向了程序员中，有那么一大批开发者，数据结构不好好学习、数据库原理不扎实掌握，在github上发布几个项目，用nodejs创建一些服务，再用H5写出APP，就自以为迈入了高级程序员的队伍，能够运筹帷幄互联网项目，难道学习新技术、新理念就是快速成长吗，显然不完全是，在这浮躁的氛围中，各种粗制滥造的互联网网站、APP接踵而至，很多看似漂亮的APP，连简单的http接口安全都没有措施应对，很多美丽的响应式网站，目录结构随意堆叠，这实在是一股歪风邪气，我觉得程序员还是应当踏踏实实的多学理论，多写代码，反复实践。

那么另外一个问题就来了，新技术、新理念难道就没有用了吗，显然也不是，新技术新理念是无数的技术大牛在长期的实践中反复重构的胜利果实，而作为一个.NET老司机，眼看着这些年微软拥抱开源，拥抱社区带来的改变和进步，也是深感欣慰，于是今天，我想和大家分享一下这些年我以及我的公司对于使用.NET进行Web开发乃至于互联网应用开发的一些经验和技术总结。

先看一个最新上线的典型案例，http://muban.printhelloworld.com，其中用到了诸如HTML5、Bootstrap、EF6 For MySql、阿里云RDS，阿里云CDN等新技术和新理念，然而却并没有脱离采用.NET进行开发以及采用.NET生态环境（IIS、Windows Server）进行部署这一基础，但整个开发流程，已经完全摆脱了WebForm甚至MVC，我们实践了一套全新的.NET开发模式，在开发效率和团队协作上大大提升，在开发时间上也极大地缩短，在这个案例里面，整个网站的前台和后台管理，从构思到设计、开发、调试、部署，1个人3天完成。下面就开发模式的细节详细描述，也听取大家的意见，继续改进和完善。

对于ASP.NET WebForm的评价，我想以下的话是客观的：ASP.NET WebForm托拉拽以及事件驱动的Web开发模式的创新，虽然方便了一大批.NET入门者的学习和理解，但最终严重阻碍了的.NET的普及和商业化使用，而且在很长一段时间内，.NET优秀的语言特性得不到重视，反而一直被扣着低效率、难扩展、不适合商业开发的帽子，ASP.NET WebForm在这其中有着不可推卸的责任。

遥想06、07年的时候，我还在惊叹于UpdatePanel的强大和方便，现在回想来看，这样的开发模式让开发人员对HTTP和Web本质的认识无疑是罩上了一层迷雾，从长远看是一种倒退，再往后来，到了ASP.NET MVC时代，微软高阶程序员的陋习依旧没有改善，虽然MVC开源了，但仍然充斥着各种自以为是的为开发人员提前想好的特性、绑定、快捷方法等等，这些东西初级开发人员可能会觉得很方便，但我想，任何从事过商业项目架构和开发的技术经理都会深有感触，在真正需要稳定的扎实项目中，这些小聪明，不仅毫无用处，而且难以扩展，更容易导致难以掌控的Bug和漏洞。

令人庆幸的是，在Nadella的带领下，在比尔盖茨重新担任技术顾问的指引下，.NET不断修正方向，除了在语言上大步向前，更在生态建设上愈加清晰可见。我一直在怀疑公司所创造的.NET敏捷开发模式是否是先进性的体现，直到vNext（MVC6.0）的出现，我豁然开朗，原来殊途同归，微软终于走对路了。

在谈开发模式之前，我想先谈一谈：

一、目前的互联网项目或者是传统Web项目的一些新趋势和特点

1、不再使用WebService，而是大量使用HTTP作为数据通讯的方式

2、数据载体不再使用XML，转而使用JSON

3、Web前端会使用Bootstrap、JQueryUI、EasyUI等第三方HTML5框架

4、有APP的需求，甚至APP优先的需求，APP需要对接各类第三方插件

5、为了追求APP快速上线，有时候会采用HTML5的APP开发模式，例如PhoneGap、AppCan、HBuilder等

6、 有微信的需求，要求对接微信公众账号，进行微信浏览器中的移动Web开发

7、开发周期短、迭代频繁

8、数据量增长迅速，对报表展示、数据分析有较多的需求

9、项目组人员需求由Web开发工程师，细分为HTML5前端工程师、JAVA（.NET）工程师、数据库工程师等

10、单元测试减少，功能测试越来越多，甚至用互联网工具（worktile等）替代专业测试工具

基于以上情况，我们考虑，如果仍然使用.NET进行系统开发，那么在用户量<=50万的敏捷项目里：

二、一些传统的.NET Web开发模式和方法就应该被抛弃

1、ASP.NET WebForm以及MVC模式不再合适，他们均存在前后端耦合严重，简单流程复杂化的问题，而且前端始终无法脱离.NET架构。

2、SQL Server数据库不再合适，虽然SQL Server 2014的特性让人激动，但随着公有云的使用越来越普遍，同时相比其他数据库来说，大小、价格、可扩展性甚至性能方面，SQL Server都显劣势。

3、传统三层架构不再合适，很多互联网项目，从设计之初就要求能够支持多服务节点，不同应用场景使用不同数据库。再加上三层架构大量使用反射牺牲性能增加代码，也不再适合敏捷开发。

4、Server 2003的IT架构应当被抛弃，无论是IIS6.0落后于IIS7的HTTP请求处理模型，还是Server 2003落后于Server 2008、2012的稳定和扩展，都不应当再考虑基于Server 2003和IIS6的.NET部署。

虽然被抛弃了一些东西，但微软毕竟是微软：

三、一些.NET特性应当被强化

1、深入使用Visual Studio 2015开发工具，VS2015是宇宙级开发工具无需多说，甚至在前端编码（CSS、JS、HTML）上也愈加纯熟，配合适合工程师自己的自定义设置以及第三方插件，将会如虎添翼

2、TFS源代码管理的使用，无论是内部安装TFS Express版本还是在tfs.visualstudio.com上申请免费空间，都能够很好的进行团队协作，以我们实践来看，切勿被Git模式冲昏头脑，事实上TFS管理模式才是最适合.NET开发的

3、.NET高阶语言特性应当加强使用，在理解的基础上，如果能熟练使用Linq、Lamda表达式、反射、Task并行编程等.NET特有的优质语言特性和方法，将会极大地提升开发效率，缩短开发时间。

4、IIS的高级功能和动态管理应当加强使用，IIS7以后，IIS服务器就是高性能Web中间件的代名词，加上Server 2008、2012的Core模式，加强对IIS的动态管理和配置能够极大地提升Web处理效率。

5、Server 2012 R2操作系统应该加强使用，虽然跨平台是.NET的方向，也在mono上实践的很好，但在PC服务器和云服务器越来越便宜的今天，还是多用用Windows最新的服务器操作系统吧。

有了以上这些认识，经过总结，我们现行的.NET开发模式，可以简单概括为如下：

一、前后端高度解耦

首先要做的就是彻底抛弃ASP.NET WebForm和MVC模型，前后端高度解耦，前端的所有逻辑处理均使用JS进行处理，包括Dom元素布局与绘制以及数据请求，而后端为纯粹的业务逻辑处理，包括逻辑处理以及数据处理。目前我们的项目由于使用了ASP.NET中的Routing特性，依然Host在ASP.NET模型以及IIS中，在理论中以及不久的将来，替换为Core IIS或者Linux下的Nginx来Host纯HTML5以及HTMl5缓存也将非常容易。

二、前端使用纯HTML5

前端抛弃传统HTML，尽量全部使用HTML5技术，其中做出的牺牲有，抛弃IE11以下的浏览器，但在互联网思维的今天，这样的思路也未尝不可，当在前端全部使用HTML5技术后， 文件、图形图像、音频视频、地理位置等各种处理将变得非常简单，而且扁平化、数据化。

三、前端充分利用成熟框架

使用新的开发模式后，很明显的一个改变就是，公司的美工不再或者很少进行前端切图，而对于技术美工的需求（会CSS开发和JS开发、也懂设计）则日渐增加，带来这一改变的根源就是那些不断涌现先进的、优秀的前端框架，我们目前正在使用的有JQuery、Zepto、JQueryUI、JQueryMobile、Bootstrap、Amaze UI、inoic、Framework7、SUI、MUI等等，以及伴随着这些优秀框架的第三方插件。客观的说，通过优秀框架的使用，不仅没有增加前端的系统风险，反而由于框架的开源、架构清晰、稳定等特性，实现了更加稳定、可扩展的前端。简单的举个例子，在解决困扰很多Web工程师的全兼容性的布局以及响应式布局问题上，Bootstrap就功不可没。

四、前端开发面向对象化

将前端开发，通过JS面向对象特性进行简单封装，在Dom元素操作以及业务逻辑数据请求的处理上，与后端数据类型、实体结构以及处理逻辑上保持一致，不仅拉近了前后端开发人员之间对业务需求的理解，也是极大地降低的技术培训的门槛，提升了团队合作的效率。

五、使用CDN服务

CDN服务在几年前还是大企业、大公司的专属，现在已经完全普及化、平民化，Web前端越来越重是不争的事实，但真正的业务逻辑往往只有几十K甚至几K，1个几百K的页面，90%是JQuery等第三方框架，因此，合理的使用CDN加速，不仅提升用户端的体验，更直接将基于HTTP架构Web服务的负载能力提升5-10倍以上。

六、业务逻辑HTTP服务化

这句话的描述可能不是很恰当，但这也是我们全新的.NET开发模式中最重要的环节，经过对阿里开放平台等先进互联网架构的学习，最终我们形成了结构化但松散的业务逻处理模式，即每一个业务逻辑行为均有1个唯一的路由名称，业务逻辑只对路由名称负责，而路由名称对流向、性能、权限、安全等上层需求负责。这样做的好处是，能够充分利用3-5年左右经验的开发人员（这也是大部分公司的开发主力军），让他们专注于业务逻辑的编写，而业务逻辑之外的事情，在架构层面由其余的控制器去解决，而一个大的.NET项目工程，也可以灵活以不同的方式拆分为各个子模块。对于HTTP服务的实现，我们尝试过ASP.NET ASHX处理器、Windows Service HOST WCF服务、ASP.NET Web API，当前较为稳定版本是Web API，当然针对HTTP服务化这一需求，Wen API也显略重，以后会继续改进。总之这一改变过程，在实践中提升了至少3倍以上的开发效率和测试效率。在后一章节中，将会进行详述。

七、分布式与热加载HTTP服务建设

互联网应用要求的是敏捷开发和反复迭代，同一个逻辑架构下的不同请求会使用不同的服务器和数据库已经是家常便饭的事情，因此项目设计初期，分布式HTTP服务的建设至关重要，而业务更新更是需要能够进行热加载，在.NET体系里面，就是DLL托管代码的动态加载使用，可惜的是，由于公司现有项目并未出现大规模分布式场景，因此还未研发出较为稳定的DLL动态加载架构，在后一章节中，将会详细讨论。

八、使用阿里云解决大数据问题

我想任何一个使用过阿里云以及其他云服务的IT架构师，都能深深的感觉到，阿里云已经领先其他云不止一个身位。事实上，特别是阿里云的数据库相关功能，例如RDS、DRDS、KVStore等，都已经在实践环节真实的解决了很多传统需求里的复杂点和困难点，具体细节后面详细讨论，但真心的说一句，赶快使用阿里云吧，至少在现阶段，不是阿里云在绑架你，而是在帮助你。

今天写了很多，总的来说，就是告诉大家，.NET的春天已经来了，.NET不仅可以进行互联网化的敏捷开发，更能处理大型项目大型数据大型逻辑，这一点我在实践中已经尝到甜头，而作为一个写Pascal数据结构出身的程序员，也至今十五年有余，我也对各类新技术非常感兴趣，都有涉猎甚至尝试，不怕被别的语言喷，我甚至可以大胆的说一句，其他语言，从综合（语言、开发环境、开发效率、技术社区、团队协作、应用能力）上来看，在应用级开发领域，已经落后.NET太多太多，只是.NET程序员自己还没察觉，所以从这一点上来看，需要大家的共同努力，不断钻研和探索。

接下来的时间里，我会抽空继续把公司这一套开发模式和相关工具抽丝剥茧，开放出来，也听取大家的意见和建议，不断改进和完善，今天先写到这啦。