如何评估web服务框架

Question

我正在尝试评估不同的web服务框架，用于.Net中的API开发。到目前为止，我一直在研究的框架是：

• ServiceStack
• MVC
• NancyFx

我试图在框架之间找到一些常见的谈话点，这样我就知道在选择一个框架时应该寻找什么。到目前为止，我的谈话要点是：

• 框架信念和原则
• 框架的体系结构(客户端和服务端)
• 框架为您提供的堆栈
• 在堆栈(插件等)中开发的方便性
• 端到端性能基准
• 可伸缩性基准
• 框架文件可用性
• 框架支持(跨平台等)
• 定价
• 总体结论

，有人能想到我应该考虑的其他事情吗?在研究结束时，我希望详细地写每一个框架，并比较一下为特定目的选择哪一个框架。任何帮助都将不胜感激。

Answer 1

端到端生产力--服务的核心要素是提供最终为其消费者提供某种价值的服务。因此，消费服务的端到端生产力也应该被强烈地看作是服务可以从客户那里消费的容易程度和消费它们的最小努力，最终为客户提供更多的价值，这通常比开发服务本身的生产力更有价值，因为它的价值在其多个消费者中成倍增长。随着许多服务的不断发展，更新服务的开发工作流程以及确定更改的内容(即它们是否具有静态API)的易用性也会影响到客户端的生产率。

Interoperability --服务的另一个目标是互操作性，以及如何从异构环境中使用服务，但是在许多情况下，通过MQ发送API请求更合适，因为它比HTTP、时间解耦、自然负载平衡、解耦端点、改进的消息传递工作流和错误恢复等更有价值。还有许多企业(和企业产品)仍然只支持或强制使用SOAP，因此拥有SOAP端点和支持XSD/WSDL元数据也是有价值的。

Versionability -一些API设计自然更适合于版本控制，在这种版本控制中，进化的服务可以在不破坏现有服务使用者的情况下得到增强。

可测试性和可移植性--您还需要比较一下服务可以测试和模拟的容易程度，以确定创建集成测试有多容易，以及它是否需要新的知识和基础设施，以及它支持并行客户端开发(当前端和后端团队并行开发解决方案时，这一点很重要，因为在开发之前可以设计和商定服务的API契约，以确保它在实现之前满足必要的需求，然后前端和后端团队可以相互独立地实现它们。如果服务还没有实现，那么客户端需要“模拟”服务响应，直到它们已经实现为止，然后在它们实现后切换到使用真正的服务。

可学习性开发服务是多么直观，所需的认知和概念开销的数量也会影响生产力和对服务框架的工作方式和功能进行推理的能力，以及它对解决方案的总体复杂性和团队做出影响性能和可伸缩性的知情实现决策的能力，以及提高新开发人员学习解决方案所需的努力。