如何使用Microsoft技术栈

Microsoft技术栈最近有大量的变迁，这使得开发人员和领导者都想知道他们到底应该关注哪些技术。Microsoft本身并不想从官方层面上反对Silverlight这样的技术，相对而言他们更喜欢让这种技术慢慢淡出人们的视线，不然局面可能会更加混乱。若是你想了解该问题的答案，那么能够查看“.NET业务应用程序技术指南”这个小有名气的文档。该文档发布于去年早些时候，它深刻探讨了Microsoft打算在哪些领域付出努力，咱们应该回避哪些技术等内容。

下面这个概要图是咱们探索Microsoft及其相关技术的一个很好的起点。

(单击放大图片)

 

尽可能早日放弃Silverlight和Flash

虽然WinForms和Web表单这些旧的.NET技术依然占有一席之地，可是Silverlight和Flash这样的RIA容器绝对是出局了。正以下面图5-15所展现的，Microsoft并不想空等着Silverlight 5所计划的10年生命周期。他们已经打算在2015年末放弃RIA容器。

 

高端应用程序更倾向于彻底使用本地技术；而低端应用程序则指望HTML5的能力持续发展。尽管没有将开发人员推向具体的某一种技术，可是对于这种转变咱们必需要注意的事情是：

• 若是你正在过渡到本地应用，那么你能够以生来就能够在任何Windows设备上运行的XAML/.NET做为目标，这样你就可以利用本身已有的技能甚至是代码了。可移植类库还容许你在不一样的平台之间共享类库，包括Silverlight。
• 对于基于浏览器的HTML5应用而言，Microsoft提供了主要的工具和框架，它们可以帮助你基于最新的标准建立可用于任何设备的应用程序。Silverlight和HTML的互操做性还容许你经过混合应用程序进行逐步的过渡。

移动

Windows 8商店有三个相等可是不一样的选项

就Windows 8商店应用而言，Microsoft过去一直不肯意将开发人员推到某一种具体的技术栈上。这个政策如今也没有发生变化；在.NET/XAML、C++和JavaScript/HTML5这些技术之间选择的首要标准是开发人员最熟悉哪一种技术。

除此以外，他们还提到了C++，由于它具备性能优点。可重用性并非很受关注的一个点，由于这三个平台都可以在Windows Phone和Windows桌面之间共享代码和资源。

本地选项适合Windows Phone

Windows Phone推荐的技术是.NET和C++。再次重申，须要注意一下C++的性能优点，可是他们说的最多的仍是开发者应该使用本身更加熟悉的技术。

尽管Windows Phone兼容PhoneGap/Apache Cordova，可是这并无被说起。推测起来缘由多是他们认为在小设备上PhoneGap的性能比起.NET或者C++要差。在2013年度的Build大会上性能无疑是最重要的话题，超出了诸如通常可用性、可视化设计和深度OS集成等其余话题。

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

若是你想选择一种可以在全部移动设备上运行的、基于Web的解决方案，那么有多种选择。使用Modernizer的ASP.NET MVC是基线推荐方案，你可以使用它建立单页面应用程序（ASP.NET SPA）。Microsoft对SPA的见解是它更像是一种设计模式而不是技术，同时Microsoft还极力推荐使用Knockout和Breeze这两个类库。

为了快速地装配CRUD风格的应用程序，LightSwitch被列了出来。虽然该框架几乎没有对HTML渲染进行控制，可是却可让开发人员没必要为各类各样的屏幕大小构建布局，减小了工做量。

ASP.NET Web页面是为移动Web提供的第四个选项。它基于Razor语法，为开发者提供了与PHP和传统ASP等脚本语言类似的开发体验。

指南中并无说起比较老的ASP.NET渲染工具箱——Web表单。虽然该技术依然在积极的开发中，同时从理论上说它也可以渲染设备特定的HTML，可是在实践中Web表单并无发挥其真正的潜力。它所渲染的HTML和JavaScript好像比较低效，此外其高级功能所必须的view state能快速地压垮一个手机的网络链接。

服务

由于大部分应用程序都依赖于外部的数据存储和处理，因此服务器端开发依然是一个很是重要的考虑因素。Microsoft认为如今有6种可行的技术选项。

首选：ASP.NET Web API

根据Microsoft所提供的信息，新项目的默认选择应该是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这个一度被认为已经死亡的技术看到了再度焕发生机的但愿。

关于做者

Jonathan Allen从2006年开始就一直在为InfoQ撰写新闻，他如今是.NET专栏的责任编辑。若是你想为InfoQ撰写新闻或者教育性的文章，能够联系他：jonathan@infoq.com。

 

查看英文原文：What to Use on the Microsoft Stack

查看中文原文：http://www.infoq.com/cn/articles/Microsoft-Stack-2013