如何处理有关WCF与Web API的技术争论？

我现在正在管理一个由15名开发人员组成的团队，而我们在选择技术时陷入了困境，该团队被分为两个完全相反的团队，就WCF与Web API的使用进行了辩论。

支持Web API使用的团队A提出了以下原因：

1. Web API只是编写服务的现代方式（Wikipedia）
2. WCF是HTTP的开销。这是TCP，Net Pipes和其他协议的解决方案
3. 由于[DataContract]和[DataMember]以及这些属性，WCF模型不是POCO
4. SOAP不像JSON那样可读性强
5. 与JSON（通过HTTP传输）相比，SOAP是网络的开销
6. 没有方法重载

支持WCF使用的团队B说：

1. WCF支持多种协议（通过配置）
2. WCF支持分布式事务
3. WCF有许多很好的例子和成功案例（虽然Web API仍然很年轻）
4. 双工非常适合双向通讯

这场辩论仍在继续，我现在不知道该怎么办。我个人认为，我们应该仅在正确的使用位置使用工具。换句话说，如果我们想通过HTTP公开服务，则最好使用Web API，而在TCP和Duplex方面则要使用WCF。

通过搜索互联网，我们无法获得可靠的结果。支持WCF的职位很多，但相反，我们也发现有人对此表示抱怨。我知道这个问题的性质听起来可能有争议，但是我们需要一些好的提示来决定。我们处于一个偶然地选择技术可能会让我们后悔的时机。我们想睁大眼睛选择。

我们的用法主要用于Web，我们将通过HTTP公开我们的服务。在某些情况下（例如5％到10％），我们可能需要分布式事务。

我现在应该怎么办？如何以建设性的方式处理这场辩论？

当双方都有很好的论据，而对这个问题的意见过于强烈而无法达成共识时，作为经理的您需要做出决定并结束辩论。否则，它将绕圈转，并进一步巩固所有参与者的立场。您等待的时间越长，“失败”的一方越难接受失败并有效地处理结果。

写下所有参数，重视它们对项目的重要性，然后做出决定。如果您做不到，请掷硬币。您的项目很可能使用任何一种技术都可以成功完成，而浪费宝贵的时间进行不必要的辩论只会花费不必要的金钱。

假设双方在所有论点中都是100％正确的，那么哪个重要呢？

由于[DataContract]和[DataMember]以及这些属性，WCF模型不是POCO

你关心？您是否打算做一些需要POCO的事情？

WCF支持分布式事务

再说一遍，这是您将要使用的东西，如果因为走了另一条路而没有，就需要构建吗？

基本上走到哪一个的心脏：

• 提供所需的一切（如果两者都不提供所需的一切，则您必须要做的工作最少）。
• 提供最少的垃圾，您将不会使用，但无论如何都必须忍受。

提出的任何与您需要完成的事情无关的论点都是无关紧要的，不应将其作为您的决定的考虑因素，并为将来的扩展留出了一定的空间。

放两分钱

作为经理，您应该要求队友牢记Yagni原则。这将有助于减少两个团队提出的原因清单。

我们的用法主要用于Web，我们将通过HTTP公开我们的服务。在某些情况下（例如5％到10％），我们可能需要分布式事务。

与其研究分散的交易，不如考虑使用补偿。

最后要考虑的是学习曲线。根据项目的期限，作为经理，您应该能够决定是否可以开始学习新技术。

如果您有很多时间浪费，那就参加某种创新日，其中A团队和B团队将有一天根据相同的要求提出概念证明。

顺便说一句，对那个说“ 由于[DataContract]和[DataMember]以及这些属性，WCF模型不是POCO ”的人，告诉他POCO通常是指域实体，公开它不是最佳实践您的域对象面向任何类型的客户端，这就是DTO的目的。

我现在应该怎么办？如何以建设性的方式处理这场辩论？

