如何使用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为中小型企业编写指南时一直遵循如下目标：

• 提高完成速度，缩短上市时间

• 提高生产效率并降低成本

• 容易开始

• 与市场产品的协作和集成

• 云计算的灵活性以及降低成本的机会

通俗点说，它的意思就是“让事情变得更快，成本更低”。Microsoft提供的这个具体的指南取决于你喜欢什么样的展示模式。

中小型企业Web应用程序

对于快速而随意的CRUD风格的应用程序而言，Microsoft推荐的首选平台依然是LightSwitch。LightSwitch最初被描述为一个针对非专业程序员的工具。许多人将它看作是一个访问的多层替代。但是随着现在Microsoft更多的将其作为一个服务于需要快速推出应用程序的IT部门的工具，这个愿景似乎也已经消失。

接下来要讲的是Web表单。是的，令人尊敬的Web表单依然是新项目推荐使用的技术。Microsoft将其看作是一种折中技术，介于易用但是有限制的LightSwitch和复杂的ASP.NET MVC之间。Web表单包含丰富的数据表格等功能，它依然能够非常好的适用于企业内部的应用程序。

此外还提到了ASP.NET Web页面，但仅仅是简单介绍了一下。如果你认为Web表单所提供的渲染能力依然无法满足自己的需求，那么可以选择ASP.NET MVC。但是Microsoft针对其较长时间的学习曲线提出了警告。

构建Windows桌面程序

虽然所有基于C++的GUI工具集（例如MFC和ATL/WTL）都不在列表上，但是最初的.NET UI工具集WinForms以及WPF依然被认为是可行的选项。这两者都支持现代的理念，例如数据绑定和async/await，同时都能够使用WCF或者SignalR进行双向通信。

在WPF和WinForms之间做出选择之前需要考虑下面几点因素：

首先是难度。比起WPF来WinForms更容易理解，甚至对高级开发者也是如此。WinForms使用非常简单的数据绑定，同时更喜欢传统的MVC或者MVP机制。而对于WPF而言，用户在能够正确地使用MVVP模式之前需要学习一个复杂的数据绑定框架。成功地使用WPF还需要了解资源字典、转换器、ICommands和XAML模版引擎方面的知识。

另一方面，如果你还打算把Windows Phone或者Windows 8 商店作为目标平台，那么你需要学习如何使用XAML。在这种情况下，从WPF入手会让你更有可能在不同的平台之间共享代码。

与常见的WinForms应用程序相比，WPF灵活的渲染引擎渲染的外观更漂亮。当然这也是有代价的，在同等条件下WPF应用程序通常比WinForms应用程序运行的慢。

顺便提一下LightSwitch桌面客户端。好像它并不能提供任何可以在桌面客户端中使用的东西，所以似乎没有太多的理由选择它。

应该避免使用客户端—服务器模式

当Microsoft谈到“客户端—服务器”的时候，他们实际上指的是那些直接与数据库通信的应用程序。尽管他们承认这依然是一个非常常见的模式，但是他们还是希望新项目使用3层设计，在客户端和数据库之间创建一个服务层。与直接访问数据库相比，这提供了更好的可伸缩性，同时还提供了一种可以绕开防火墙及其他障碍物的方式。另外它允许将应用程序移植到数据库驱动不可用的平台上。

"现代化" —放弃Windows桌面

对于如何“现代化”桌面应用程序Microsoft提供了很多建议。下面的建议大部分是有关于做好将应用程序迁移到其他平台上的准备的，但是即使你并没有打算放弃Windows桌面，这些指导对你而言依然是有一定用处的。相关建议的摘要如下：

• 使用模型—视图—视图模型（MVVM）设计模式：Microsoft客户端平台（包括WPF）让我们能够容易地使用MVVM模式构建应用程序。借助于该模式，你能够将展现与状态和行为分离，能够创建可以容易地在不同设备间分享、干净可维护的代码。

• 客户端逻辑使用可移植类库：.NET可移植类库允许我们在多个平台之间共享二进制，例如桌面、Windows商店应用、Windows Phone应用以及其他平台。使用.NET可移植类库实现客户端逻辑能够极大地简化多个平台上多种体验的创建工作。

• 改进用户体验：最终用户当前所需要的理念可以使用.NET针对桌面平台最新的创新来实现。像“快速流畅”、“返璞归真”和“事半功倍”这样的设计原则能够通过在XAML设计中使用现代UI、谨慎地使用动画以及广泛地实现.NET异步编程这些方法应用到已有的桌面应用程序中。

• 将业务逻辑移动到服务器：双层应用程序（客户端/服务器）很难扩展到新设备上。推荐方式是将业务逻辑分离成非常清晰的服务，然后在其他设备上重用这些服务。

• 扩展到云端：一旦将业务逻辑从客户端中分离出来，那么就可以借助于Windows Azure所提供的多种解决方案将其移动到云端。将这些逻辑改造成云服务能够极大地提升已有解决方案的弹性和可扩展性，让它们做好拥抱多种设备的准备。

Android和iOS平台上的.NET

Microsoft正在和一些合作伙伴一起努力，以帮助用户实现现代化。下面是针对每一个合作伙伴所必须说的内容：

• Xamarin 是一个跨平台的开发工具，以Windows、Windows Phone、iOS和Android设备为目标的应用程序能够借助于它分享C#代码。我们能够使用它访问底层API，在设备间重用客户端逻辑代码的同时创建定制的视图。

• ITR-Mobility iFactr 和MonoCross 提供了一个解决方案，该方案允许我们使用C#构建可运行于主要移动平台上的企业移动应用。它提供的抽象UI和企业数据同步等服务能够让业务程序跨多种设备。

