如何使用Microsoft技术栈

本期，边肖将为您带来如何使用微软堆栈的信息。文章内容丰富，从专业角度进行分析和叙述。看完这篇文章，希望你能有所收获。 最近微软技术栈发生了很多变化，这让开发者和领导者都想知道应该关注哪些技术。微软本身并不想从官方层面反对Silverlight。相对来说，他们更愿意让这项技术淡出人们的视线，否则情况可能会变得更加混乱。如果您想知道这个问题的答案，您可以查看著名的文档“的技术指南”。NET商业应用程序”。该文档于去年年初发布，它深入讨论了微软打算在哪些领域做出努力，以及我们应该避免哪些技术。 以下概述是我们探索微软及其相关技术的良好起点。 00-1010虽然老了。WinForms、Web Forms等NET技术依然占据一席之地，Silverlight、Flash等RIA容器肯定出局。如下图5-15所示，微软不想等待计划中的Silverlight 5的10年生命周期。他们计划在2015年底放弃RIA集装箱。 高端应用倾向于完全使用本地技术；低端应用期待HTML5继续发展。虽然开发人员还没有被推向一种特定的技术，但是对于这种转型，我们必须注意以下几点： 如果您正在过渡到本地应用程序，您可以瞄准XAML/。NET，它本质上可以在任何Windows设备上运行，这样你就可以使用你现有的技能甚至代码。可移植类库还允许您在不同平台之间共享类库，包括Silverlight。 对于基于浏览器的HTML5应用程序，微软提供了主要的工具和框架，可以帮助您创建可以在任何基于最新标准的设备上使用的应用程序。Silverlight和HTML之间的互操作性还允许您通过混合应用程序进行渐进过渡。

尽量早日放弃Silverlight和Flash

Windows 8 Store有三个相同但不同的选项。 就Windows 8商店应用程序而言，微软一直不愿意将开发人员推向特定的技术堆栈。这项政策现在没有改变；选择的第一个标准。NET/XAML、C和JavaScript/HTML5是开发者最熟悉的技术。 除此之外，他们还提到了C，因为它的性能优势。可重用性不是一个很受关注的点，因为这三个平台都可以在Windows Phone和Windows Desktop之间共享代码和资源。

移动

Windows Phone推荐的技术有。NET和C .同样，我们需要注意C的性能优势，但他们最常说的是开发人员应该使用他们更熟悉的技术。 虽然Windows Phone与PhoneGap/Apache Cordova兼容，但这一点没有提到。据推测，原因是他们认为PhoneGap在小设备上的表现比。NET或c .性能无疑是2013年Build Conference上最重要的话题，超越了一般可用性、视觉设计和深度OS集成等其他话题。

本地选项适合Windows Phone

如果你想选择一个可以在所有移动设备上运行的基于Web的解决方案，有很多选择。使用Modernizer的ASP.NET MVC是一个基线建议，您可以使用它来创建单页应用程序(ASP.NET SPA)。微软对SPA的看法是，它更像是一种设计模式，而不是一种技术。同时，微软强烈推荐使用淘汰赛和Breeze作为两个类库。 为了快速组装CRUD风格的应用程序，列出了LightSwitch。虽然该框架对HTML呈现几乎没有控制，但它使开发人员没有必要为各种屏幕大小构建布局，从而减少了工作量。 ASP。NET网页是移动网页的第四种选择。基于Razor语法，它为开发人员提供了类似于PHP和传统ASP等脚本语言的开发体验。 该指南没有提到旧的ASP.NET渲染工具箱——Web表单。虽然这项技术仍在积极开发中，理论上可以呈现设备特定的HTML，但实际上，Web表单并没有发挥出真正的潜力。渲染出来的HTML和JavaScript看起来效率不高，视图状态这种对其高级功能必不可少的东西，可以快速压垮手机的网络连接。

移动Web：都可以使用，除了Web表单

由于大多数应用程序依赖于外部数据存储和处理，服务器端开发仍然是一个非常重要的考虑因素。微软认为有六种可行的技术方案。 00-1010根据微软提供的信息，新项目的默认选择应该是ASP.NET web API。如果你想开发REST风格的服务。

，或者需要兼容“Akamai、Windows Azure CDN、Level3等”Internet缓存，那么可以使用该技术。

开发者在使用Web API的时候应该关注OData和JSON，前者标准化了REST端点的暴露方式。

第二选择：WCF

与Web API相比WCF被认为是一种更加灵活的选项，因为它并没有与任何特定的传输协议或者消息格式绑定。例如，你能够利用TCP或者命名管道和二进制消息提升性能。缺点是WCF使用起来比较困难，特别是当你想要以JSON或者其他非基于SOAP的格式暴露数据时更是如此。

WCF是面向企业设计的，理念是RPC风格的通信。虽然它也可以使用面向大众的REST风格的设计模式，但是这并不是该场景下的首选项。

WCF和OData

如果你的主要工作是CRUD风格的服务层，同时想要使用WCF技术栈，那么WCF数据服务是一个不错的选择。它与ASP.NET Web API共享OData类库，并且通常会与Entity Framework结合使用。

Workflow服务

Workflow服务是Windows Workflow与WCF的结合。使用它的原因只有一个，那就是你的服务内部已经使用了Windows Workflow。Microsoft认为没有让你选择这个选项的其他原因。

使用SignalR进行双向通信

如果你仅想使用基于.NET的客户端，那么WCF为良好的双向通信提供了很多选项。但是如果你想要的是能够同时支持.NET和基于Web的客户端，那么SignalR是一个非常不错的选择。

根据Microsoft提供的信息，SignalR甚至能够扩展到上百万用户。Web客户端喜欢使用WebSockets，但是可以在必要的时候自动地回退到旧的模式，例如长轮询。

SignalR还有一个针对.NET客户端的类库，允许Web和本地客户端共享服务。

LightSwitch，另一个OData提供者

Microsoft对OData的喜爱程度夸张到我们几乎难以用语言来描述。到现在为止，我们已经看到了用于WCF和Web API的OData，但是这并没有结束。尽管通常情况下我们使用的是LightSwitch的客户端，但是很显然我们还可以使用它的服务器端能力快速地生成一个服务层。

Microsoft宣称LightSwitch不需要任何编码，但是同时也警告说这样会丧失灵活性。

中小型企业应用程序指南

Microsoft为中小型企业编写指南时一直遵循如下目标：