我需要在本地公开一些逻辑作为服务......</p>
向/从逻辑发送/接收的对象非常大，信息很敏感，并且逻辑永远不需要暴露在外部，它仅用于本地服务器。
一些 MVC 开发人员争辩说应该使用 WEB Api 服务公开它——是否值得实现这个？
他们的论点是，使用 Web API，它可以更多地集成到 MVC 中，并且更容易显示结果（我对这方面的事情一无所知），我担心我们将不得不实现复杂的授权并牺牲性能。
没有更适合这种场景的轻量级服务层吗？WCF 命名管道对我来说似乎是合乎逻辑的，或者只是将其作为类库引用——是的，配置文件很痛苦，但不是世界末日。基本上我们只想在本地提供一些逻辑。
Web API 是微软迄今为止最好的高级 HTTP 实现。因此，它以前所未有的方式包含 HTTP，并允许在正常 MVC 下不可能实现的许多灵活性。
内容协商等功能对于任何内部或外部服务都非常重要。
然而，我也会看到 WCF 提供了更好的内聚力，因为它是一个纯 RPC 框架。但它绝对不是轻量级的。我在这里有一个博客，它讨论了这个问题并做了一些比较（无耻的插头！）。
如果您只关心在私有环境中调用方法，那么 WCF 就可以了。但请记住，命名管道/TCP 在某些防火墙条件下可能不起作用。
Web API 丢失的另一件事是合约。Web API 领域中没有 WSDL - 这可能是好是坏取决于您如何看待它。如果您的公司对服务合同非常严格，WCF 是一个更好的选择。
Aliostad 有一些非常好的观点。除了个人经验，我没有太多要补充的。在 WCF 遇到一些严重的配置问题后，我最近使用 mvc 启动了一个 Web 服务，这非常简单。您的问题要求轻量级、简单的实现——在这些方面，答案肯定是 MVC Web API over WCF。
如果你的服务层是面向休息的，你可以看看servicestack。
这个实现起来非常简单，不会牺牲性能，并且允许您通过使用属性（如 ASP.NET mvc 中的操作过滤器）或继承轻松实现安全性。
MVC 或 Web API 是不错的选择。如果您想要更轻量级的东西，请查看http://www.nuget.org/packages/DuoVia.Net，这是我从事的一个开源项目。