10年前，微软开发人员的生活非常美好. 公司很乐意在大多数开发项目中使用微软开发栈. 用ASP.网在前端， .. 网中间层和后端SQL Server，大多数情况下工作得很好. 当他们不这么做的时候，开发者就会把这当成是地盘上的东西. 微软几乎主导了这场秀. 然后，在上个十年结束时，微软800磅重的大猩猩地位开始瓦解. 也许是因为iPhone的推出和微软错过了向移动设备的转变, 也可能是因为开源项目的激增, 但是事情变了, 而今天，这些公司需要被说服，让他们相信使用微软堆栈是个好主意. 本文提出了坚持使用微软软件栈的八个理由.

原因# 1: .. 网仍然是最好的

十多年前推出， .微软网络框架 功能是否丰富，是否经过彻底的实战考验. 虽然在早期，必须将本机开发与托管代码结合起来是很常见的 .网，现在绝大多数的开发任务都是开箱即用的. 甚至像甲骨文这样的公司也发布了100%的组件 .. 网托管代码(i.e. ODP.. 网管理的驱动程序)与他们的产品接口. .. 网 API是一致的，文档齐全，被数百万人使用.

通过MSDN, StackOverflow和成千上万的论坛和博客提供的知识库是巨大的. 在我多年的发展中 .网, I cannot recall an instance where I would get stuck for long on a framework bug; each time, 有人已经经历过了, 研究并发布了一个答案, 并不总是我想要的答案, 但仍有一些东西推动着我前进. 在即将到来的2015年版本中， .. 网 Core将是开源的，可以在非windows系统上使用.

原因2:ASP.. 网的发展

回顾10年前传统的web到数据库的微软堆栈, 看看哪些部分经受住了时间的考验，哪些部分消失了，这很有趣. 而微软堆栈的后端基本保持不变(我们仍然使用相同的模式和组件集), 比如依赖注入, 任务, Linq, EF或ADO)前端, ASP.网的一篇文章，看到了一个根本性的转变，从“用微软的方式去做”.e. Web Forms)“按照自己的方式来做，并使用ASP.. 网作为平台.今天，ASP.. 网是一个基于mvc的框架，具有健壮的身份验证基础设施, 它集成了许多非微软的技术，比如Bootstrap和AngularJS. ASP.网站点在各种形式的因素上看起来都很漂亮, 从手机到台式电脑, 它的Web API功能使得公开Web服务变得轻而易举. 该框架已经开放源代码很多年了, 所以如果你在一个问题上卡住了, 源代码可在GitHub上获得. ASP.. 网已经改变了，而且变得越来越好.

原因#3:Web API的简单性和WCF的强大性

我最喜欢的一句话是Alan Kay说的, “Simple things should be simple; complex things should be possible.当Windows通信基金会(WCF)于2006年首次推出时, it was anything but simple; behaviors, 端点, 绑定是压倒性的. So, 微软发布Web API, 一个易于使用的框架，使暴露HTTP web服务变得轻而易举. 通过几行配置，您的API就变成了安全的“行业标准”web服务.

如果您的用例不符合“标准”模式, 并且您需要完全控制您的API如何通过网络公开, 你总是可以依靠WCF. 有无数的配置选项和钩子, WCF允许您自定义序列化数据, 日志, 拦截, 路由信息, 使用点对点和排队, 还有更多. Web API, 与WCF一起, 实现了Kay引用的两个原则:如果你需要一个简单的web服务, you are done in minutes with Web API; if your service requirements are complex, 使用WCF，“所有”都是可能的. 这两种技术提供了对服务场景的全面覆盖，并预先打包了 .微软网络框架.

原因#4:SQL Server一如既往的可靠

多年来, 这似乎是新开发语言的浪潮, 框架和模式通过前端和中间层出现，而不涉及数据库后端. 毕竟，老式的“SELECT”在今天仍然像20年前一样被广泛使用. 我想这是因为许多公司将数据视为其业务的核心, 保持核心的完整性远远超过在数据库层尝试“新事物”的兴奋感.

SQL Server的主要功能是作为一个数据管理员，为事务提供了大量的特性, 参照完整性, 备份, 镜像和复制, 但让SQL Server在竞争中脱颖而出的是它与微软其他堆栈的整合程度. 为了快速发展, 有实体框架, 当前为版本6, 已经过了青春期，并很好地履行了精简数据访问的承诺. 如果你需要计算能力 .. 网框架与SQL Server一起加载在进程中，这意味着您可以嵌入 .网代码作为存储过程、函数或聚合而不牺牲性能. 这与SQL Server 2014自带内存表的事实相结合, 并且您可以提出一些非常漂亮的实时解决方案，这些解决方案仅使用SQL和常规表是不够快的. 在这个行业工作了多年之后，SQL Server仍然是我最喜欢的rdbms.