首先，远离主观性。在您的WebAPI团队的争论中，我发现“ Web API只是现代方法” *，“由于那些属性，WCF模型不是POCO”和“ SOAP不像JSON那样易读易懂”，即使不是很明显的错误。 ，这将不利于做出决定。

因此，该怎么做：确定您想对服务做些什么，然后选择一种能够以最小的痛苦适应该目标及其可维护性和可扩展性的技术。您可以通过简单地研究要使用的框架是否支持任何给定的方面来做到这一点。

有趣的阅​​读材料：

• Mvc 4与Wcf Web Api
• WCF或ASP.NET Web API？我在这个问题上的两分钱
• WebAPI还是WCF？

*：请注意，您为此参考Wikipedia，其中引用为：“ Web 2.0 Web应用程序已从基于SOAP的Web服务的面向服务的体系结构（SOA）转向更具凝聚力的RESTful Web资源集合”。这是从网页上使用您的服务时的用法示例。使用WHttp，也可以使用WebHttpBinding轻松完成此操作。它没有说“为此使用WebAPI”。

如果此问题超出“如何管理讨论”范围：如果非Web客户端要使用服务，我将使用WCF，因为它的元数据允许非常容易地生成强类型的客户端。

除了团队管理，您不能选择一个。您需要查看每个Web服务的用途，并对应用程序的特定部分使用适当的技术。这就像团队使用实体框架时禁止存储过程。

我们的用法主要用于Web，我们将通过HTTP公开我们的服务。在某些情况下（例如5％到10％），我们可能需要分布式事务。

然后在WCF中编写那些5〜10％的Web服务。如果要在其他项目中内部引用该服务，则无需争论。导入WCF合同以创建客户端代理的功能的优点尚未公开。它使整体集成，效率和类型安全性提高到一个全新的水平。

您在Asp.net网络api中编写用于公共api（也许）/ Ajax请求的内容。

如果只是页面特定的ajax调用，则可以使用Asp.Net MVC。

不要选择，拥抱所有人。WCF和Asp.net Web API服务于不同的目的。没有人说水果沙拉中不能同时含有苹果和橙子。试图在另一个场景中选择一个场景并将其推倒只是纯粹的懒惰。

几个月前，我们的团队进行了类似的讨论。对于我们而言，决定性因素取决于我们如何创建和实施每种技术。由于我们已经在构建MVC应用程序并使用Knockout.js进行数据绑定，因此我们有效地使用了MVVM，而控制器只是作为数据的API。

这使我们可以将本项目对技术的使用分类如下：

• Web API将用作敲除和Ajax调用的API，从而使它们成为MVVM模式的命令。我们针对Web应用程序的业务逻辑通过许多类，存储库和工厂包装在这一层后面。
• 然后，将WCF用于我们的数据存储，不仅从数据库中公开该网站的数据，还公开了其他任何使用公开数据的站点或服务的数据。

尽管这可能不是一种流行的或超级技术的应对方法，但首先确定您需要的东西以及该技术将如何或是否会有所帮助，才是帮助我的团队确定在哪里使用哪种技术的原因。

换句话说，如果我们想通过HTTP公开服务，则最好使用Web API，但在涉及TCP和Duplex时，请使用WCF。

那将是最合理的方法。在同一个Web应用程序中同时具有WCF和WebApi服务，这两种服务都有不同的用途。

只是为了纠正一些参数：

由于[DataContract]和[DataMember]以及这些属性，WCF模型不是POCO

在许多情况下，WCF模型可以在没有数据合同/数据成员属性的情况下工作。

SOAP不像JSON那样可读性强

事实并非如此，但是WCF Web服务通常携带纯XML而不是过分的SOAP。这绝对是可读的。

WCF的一个论点是：如果有WSDL，几乎所有技术中都有大量工具可以根据元数据创建代理。另一方面，JSON Schema尚未得到所有广泛的支持。

为什么不采用WCF数据服务呢？使用WCF的强大OData / webapi样式查询和可用性，以及返回的功能还JSON不错。同样，如果您有一个不错的自动wcf托管代码，Wcf也不错，如下所示：

