InfoQ: 你觉得在哪些场景中，WCF/Web API/MVC也许比ServiceStack更适合呢？ Demis：MVC是一个功能全面的web框架，它更适合于那些拥有大量的服务端生成内容的网站。而ServiceStack更专注于为那些拥有一个重量级服务组件的web应用提供优秀的体验，例如单页面应用就经常会用到一些尖端的JavaScript框架，比如Backbone.js、AngularJS，还不断有令人兴奋的新贵加入这个阵营，例如Dart的WebComponents。我们也期望我们所提供的集成的Mardkdown与Razor视图引擎能够吸引那些托管大量内容与文档的网站。 如果你在开发服务端驱动的系统时愿意相信遵循REST和HATEOAS约定所带来的价值，那你应该使用WebAPI，并遵从那个社区的开发文化。而如果你希望为你的服务提供最大化的功能，并且将终结点托管在SOAP、MQ（即将支持TCP）上，那ServiceStack会是更好的选择。 如果你是一位MVP或是一位微软金牌合伙人，那你会自然地选择继续坚守MVC与Web API技术路线，因为微软会让你一路跟随他们的技术，从SQL Server到AppFabric，最后到Windows Azure。而我们看到了支持伸缩性更强、性能更好的平台所带来的更大的价值，我们将把精力集中在这些平台上，在Amazon的EC2以及Google Compute Engine这样的纯Linux云平台运行我们的软件，提供对替代的关系型数据库解决方案OrmLite、以及各种高性能NoSQL解决方案的支持，并且会继续在Redis以及云端数据存储的集成适配器上加大投入力度。 InfoQ: 微软之前也和一些开源项目（例如jQuery和NuGet）达成了合作，而且像Scott Hanselman这样的微软员工看起来也对在微软技术平台上采用优秀的开源解决方案表现得非常开放 – 你觉得这种合作会在整体上为.NET社区带来什么好处吗？ Demis：作为项目领导，我已经将ServiceStack作为一个开源项目运行了4年，打造一个繁荣的开源.NET社区一直是我所非常关心的事，虽然我觉得到目前为止，微软与现有的开源项目的合作还不能让我竖起大拇指，尤其是在.NET方面。目前来看，他们似乎只会在直接竞争失败后才会采用开源的类库。比方说，早在微软正式采用jQuery之前，大多数JavaScript开发者就已经抛弃ASP.NET AJAX JavaScript框架而转投jQuery的怀抱了。 当NuGet项目刚刚发布的时候，它就由于缺乏对现有的开源解决方案的支持而遭受批评。但总体而言，我认为NuGet是微软所提供的一个很有帮助的贡献，由于它在VS.NET中提供了一个界面，使得开发者可以方便地引用外部的构件，这就减少了使用开源框架的各种麻烦。自从ServiceStack类库发布在NuGet上以来，我们已经看到了大量的应用，最近的18个月中它已经有超过20万次下载了。 而在开源.NET类库方面，微软仅仅在今年早期推出Web API的时候，首次采用了开源的JSON.NET这个.NET类库。和其它公司一样，对微软来说，当出现了更优秀的开源软件时将其纳入麾下是个正常的选择，尤其是微软自己之前提供的JSON序列化工具在对日期数据的格式化方面没有选择和JSON.NET一样遵循标准，而且在性能上也比不过ServiceStack的序列化工具。对于一个像JSON.NET一样的单独的类库来说，这种方式让它的使用度产生了一次爆发，光是下载量就已经超过其它所有JSON序列化工具的总和了。但这对于对其它类库的应用并没有带来一种光环效应，事实上反而带来了负面的影响。当它成为了这方面的默认类库之后，就意味着.NET开发者如果打算与其背倒而驰而去采用其它替代方案，那他们就必须提出一个合适的理由。选择我们的产品作为替代方案其实已经有了一个非常好的理由，因为它是.NET平台上最快的JSON序列化工具，这使它在那些关注于性能的公司中非常流行，像StackOverflow就采用它处理JSON。但我们在市场上虽然处于第2位，却离头名有了巨大的差距，我们的市场占有率只是JSON.NET的14分之1，而排名第3的开源JSON序列化工具更是只有头名110分之1的市场占有率。在开发高性能的服务时，序列化的性能是至关重要的。因此我们一直将我们的序列化工具视作核心组件，我们承诺将尽力将它保持为最好与最快的序列化工具。 除了JSON.NET之外，我相信DotNetOpenAuth是在那之后唯一一个被采用的开源.NET类库了，这对于使用者来说就可以避免重复发明轮子的尴尬了。看起来微软现在确实是对于采用他们感兴趣的、更优秀的开源类库持比较开放的态度了，虽然这一改变并没有为整个社区带来太多令人注目的好处。 但还是要感谢微软在商业模式上的变化，他们已经将更多的东西开源，Windows Azure相关的大多数类库与框架就已经开源了。这是件大好事，一是它降低了每个人采用新软件的门槛，二来它也为减轻Mono社区的负担的带来了直接的好处，因为Mono之前每次都要消耗精力去重新实现相同的功能，而现在他们则可以使用微软的开源版本的软件，并且还可以为其贡献各种补丁包，以改善它对Mono的支持了。F#就是这方面一个很好的例子，它完全开源，并且对Mono的支持程度之高也令人感到吃惊。实际上我个人在F#方面做的各种尝试都是在Mono/OSX平台上用Sublime.Text完成的。微软开源产品之一的SignalR更是拥有了一个活跃的社区，并且在GitHub C#/.NET的版块上跃居前列，而基于SignalR框架的JabbR.net聊天室也成为了.NET开发者的主流选择。 有一些开源框架首先将其它平台上的流行功能引入到.NET平台上，在微软推出一个完整的解决方案之前填补了某方面的功能空白，但是这些开源框架可谓命运多舛。比方说，在MVC MonoRail框架推出了好几年之后，微软推出了自己的ASP.NET MVC框架，这让该社区的成员感到非常泄气。微软近期在尝试在Entity Framework中加入的ORM Data Access Layer也对之前拥有一个活跃社区，并且在这方面处于领先地位的ORM NHibernate产生了负面的影响。尽管EF的速度比起其它任何一个开源的.NET ORM框架都要慢上好几倍，但它的下载量仍然超过了其它所有ORM框架的总和。与之类似的是，微软现在一再重复地创建和发布新的服务框架，许多技术不断出现随后又被淘汰，包括.asmx、CSF、WCF、WCF/REST、WSE、WCF DataServices、WCF RIA Services以及最新的Web API。而在这些年前，已经有许多可替代的开源服务框架提供了足以取而代之的能力。如果不是微软的举动有着许多不确定性，在许多领域都会出现更多的合适的替代方案，以提供给更广大的.NET社区。 .NET平台有着它独特的地方。微软的推广方式包括合作伙伴频道、传道士（evangelist）、MVP奖励项目，并且完全掌控VS.NET的各个方面。这种方式让微软对大多数开发而言看起来就是整个.NET生态系统的权威发言人，这使得它们完全控制了.NET平台上的各种思想。在过去，微软只是在利用这方面的影响力去推广他们自己的类库与框架，这让许多使用.NET的公司不愿意脱离微软的技术范围而去寻求其它替代方案。我们也在很多场合承受着痛苦：许多开发者希望在工作中采用ServiceStack，但由于微软官方的解决方案的存在，他们无法说服他们的公司去采用其它框架，即使它们展现了各种有用的示例与更好的性能指标。我相信其它许多开源类库与框架也遭受过类似的命运。 整个大环境导致了开源社区难以振兴，而C#/.NET的流行程度相对也有所下降，近期已经滑出了GitHub（这里可以被视为开源之家）的Top 10语言的榜单，但仍存在的少数开源.NET项目挽回了这种劣势，并且依靠它们的独立技术建立了围绕它们的社区。Mono项目是目前为止最耀眼的明亮，它的发展情况良好，并且在社区中具有很多优秀的开发者，这一点为.NET应用程序运行在主流的其它平台上，例如iOS、Android、Linux及OSX作出了很大的贡献与价值。对许多项目来说，提供对Mono的支持能够最大程度上扩展它们的应用范围。而我们的最大动力之一就是永远保证ServiceStack在Mono上的第一等支持。不仅Mono，NancyFx与ServiceStack也尽了它们最大的力量去壮大开源.NET社区，它们都各自吸引了超过200位贡献者，这些贡献者中有许多都是首次为开源项目贡献力量。MonoGame与RavenDB是另两个值得关注的项目，它们正在逐渐流行起来。我们对于能够成为GitHub上排名最高的项目之一，以此促进.NET的开源活动感到非常自豪，但我们也期望能够看到更多的吸引人的.NET社区发展壮大，并且鼓励更多的开发者去尝试开源开发的模型。 我相信微软的合作模式所带来的最大好处，是让那些可作为替代选择的类库与框架走入了人们的视线。在这种情况下，建立一个更大的开源.NET社区比起让微软独自提供更多的功能能够带来更多的好处。在这一点上，Scott Hanselman在他那著名的个人博客上多次提到了各种开源类库与框架，以一己之力让大众了解到了这些信息。除了Scott之外，Glenn Block也在其非常活跃的个人twitter帐号@gblock上推广了许多框架。如果微软能够投入更多力量去提升公众对这些项目的认知度，这将鼓励更多的.NET开发者投身开源世界，并给予那些现有开源项目的开发足够的动力，促使他们继续增强自己的项目，这两点对于维持开源社区的繁荣都是至关重要的组成部分。 作为一家利益驱动的公司，微软需要一些财政上的激励，以促使它们去推广各种其它的类库与框架。我希望某个组织能够建立一个成功的商业案例，以证明建立一个繁荣的开源.NET社区将鼓励更多的开发者选择.NET，并且因此为Windows服务器工具与Azure服务带来了更多的潜在客户君。即使微软只在Windows Azure的运行环境中推广一些其它的.NET框架，例如它们对Node.js、Python以及Java的支持，这也是一种良好的改进。想要完全壮大开源.NET，需要微软从心底里真正地将开源.NET社区的成长视为它们打算积极进取的目标，到了那时微软就会在它们的MVP奖励计划中认可开源的贡献，并在合作伙伴频道中对其进行推广。我相信如果在未来微软仍旧无动于衷的话，那Mono项目就是鼓励更多的.NET开发者加入开源的最后希望了。 InfoQ: 你最近在某个论坛中有这样一条留言：“我希望明年会发展的更好，我已经计划好了一些东西，它们会让你放弃选择其它框架。”你能详细地说明一下你已经为未来计划好了哪些特性吗？ Demis：呵呵，我是有意在论坛里有所保留的，这样当我们宣布这些功能时就能为人们带来极大的震撼。因为我相信我们能够推出一些独一无二的、值得关注的产品与特性。但总的目标依然是提供一个有价值的服务框架，并且实现WCF中其余的有用功能，以进一步提高ServiceStack的竞争力。我们已经公开了一部分打算在明年推出的特性，包括以下内容：
InfoQ: Demis，非常感谢你抽出时间进行这些访谈。 关于受访者
查看英文原文：Interview With Demis Bellot, Project Lead of ServiceStack - Part 2 |
Demis Bellot是来自Stack Exchange的一位开发者，他维护着StackOverflow Careers 2.0的后台网站以及基于ServiceStack创建的MQ服务。他同时也是ServiceStack的创始人以及项目领导。