原因5:它很容易测试

那么多次, 在企业IT部门工作, 我看到软件变成了这些不可触摸的黑盒子，因为没有测试, 没有人想打乱代码，因为害怕“破坏其他东西”.“那, 我研究过有上千个测试的系统, 这是一种很棒的感觉，能够告诉企业, “是的, 我们可以做出这些改变,在软件发布多年之后. 微软堆栈在设计时就考虑到了可测试性. ASP.. 网 MVC有用于依赖注入的钩子, 在版本5中, 依赖注入将包含在框架本身中. 在中间层, 这是一个类似的故事:我们使用依赖注入来将实现与接口分离, 哪一种方法可以让我们在测试时将生产类型与模拟类型交换. 甚至在数据库端也是如此, SQL Server数据工具附带了用于针对存储过程层进行测试的模板. 测试是当今软件开发过程中不可分割的一部分, 微软的堆栈为这个新的现实做好了充分的准备.

原因6:精心设计支持生态系统

当涉及到支持, 有多种选择很好, 从社区论坛开始，到一个实际的人在你的服务器上工作结束. 微软产品的在线生态系统是业内最大的之一. 毕竟, 微软是比尔·盖茨创立的, 他自己也是软件开发人员, 谁认为开发者的广泛采用是微软产品扩散的关键. 这意味着要为这些开发者提供大量的支持.

微软是最早鼓励员工在博客上介绍他们正在开发的技术的公司之一, 虽然其他行业也在迎头赶上, 的数量和质量 教学 今天，直接来自微软的视频、指南和文章仍然令人印象深刻. 这一层高质量的在线内容得到了大量基于社区的支持生态系统(如StackOverflow)的补充, 哪些在内容质量上不一致, 但, 不过, 比没有有用多了.

最后，总是有一个选择，拿起电话和微软的支持. 我很少使用它, 但当微软开发人员分析核心转储时，出现了一些生产紧急情况. 支持选项的范围显然是支持使用微软堆栈的一个因素.

原因7:微软坚持自己的产品

几年前, 选择微软Silverlight作为应用程序的前端似乎是一个合理的选择, 但现在情况已经不同了. 随着移动趋势的全面发展和JavaScript框架主导前端领域, Silverlight is no longer a feasible option; 不过, 到2021年，微软仍将支持它. 微软坚持自己的立场, 对于我们这些不得不做出技术选择的人来说，没有一个神奇的八球来告诉我们未来哪种技术趋势将主导软件领域，这是好事吗. 使用微软的堆栈可以确保将时间和金钱投入到将得到支持的技术上，即使它不受行业的青睐.

原因8:Visual Studio Umbrella

十年前, 我花了大约50%的时间在Visual Studio上，另外50%的时间在其他工具上. 今天，这种分裂压倒性地支持Visual Studio. 微软将Visual Studio作为托管ide的一站式解决方案的愿景正在实现，许多微软和非微软的产品都提供了与Visual Studio的某种程度的集成. 从使用SQL Server Data 工具开发数据库到使用Xamarin编写iPad和Android应用程序, Visual Studio提供了熟悉的开发人员体验和一致的用户界面. 使用微软 Azure也是如此, 包含从数据库托管到移动服务的各种服务的云平台.

Visual Studio模糊了分布式云基础设施的复杂性，使得开发云应用程序的体验与开发不在云中托管的应用程序的体验一致. 在Visual Studio的保护伞下，所有的部分似乎都很好地结合在一起, 使整个开发过程非常高效.

微软堆栈技术:两全其美

今天，与10年前相比，编写高质量软件的选择要多得多. 这当然是一件好事，因为竞争迫使大型企业, 比如谷歌, 苹果, 亚马逊和微软, 继续创新，不要自满. 而微软则被过去十年的科技发展推下了顶峰, 该公司已经表明，它愿意适应并适应当前技术趋势的现实. ASP.. 网采用了其他技术和方法, 其中很多都是开源的, 随着最初的Web表单逐渐成为历史. 的 .. 网框架继续发展，为多线程和多核计算的库开辟了新的领域. 2015年即将发布, 该框架的核心将是开源的，并且可移植到非windows平台, 这是朝着包容性和透明度的方向迈出的一步.

这些受欢迎的改进来自于一个长期建立了发布经过测试的软件流程的公司, 文档化和支持. 使用微软技术栈带来了使用现代语言和框架的兴奋感，以及由拥有数十年开发行业经验的软件巨头支持的稳定性. 这就是我今天推荐微软开发栈的原因.