https://github.com/ImaginaryDevelopment/MvcOdata

我要说的是，它们之间并没有什么不同，只是当我们WebApi在前端和WCF data services中间层使用时，WebApi抛出了诸如字符串包含或字符串匹配odata运算符之类的简单东西。

优秀的架构师会延迟技术决策，直到绝对必要地做出决策为止。

换句话说，在客户端需要实际连接之前，不要做出决定。您可以构建经过全面测试的服务层，而无需实际在其上放置传输/通信机制。95％以上的工作可以在框架外部的适配器“之下”完成。

是时候将这些服务提供给远程客户端了，您可以选择现成的最流行的框架，并在通用服务层上编写薄包装。

糟糕，如果您的“真实”服务层做得很好，您甚至可以花最少的钱尝试几个包装器。

无论如何，那是教条主义的答案。 在实践中，您可能想选择最简单的工具以方便进行早期和频繁的集成测试-但仍要限制对它的依赖，并严格将其视为真实服务上的简单通信层。

如果采用这种方法，您可能会发现自己选择了最简单的工具来最初使用，没有人会大惊小怪，因为团队知道他们以后可以在需要的情况下以最小的努力实现更复杂或新潮的工具或框架。

因此，我现在面临着同样的选择，我问自己，我们的团队目前正在使用WCF的哪些功能子集。我们使用不同的协议吗？否。我们使用交易支持吗？否（尽管我们使用自定义的最终一致性机制）。我们使用双工吗？没有。

为什么我们要使用Web API？更加容易的前端集成（删除了现有的其他服务层），SignalR用于推送对客户端的答复，缓存GET。

可能是，可能还有其他原因：)还有，留在WCF的原因。

如果我在您的位置，我将从检查您的团队能力开始。如果您团队中的每个人都已经知道WCF，而只有一小部分人知道Web API，那么您已经为您做出了决定。

如果有时间，一定要花时间在学习和改善知识库上，而不是以业务需求和公司生产力为代价。

我想问一下您需要支持哪种交互模型？您所需的外部接口是否更像RPC或REST？根据我的经验，它通常介于两者之间，但大多在另一个之间。

您是否正在为.Net中的其他项目使用自己的服务？这可能是您可能要问的最有启发性的问题。WCF确实具有以下优势：能够将您的接口抽象到一个单独的类库中，并能够构建和注入您的客户端。作为对此的扩展，您可以同时将基于WCF的项目与JSON和SOAP / WSDL端点一起挂载。WCF还可以针对您定义的接口提供更好的保证。

就是说，如果您希望总体上拥有来自其他平台XML的客户端，那么，除了简单的JSON终结点所拥有的SOAP之外，还有其他可测量的开销。如果您使用JSON / Web API路线，那么您将需要更好地记录如何与端点和API交互。

通常，我建议编写一个简单的API文档，该文档说明如何提交数据以及如何为单个请求对象结构提供响应。以最通用的方式编写测试用例，并以此进行记录。我建议使用简单的curl语句。然后让您的几个成员使用WCF和Web API来实现此目的。然后查看哪个获胜。

就个人而言，尽管已经使用WCF完成了一些相对较大的项目和实现，但实际上我倾向于最简单的实现，在我看来，它实际上是使用JSON结果以及在Global.asax.cs中用于处理错误条件的某些重写行为的直接WCF。如果API的文档中包含curl语句，并且您可以通过curl示例来使用API​​的所有功能，则可以使用支持Web界面的任何语言轻松实现客户端。这实际上是WCF开始下降的地方。与外部系统打交道时，拥有一个定义明确且带有不可知文件的API优于拥有带有自动化工具的结构。作为其他平台的那些系统的使用者来说。

除此之外，还可以用两种不同的语言来实现您的客户。用C＃做一个客户端，但也用Node.js或Python做一个客户端，看看它们的实际适应程度。仅此练习便可以帮助您摆脱API的空白。