我需要在本地揭露一些邏輯作爲服務...簡單的輕量級服務層
的對象發送/接收/從邏輯是相當大的，信息是敏感和邏輯將永遠不需要外部暴露它僅用於本地服務器。
一些MVC開發人員爭辯說，它應該使用WEB Api服務公開 - 這是否值得實施？
他們的觀點是，使用Web API，它更加融入到MVC中，並使得顯示結果更加容易（我對這一方面一無所知），我擔心我們將不得不實施複雜的授權並犧牲性能。
有沒有更適合這種情況的輕量級服務層？ WCF命名管道對我來說似乎是合乎邏輯的，或者只是將它作爲類庫引用 - 是的配置文件是一個痛苦，但不是世界的盡頭。基本上我們只是想在本地提供一些邏輯。
Web API是微軟的'最好的到目前爲止的高級HTTP實現。因此，它像之前沒有HTTP一樣包含HTTP，並允許在正常MVC下無法實現的許多靈活性。
諸如Content-Negotiation之類的功能對於任何內部或外部服務都非常重要。
但是，我還會看到WCF提供了更好的內聚性，因爲它是一個純RPC框架。但它絕對不是輕量級的。我有一個博客here，它討論了這個問題並做了一些比較（無恥的插件！）。
如果你所關心的是在私人環境中調用方法，WCF沒問題。但請記住，named-pipe/TCP在某些防火牆條件下可能不起作用。
您用Web API失去的另一件事是合同。 Web API領域沒有WSDL--根據你的看法，它可以是好的也可以是不好的。如果貴公司對服務合同非常嚴格，那麼WCF是更好的選擇。
Aliostad有一些非常好的觀點。除了個人經驗之外，我沒有更多的補充。我最近使用mvc創建了一個Web服務，在使用WCF發生一些嚴重的配置問題之後，它非常容易。你的問題要求輕量級，簡單的實現 - 答案肯定是在這些方面WCF上的MVC Web API。
如果你的服務層面向休息方向，你可以看看servicestack。
這個實現非常簡單，不會犧牲性能，並且可以通過使用屬性（如ASP.NET mvc中的動作過濾器）或繼承來輕鬆實現安全性。
MVC或Web API是不錯的選擇。如果你想要更輕量級的東西，看看http://www.nuget.org/packages/DuoVia.Net這是我正在開發的一個開源項目。
感謝您的信息，但如果我要求您將顏色固定在桅杆上，您會選擇哪種顏色？ – baileyswalk 2012-04-13 12:06:41
我*親自*選擇Web API，因爲它更好地包含更改，並且我對HTTP/REST有個人熱情。 – Aliostad 2012-04-13 12:08:26
@baileyswalk等待其他人的更多評論。我希望其他人也貢獻。 – Aliostad 2012-04-13 12:09:26