• Mobilize.NET来自于Art in Soft公司，它提供了可以帮助用户将遗留应用程序迁移到现代化平台（包括Web、移动和云）上的解决方案和服务。方法是将已有的源码转换成没有运行时的新代码。

• Citrix Mobile SDK for Windows Applications为开发人员提供了丰富的工具箱，能够帮助他们移动化LOB Windows应用或者编写新的能够在中央服务器（Citrix XenApp/XenDesktop）上执行且能够使用Citrix Receiver从任意移动设备访问的触摸友好的应用。

边注：Microsoft正在积极推动Xamarin和MonoCross的事实最终应该会平息一直流传的Microsoft打算控告Mono制造商的谣言。

大型、关键业务应用程序指南

对于大型企业以及它们的关键业务应用程序而言，焦点不再是成本和生产率，而是复杂性管理和服务的质量。下面的指导方针并不适合数据驱动或者CRUD风格的应用程序，从事这种工作的开发者应该参照中小型企业指南。这些指导方针适用于有许多相互联系的部分同时有大量独立子系统的系统。

企业Web应用程序

Microsoft对于这一点的态度是明确的，他们认为关键的Web网站应该使用ASP.NET MVC。唯一的架构问题是是否应该在它上面使用单页面应用程序设计模式。

不推荐使用其他Web技术，例如Web表单和Web页面。因为它们不具备MVC的控制性和可测试性，这反过来限制了可获得的服务的质量。

企业桌面应用程序

对于小型应用程序，Microsoft的推荐列表中依然包含WPF和WinForms。这种场景下他们还增加了C++和Win32/MFC。Microsoft推荐在可以与Microsoft Office相比的这种大型、长期项目中使用C++。这里的一个假定是AutoCAD和Paint.NET在规模方面是不同的。

企业Windows商店/Windows Phone

对于这一场景，Microsoft给出的建议类似于“新兴应用程序模式”部分所给出的建议，除此之外并没有其他内容。这样的态度并没有给用户灌输太多的信心，但是也没有彻底地放弃平台。

模式和实践

在指南的最后，Microsoft并没有继续讨论产品，而是花了大约20页左右的篇幅讨论模式和实践。

控制反转

Microsoft在讨论依赖注入和控制反转容器上花费的大量时间简直令人惊讶。他们列出了9个单独的控制反转容器，其中最主要的一个是非附属于Microsoft的社区运行的项目。应该注意的是，他们列出的许多框架并不是真正意义上的IoC容器，而是依赖注入框架。

Microsoft并没有在这一部分清晰地表述出自己更喜欢组合根（一种DI模式）还是更喜欢服务定位（一种IoC容器模式），所以用户对这两者的疑惑依然存在，这相当令人沮丧，因为正如Mark Seemann所说：他们在本质上是对立的。

Microsoft使用了“单一职责模式”证明依赖注入的使用。例如，他们说SRP可能会导致一个类的构造函数中有15个依赖。为了“解耦”这些依赖，他们建议从构造函数中移除这些依赖，然后使用控制反转容器进行注入。

Microsoft还提到应使用面向切面的编程添加一些其他的间接层，并且进一步注入依赖。

边界上下文和复杂性管理

为了控制复杂性，Microsoft花了几页讨论“边界上下文”的概念。据Eric Evans所说，它的基本思想是将应用程序分成更小的部分，各部分之间使用有限的共享。下面的例子有4个独立的栈，它们使用不同的后端和一个共同的UI。

（单击放大图片）

Microsoft在这一部分的建议非常有道理。对于被识别出来作为关键任务的边界上下文，你可以使用更加昂贵的命令、查询职责分离（CQRS）或者领域驱动设计（DDD）模式以及完全的自动化测试。同时，辅助性的边界上下文可以使用轻量级的、CRUD风格的架构。当然，遗留代码会有它自己的仓库，在那里它们会被隔离并被慢慢替代。

通信和防护

如果想要在边界上下文之间共享信息，那么Microsoft推荐尽可能地使用异步消息。这样每个部分就能够独立工作，即使某个部分失败了也不会影响其他部分。对于简单的场景，命名管道和Microsoft消息队列是比较容易的选项，而更复杂的系统则需要一个服务总线。Microsoft提到了Windows Server服务总线、Windows Azure服务总线以及NServiceBus，但是并没有说更喜欢哪一个。

边界上下文暴露的所有服务都应该有一个防护层对其进行保护。就像应该对参数进行检查以保护公共函数一样，边界上下文的防护层可以让底层的数据存储免受畸形消息的侵害。这一层会验证进入的消息，执行所有必要的转换，并且确保坏数据会被处理和存储。用户可以使用普通的.NET代码实现，但是对于复杂的、有很多频繁变化的业务规则的场景，Microsoft推荐使用规则引擎和集成平台，例如BizTalk。

处理遗留代码

处理遗留代码的第一步是为其创建一个外观层。该外观层应该使用现代的技术，例如持续的、可扩展的缓存，并且应该隐藏旧代码使用的所有模式。随着时间的推移，遗留代码将会被置换，外观层会被重定向到新的服务层。

Microsoft推荐使用所有的.NET 本地、Web和通信框架，浏览器端的Silverlight和.NET Remoting除外。在一些场景下他们还推荐使用C++和JavaScript。像VB 6和传统ASP这样的旧平台根本没有被提及，所以依然在使用这些技术的公司应该尽快地迁移到新技术上。

不出所料，Microsoft继续强调了依赖注入，特别是它们与ASP.NET MVC及Entity Framework的结合。企业试图集成现场和云架构的趋势让BizTalk这个一度被认为已经死亡的技术看到了再度焕发生机的希望。

上述就是小编为大家分享的如何使用Microsoft技术栈了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注行业资讯频道。